A Field Study in Static Extraction ofRuntime Architectures1Marwan Abi-Antoun Jonathan AldrichJune 2008CMU-ISR-08-133School of Computer ScienceCarnegie Mellon UniversityPittsburgh, PA 15213AbstractWe recently developed a static analysis to extract runtime architectures from object-oriented programswritten 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 a30-KLOC module of a 250-KLOC commercial system. In a few days, we were able to add the annotationsto the module and extract a top-level architecture for review by a developer.1A shorter version is to appear as: Abi-Antoun, M. and Aldrich, J. A Field Study in Static Extraction of Runtime Ar-chitectures. In ACM SIGPLAN-SIGSOFT Workshop on Program Analysis for Software Tools and Engineering (PASTE),2008.This work was supported in part by NSF CAREER award CCF-0546550, DARPA contract HR00110710019, theDepartment of Defense, and the Software Industry Center at Carnegie Mellon University and its sponsors, especiallythe Alfred P. Sloan Foundation.Keywords: runtime architecture, architecture recovery, ownership types, field studyContents1 Introduction 22 Overview 22.1 Mapping Source to High-Level Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22.2 Ownership Domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32.3 Static Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 Field Study 53.1 Setup and Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63.2 Extraction Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 Results 94.1 Quantitative Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94.2 Qualitative Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94.3 Validity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125 Related Work 126 Conclusion 14List of Figures1 A Document-View architecture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 Two-tiered system with annotations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 High-level module and runtime views. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 Developer’s diagram. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175 Extracted runtime architecture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181“An object-oriented program’s runtime structure often bears little resemblance to its code structure. Thecode structure is frozen at compile-time; it consists of classes in fixed inheritance relationships. A pro-gram’s runtime structure consists of rapidly changing networks of communicating objects. In fact, thetwo structures are largely independent. Trying to understand one from the other is like trying to un-derstand the dynamism of living ecosystems from the static taxonomy of plants and animals, and viceversa.” (Gamma et al., 1994 [17]).1 IntroductionSoftware architects describe a system using different architectural views. A code architecture or module viewshows code entities in terms of classes, packages, layers and modules. A runtime architecture or runtimeview of a system models runtime entities and their potential interactions [13].Many tools automatically extract module views from source code [24], but the support for runtime viewsis less mature [22, 37]. Intuitively, many have preferred dynamic analyses to extract runtime architectures.But, a dynamic analysis extracts partial descriptions that cover interactions between objects from a fewprogram runs. To be most useful, an architecture must capture a complete description of a system’s runtimestructure. This requires a static analysis that is sound, i.e., one that reveals all entities and relations thatcould possibly exist at runtime.Previous static analyses extract low-level non-hierarchical object graphs that do not provide architecturalabstraction [31, 26, 19, 38]. Other approaches use radical language extensions [7, 34] or mandate architecturalmiddleware or frameworks [28]. To handle existing systems, an approach must support existing languages,common design idioms, and existing frameworks and libraries. But adding annotations to clarify the designintent might be acceptable.We have been applying ownership domain annotations for architectural extraction [1, 3]. Ownershiptypes were originally proposed to control aliasing [12, 6, 14], but also enable the static extraction of runtimearchitectures, because they track instances instead of types. In our architectural recovery method, a developeradds annotations to clarify the architectural intent related to object encapsulation, logical containment andarchitectural tiers.The annotations specify and enforce the sharing of data between objects, a key challenge in extractinga runtime architecture. This state sharing is often not explicit in object-oriented programs, rather, it isimplicit in the structure of references created at runtime.Using annotations to recover design from code is not new [26]. But previous systems did not supporthierarchy, and thus did not scale to large systems at multiple levels of abstraction, nor did they supportcritical language constructs like inheritance.Our approach does have the overhead of adding annotations to a program, which is currently done mostlymanually. Precise and scalable ownership inference is a separate problem and an active topic of ongoingresearch [29].In this paper, we present promising results from an on-site field study to demonstrate the approach’sfeasibility on real code and users. The paper is organized as follows. Section 2 gives an overview of theapproach. Section 3 discusses …