We have found many programming problems for which neither procedural nor object-oriented programming techniques are sufficient to clearly capture some of the important design decisions the program must implement. This forces the implementation of those design decisions to be scattered throughout the code, resulting in “tangled” code that is excessively difficult to develop and maintain. We present an analysis of why certain design decisions have been so difficult to clearly capture in actual code. We call the properties these decisions address aspects, and show that the reason they have been hard to capture is that they crosscut the system’s basic functionality. We present the basis for a new programming technique, called aspect-oriented programming, that makes it possible to clearly express programs involving such aspects, including appropriate isolation, composition and reuse of the aspect code. The discussion is rooted in systems we have built using aspect-oriented programming.

This paper presents a method to view a system as a hierarchy of modules according to information hiding concepts and to identify architectural component candidates in this hierarchy. The result of the method eases the understanding of a system's underlying software architecture. A prototype tool implementing this method was applied to three systems written in C (each over 30 Kloc). For one of these systems, an author of the system created an architectural description. The components generated by our method correspond to those of this architectural description in almost all cases. For the other two systems, most of the components resulting from the method correspond to meaningful system abstractions. 1. Introduction It is well known that programmer efforts are mostly devoted to maintaining systems [Corb89, Somm92]. A large portion of that maintenance effort is spent in understanding the program and data [Yau80]. Within this context, helping maintainers to understand the legacy systems...

To effectively perform a change to an existing software system, a software engineer needs to have some understanding of the structure of the system. All too often, though, an engineer must proceed to change a system without sufficient structural information because existing software understanding techniques are unable to help the engineer acquire the desired knowledge within the time and cost constraints specified for the task. The thesis of this research is that an approach based on summarization can overcome the limitations associated with existing approaches, enabling an engineer to assess, plan, and execute changes to a software system more effectively. Summarization involves the production of overviews of vast amounts of user-selected information in a timely manner. I describe two tech...

Software product lines (SPLs) enable modular, large-scale reuse through a software architecture addressing multiple core and varying features. To reap the benefits of SPLs, their designs need to be stable. Design stability encompasses the sustenance of the product line’s modularity properties in the presence of changes to both the core and varying features. It is usually assumed that aspect-oriented programming promotes better modularity and changeability of product lines than conventional variability mechanisms, such as conditional compilation. However, there is no empirical evidence on its efficacy to prolong design stability of SPLs through realistic development scenarios. This paper reports a quantitative study that evolves two SPLs to assess various design stability facets of their aspect-oriented implementations. Our investigation focused upon a multi-perspective analysis of the evolving product lines in terms of modularity, change propagation, and feature dependency. We have identified a number of scenarios which positively or negatively affect the architecture stability of aspectual SPLs.

Requirements-driven impact analysis (RDIA) identifies the set of software entities that need to be changed to implement a new requirement in an existing system. RDIA thus involves a transition from requirements to software entities or to a representative model of the implemented system. RDIA is performed during the release planning phase. Input is a set of requirements and the existing system. Output is, for each requirement, a set of software entities that have to be changed. The output is used as input to many projectplanning activities, for example cost estimation based on change volume.

Reverse-engineering application codes back to the design and specification stage may entail the recreation of lost information for an application, or the extraction of new information. We describe techniques which produce abstractions in object-oriented and functional notations, thus aiding the comprehension of the essential structure and operations of the application, and providing formal design information which may make the code much more maintainable and certainly more respectable. The two types of application considered here are (1) data processing applications written in Cobol -- of primary importance due to their pre-dominance in present computing practice -- and (2) scientific applications written in Fortran. These two require somewhat different abstraction approaches. 1 Introduction The Programming Research Group at Oxford University is participating in the ESPRIT II project REDO 1 on the Maintenance, Validation and Documentation of Software Systems. As part of this proje...

Constant changes cause software architectures to degenerate. In organizations where developers are involved in the maintenance and evolution, system degeneration is even more likely to occur. We have experimented with a process for detecting deviations from the intended design. The process is a quick and inexpensive process that helps to keep the system architecture from veering off course from the planned design. It is expected to improve maintainability over time. The paper

A dependence cluster is a set of program statements, all of which are mutually inter-dependent. This paper reports a large scale empirical study of dependence clusters in C program source code. The study reveals that large dependence clusters are surprisingly commonplace. Most of the 45 programs studied have clusters of dependence that consume more than 10 % of the whole program. Some even have clusters consuming 80 % or more. The widespread existence of clusters has implications for source code analyses such as program comprehension, software maintenance, software testing, reverse engineering, reuse, and parallelization.

Abstract—Architecture-level decisions, directly influenced by environmental factors, are crucial to preserve modularity and stability throughout software development life-cycle. Tradeoffs of modularization alternatives, such as aspect-oriented vs. object-oriented decompositions, thus need to be assessed from architecture models instead of source code. In this paper, we present a suite of architecture-level metrics, taking external factors that drive software changes into consideration and measuring how well an architecture produces independently substitutable modules. We formalize these metrics using logical models to automate quantitative stability and modularity assessment. We evaluate the metrics using eight aspectoriented and object-oriented releases of a software product-line architecture, driven by a series of heterogeneous changes. By contrasting with an implementation-level analysis, we observe that these metrics can effectively reveal which modularization alternative generates more stable, modular design from highlevel models.

Maintenance is one of the major concerns of software developers and industries. The success of this critical phase depends highly on the changeability of the software. In order to evaluate the flexibility of a software to accommodate changes, we have defined a change impact model for object-oriented systems. As previously defined, it calculates the impacted classes due to an atomic change. In this paper we present an extension of the change impact model to obtain a fine-grained assessment of system changeability. As a first extension, we take into account the classes that are impacted by ripple effect. In a second extension, we also count classes that need to be re-tested even if they are not directly affected. An experimentation is planned to study the relationship between software’s changeability assessed by the extended change impact model and design properties.