View Full Document

A Field Study in Static Extraction of Runtime Architectures1



View the full content.
View Full Document
View Full Document

12 views

Unformatted text preview:

A Field Study in Static Extraction of Runtime Architectures1 Marwan Abi Antoun Jonathan Aldrich June 2008 CMU ISR 08 133 School of Computer Science Carnegie Mellon University Pittsburgh PA 15213 Abstract 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 to the module and extract a top level architecture for review by a developer 1 A shorter version is to appear as Abi Antoun M and Aldrich J A Field Study in Static Extraction of Runtime Architectures 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 the Department of Defense and the Software Industry Center at Carnegie Mellon University and its sponsors especially the Alfred P Sloan Foundation Keywords runtime architecture architecture recovery ownership types field study Contents 1 Introduction 2 2 Overview 2 1 Mapping Source to High Level Models 2 2 Ownership Domains 2 3 Static Analysis 2 2 3 4 3 Field Study 3 1 Setup and Methodology 3 2 Extraction Process 5 6 7 4 Results 4 1 Quantitative Data 4 2 Qualitative Data 4 3 Validity 9 9 9 12 5 Related Work 12 6 Conclusion 14 List of Figures 1 2 3 4 5 A Document View architecture Two tiered system with annotations High level module and runtime views Developer s diagram Extracted runtime architecture 1 4 5 7 17 18 An object oriented program s runtime structure often bears little resemblance to its code structure The code structure is frozen at compile time it consists of classes in fixed inheritance relationships A program s runtime structure consists of rapidly changing networks of communicating objects In fact the two structures are largely independent Trying to understand one from the other is like trying to understand the dynamism of living ecosystems from the static taxonomy of plants and animals and vice versa Gamma et al 1994 17 1 Introduction Software architects describe a system using different architectural views A code architecture or module view shows code entities in terms of classes packages layers and modules A runtime architecture or runtime view 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 views is 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 few program runs To be most useful an architecture must capture a complete description of a system s runtime structure This requires a static analysis that is sound i e one that reveals all entities and relations that could possibly exist at runtime Previous static analyses extract low level non hierarchical object graphs that do not provide architectural abstraction 31 26 19 38 Other approaches use radical language extensions 7 34 or mandate architectural middleware 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 design intent might be acceptable We have been applying ownership domain annotations for architectural extraction 1 3 Ownership types were originally proposed to control aliasing 12 6 14 but also enable the static extraction of runtime architectures because they track instances instead of types In our architectural recovery method a developer adds annotations to clarify the architectural intent related to object encapsulation logical containment and architectural tiers The annotations specify and enforce the sharing of data between objects a key challenge in extracting a runtime architecture This state sharing is often not explicit in object oriented programs rather it is implicit in the structure of references created at runtime Using annotations to recover design from code is not new 26 But previous systems did not support hierarchy and thus did not scale to large systems at multiple levels of abstraction nor did they support critical language constructs like inheritance Our approach does have the overhead of adding annotations to a program which is currently done mostly manually Precise and scalable ownership inference is a separate problem and an active topic of ongoing research 29 In this paper we present promising results from an on site field study to demonstrate the approach s feasibility on real code and users The paper is organized as follows Section 2 gives an overview of the approach Section 3 discusses the methodology we followed Section 4 discusses the results Finally we survey related work in Section 5 and conclude 2 Overview In this section we give the intuition behind the static extraction of runtime architectures by example 2 1 Mapping Source to High Level Models Architectural extraction maps source code entities to entities in a high level model Consider a DocumentView system where a BarChart and a PieChart render a Model 2 We used AgileJ to extract a module view from the program 5 Fig 1 a shows classes inheritance and association relations For instance classes BarChart and Model implement a Listener interface The view also shows associations from Model and BaseChart to Listener But it does not explain the instance structure of the application For instance it is not clear if a Model object and a BaseChart object share the same Listener object at runtime It is also unclear whether instances of PieChart and BarChart which inherit from BaseChart share one Listener object In general an object oriented program s runtime structure often bears little resemblance to its code structure One code element can appear as multiple elements in a runtime view Alternatively one element in a runtime view can correspond to multiple code elements At runtime BarChart and Model objects each contain a List of Listener objects Moreover the Listener object inside a list List Listener maps to multiple design elements based on the context Fig 1 b


Access the best Study Guides, Lecture Notes and Practice Exams

Loading Unlocking...
Login

Join to view A Field Study in Static Extraction of Runtime Architectures1 and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view A Field Study in Static Extraction of Runtime Architectures1 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?