Design Principles in Architectural Evolution: a Case Study

We wish to investigate how structural design principles are used in practice, in order to assess the utility and relevance of such principles to the maintenance of large, complex, long-lived, successful systems. In this paper we take Eclipse as the case study and check whether its architecture follows, throughout multiple releases, some principles proposed in the literature

An approach to software maintenance support using a syntactic source code analyser data base : this thesis is presented in a partial fulfillment of the requirements for the degree of Master of Arts in Computer Science at Massey University

In this thesis, the development of a software maintenance tool called a syntactic source code analyser (SSCA) is summarised. An SSCA supports other maintenance tools which interact with source code by creating a data base of source information which has links to a formatted version of program source code. The particular SSCA presented handles programs written in a version of COBOL. Before developing a SSCA system, aspects of software maintenance need to be considered. Hence, the scope, definitions and problems of maintenance activities are briefly reviewed and maintenance support through environments, software metrics, and specific tools and techniques examined. A complete maintenance support environment for an application is found to overlap considerably with the application documentation system and shares some tools with development environments. Program source code is also identified as the fundamental documentation of an application and interaction with this source code is a requirement of many maintenance support tools

Supporting software maintenance with non-functional information

The paper highlights the role of non functional information (about efficiency, reliability and other software attributes) of software components in software maintenance, focusing in the component programming framework. Non functional information is encapsulated in modules bound to both definitions and implementations of software components and it is written as expressions in a classical programming language. It is shown with an example how this notation supports software maintenance, with the help of an algorithm which is able to select the best implementation of a software component in its context of use, meaning byPeer ReviewedPostprint (published version

The Co-Evolution of Test Maintenance and Code Maintenance through the lens of Fine-Grained Semantic Changes

Automatic testing is a widely adopted technique for improving software quality. Software developers add, remove and update test methods and test classes as part of the software development process as well as during the evolution phase, following the initial release. In this work we conduct a large scale study of 61 popular open source projects and report the relationships we have established between test maintenance, production code maintenance, and semantic changes (e.g, statement added, method removed, etc.). performed in developers' commits. We build predictive models, and show that the number of tests in a software project can be well predicted by employing code maintenance profiles (i.e., how many commits were performed in each of the maintenance activities: corrective, perfective, adaptive). Our findings also reveal that more often than not, developers perform code fixes without performing complementary test maintenance in the same commit (e.g., update an existing test or add a new one). When developers do perform test maintenance, it is likely to be affected by the semantic changes they perform as part of their commit. Our work is based on studying 61 popular open source projects, comprised of over 240,000 commits consisting of over 16,000,000 semantic change type instances, performed by over 4,000 software engineers.Comment: postprint, ICSME 201

An Empirical Study of a Software Maintenance Process

This paper describes how a process support tool is used to collect metrics about a major upgrade to our own electronic retail system. An incremental prototyping lifecycle is adopted in which each increment is categorised by an effort type and a project component. Effort types are Acquire, Build, Comprehend and Design and span all phases of development. Project components include data models and process models expressed in an OO modelling language and process algebra respectively as well as C++ classes and function templates and build components including source files and data files. This categorisation is independent of incremental prototyping and equally applicable to other software lifecycles. The process support tool (PWI) is responsible for ensuring the consistency between the models and the C++ source. It also supports the interaction between multiple developers and multiple metric-collectors. The first two releases of the retailing software are available for ftp from oracle.ecs.soton.ac.uk in directory pub/peter. Readers are invited to use the software and apply their own metrics as appropriate. We would be interested to correspond with anyone who does so