To maintain and understand large applications, it is important to know their architecture. The first problem is that unlike classes and packages, architecture is not explicitly represented in the code. The second problem is that successful applications evolve over time, so their architecture inevitably drifts. Reconstructing the architecture and checking whether it is still valid is therefore an important aid. While there is a plethora of approaches and techniques supporting architecture reconstruction, there is no comprehensive software architecture reconstruction state of the art and it is often difficult to compare the approaches. This article presents a state of the art in software architecture reconstruction approaches.

We recently developed a static analysis to extract runtime architectures from object-oriented programs written in existing languages. The approach relies on adding ownership domain annotations to the code, and statically extracts a hierarchical runtime architecture from an annotated program. We present promising results from a week-long on-site field study to evaluate the method and the tools on a 30-KLOC module of a 250-KLOC commercial system. In a few days, we were able to add the annotations

An object diagram makes explicit the object structures that are only implicit in a class diagram. An object diagram may be missing and must extracted from the code. Alternatively, an existing diagram may be inconsistent with the code, and must be analyzed for conformance with the implementation. One can generalize the global object diagram of a system into a runtime architecture which abstracts objects into components, represents how those components interact, and can decompose a component into a nested sub-architecture. A static object diagram represents all objects and interobject relations possibly created, and is recovered by static analysis of a program. Existing analyses extract static object diagrams that are non-hierarchical, do not scale, and do not provide meaningful architectural abstraction. Indeed, architectural

The software architecture is one of the most important artifacts created in the lifecycle of a software system. It enables, facilitates, hampers, or interferes directly the achievement of business goals, functional and quality requirements. One instrument to determine how adequate the architecture is for its intended usage is architecture compliance checking. This paper compares three static architecture compliance checking approaches (reflexion models, relation conformance rules, and component access rules) by assessing their applicability in 13 distinct dimensions. The results give guidance on when to use which approach.

It is hard to statically check a system’s conformance to its runtime architectural structure. Previous approaches address the code architecture, change the language radically, mandate implementation frameworks, or use dynamic analyses that cannot check all possible program runs. We propose a static approach that supports existing object-oriented implementations, but relies on program annotations to encode architectural intent. We statically extract a hierarchical view of the runtime object graph from the annotated program and map it into an as-built runtime architecture. We then check and measure the structural conformance of the as-built and the as-designed architectures.

Abstract—Java Enterprise Applications (JEAs) are large systems that integrate multiple technologies and programming languages. Transactions in JEAs simplify the development of code that deals with failure recovery and multi-user coordination by guaranteeing atomicity of sets of operations. The heterogeneous nature of JEAs, however, can obfuscate conceptual errors in the application code, and in particular can hide incorrect declarations of transaction scope. In this paper we present a technique to expose and analyze the application transaction scope in JEAs by merging and analyzing information from multiple sources. We also present several novel visualizations that aid in the analysis of transaction scope by highlighting anomalies in the specification of transactions and violations of architectural constraints. We have validated our approach on two versions of a large commercial case study.

During software maintenance tasks, developers often spend an important amount of effort investigating source code. This effort can be reduced if tools are available to help developers navigate the source code effectively. For this purpose, we propose to search the change history of a software system to identify clusters of program elements related to a task. We evaluated the feasibility of this idea with an extensive historical analysis of change data. Our study evaluated to what extent change sets approximating tasks could have benefited from knowledge about clusters of past changes. A study of 3 500 change sets for seven different systems and covering a cumulative time span of close to 12 years of development shows that less than 12 % of the changes could have benefited from change clusters. We report on our observations on the factors that influence how we can use change clusters to guide program navigation. 1.

Software variants emerge from ad-hoc copying inthe-large with adaptations to a specific context. As the number of variants increases, maintaining such software variants becomes more and more difficult and expensive. In contrast to such ad-hoc reuse, software product lines offer organized ways of reuse, taking advantage of similarities of different products. To re-gain control, software variants may be consolidated as organized software product lines. In this paper, we describe a method and supporting tools to compare software variants at the architectural level extending the reflexion method to software variants. Murphy’s reflexion method allows one to reconstruct the module view, a static architectural view describing the static components, their interfaces and dependencies and their grouping as layers and subsystems. The method consists of the specification of the module view and the mapping of implementation components onto the module view. An automatic analysis determines differences between the module view and its implementation. We extend the reflexion method from single systems to software variants. Because software variants share a very large amount of code, we use clone detection techniques to identify corresponding implementation components between variants. The correspondence is then used to transfer as much of the mapping for the analyzed variants to the next variant to be analyzed. 1

Abstract not found

To maintain and understand large applications, it is crucial to know their architecture. The first problem is that architectures are not explicitly represented in the code as classes and packages are. The second problem is that successful applications evolve over time so their architecture inevitably drifts. Reconstructing and checking whether the architecture is still valid is thus an important aid. While there is a plethora of approaches and techniques supporting architecture reconstruction, there is no comprehensive state of the art and it is often difficult to compare the approaches. This article presents a first state of the art in software architecture reconstruction, with the desire to support the understanding of the field. 1.