Extraction of Ownership Object Graphs from Object-Oriented Code: an Experience Report Marwan Abi-Antoun Nariman Ammar Zeyad Hailat Department of Computer Science Wayne State University {mabiantoun, nammar, zmhailat}@wayne.edu ABSTRACT Despite receiving much research attention, the extraction of runtime architecture remains hard. One approach, Scholia, relies on adding typecheckable annotations to the code, and uses static analysis to extract a global, hierarchical Owner- ship Object Graph (OOG). The OOG provides architectural abstraction by ownership hierarchy and by types, and can be abstracted into a run-time architecture represented in an architectural description language, for documentation or conformance analysis. We report on our experience in analyzing a medium-sized object-oriented system undergoing maintenance to: (1) ex- tract an OOG; and (2) refine the OOG based on the main- tainers’ feedback. We evaluate the effectiveness of abstraction by ownership hierarchy and by types to extract an OOG that the system maintainers understand. We measure the extraction effort to be about 1 hour/KLOC. An evaluation with the lead main- tainer confirms that he understands abstraction by owner- ship hierarchy and by types. Finally, we illustrate how to incrementally refine an extracted OOG (without starting all over) to better match the maintainer’s mental model. Categories and Subject Descriptors D.2.11 [Software Engineering]: Software Architectures General Terms Experimentation, Documentation Keywords runtime architecture, architecture recovery, ownership types 1. INTRODUCTION AND MOTIVATION During software evolution, high-level architectural dia- grams showing the system’s organization are useful to main- tainers. Unfortunately, architectural diagrams are missing Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. QoSA’12, June 25–28, 2012, Bertinoro, Italy. Copyright 2012 ACM 978-1-4503-1346-9/12/06 ...$10.00. or out-of-date for many legacy object-oriented systems un- dergoing maintenance. Because the most reliable and accu- rate description of an evolving system is its source code [23], one can use architectural extraction techniques to reverse- engineer from the code high-level diagrams of a system for redocumentation, conformance and analysis [12]. Many architectural diagrams are needed to describe a soft- ware system. The code architecture organizes code entities in terms of classes and packages [10], and is useful for study- ing properties such as maintainability. Another useful dia- gram, the runtime architecture [10], models runtime entities and their potential interactions. A runtime architecture is equally important as the code architecture, because it im- pacts quality attributes such as security and performance. Despite receiving much research attention, extracting run- time architectures remains a hard problem. Many have preferred dynamic analysis (or mixed with static analysis) to extract the as-built runtime architecture [20, 21]. The only approach, currently available, to extract a hierarchi- cal runtime architecture entirely statically is Scholia by Abi-Antoun and Aldrich [3]. Scholia is a two-pronged ap- proach which requires first adding ownership annotations in the code to specify some architectural intent [6]. It then uses a static analysis to extract a hierarchical object graph, the Ownership Object Graph (OOG). The OOG provides archi- tectural abstraction by ownership hierarchy and by types, where architecturally significant objects are near the top of the hierarchy and data structures are further down. More- over, the OOG is sound in two respects. First, each runtime object has exactly one representative in the OOG. Second, the OOG has edges that correspond to all possible runtime points-to relations between those objects. The OOG corresponds to a runtime architecture which abstracts objects into components, abstracts relations be- tween objects into connections, and optionally decomposes a component into a nested sub-architecture. Instead of ob- jects being directly inside other objects, the OOG has an extra level of hierarchy and groups related objects inside a domain. A domain is similar to an architectural runtime tier, i.e., a conceptual partitioning of functionality [10]. In this paper, we report on our experience in analyzing a medium-sized, object-oriented system undergoing main- tenance to: (1) extract an OOG; and (2) refine the OOG based on the maintainers’ input. Research Questions. We refer to the person who added annotations to the code, extracted OOGs and refined them as the extractor (this paper’s third author). One of the maintainers of the subject system evaluated the OOG (and is