Marwan Abi-Antoun

Static extraction and conformance analysis of hierarchical runtime architectural structure using annotations

A high-level architectural diagram of a systems organization can be useful during software evolution. Often, such a diagram is missing, hence the need to extract one from the code. Alternatively, a diagram may exist but may be inconsistent with the code, hence the need to analyze its conformance with the implementation. One important notion of conformance, the communication integrity principle, stipulates that each component in the implementation may only communicate directly with the components to which it is connected in the architecture. This dissertation proposes a novel approach, SCHOLIA*, to extract a hierarchical runtime architecture from an existing object-oriented system, and analyze communication integrity with a target architecture, entirely statically and using typecheckable ownership annotations. Previous approaches to enforcing communication integrity have significant drawbacks: they either require radical language extensions that incorporate architectural constructs at the expense of severe implementation restrictions, mandate specialized architectural middleware, or use dynamic analyses that cannot check all possible executions. The key contribution is a static points-to analysis to extract, from an annotated program, a global object graph that provides architectural abstraction by ownership hierarchy and by types, where architecturally significant objects appear near the top of the hierarchy and data structures are further down. Moreover, an extracted object graph is sound in two respects. First, each runtime object has exactly one representative in the object graph. Second, the object graph has edges that correspond to all possible runtime points-to relations between those objects. Another analysis abstracts an object graph into a built runtime architecture. Then, a third analysis compares structurally the built architecture to a target, and analyzes communication integrity in the target architecture, without propagating low-level implementation objects into the target architecture. An evaluation on several real object-oriented systems showed that, in practice, SCHOLIA can be applied to an existing system while changing only annotations in the code, and that SCHOLIA can identify interesting structural differences between an existing implementation and its target architecture. *SCHOLIA stands for static conformance checking of object-based structural views of architecture. Scholia are annotations which are inserted on the margin of an ancient manuscript.

Enabling the refinement of a software architecture into a design

Software architecture research has thus far mainly addressed formal specification and analysis of coarse-grained software models. The formality of architectural descriptions, their lack of support for downstream development activities, and their poor integration with mainstream approaches have made them unattractive to a large segment of the development community. This paper demonstrates how a mainstream design notation, the Unified Modeling Language (UML), can help address these concerns. We describe a semi-automated approach developed to assist in refining a high-level architecture specified in an architecture description language (ADL) into a design described with UML. To this end, we have integrated DRADEL, an environment for architecture modeling and analysis, with Rational Rose®, a commercial off-the shelf (COTS) UML modeling tool. We have defined a set of rules to transform an architectural representation into an initial UML model that can then be further refined. We believe this approach to be easily adaptable to different ADLs, to the changes in our understanding of UML, and to the changes in UML itself.

A case study in re-engineering to enforce architectural control flow and data sharing

Without rigorous software development and maintenance, software tends to lose its original architectural structure and become difficult to understand and modify. ArchJava, a recently proposed programming language which embeds a component-and-connector architectural specification within Java implementation code, offers the promise of preventing the loss of architectural structure. AliasJava, which can be used in conjunction with ArchJava, is an annotation system that extends Java to express how data is confined within, passed among, or shared between components and objects in a software system. We describe a case study in which we incrementally re-engineer an existing Java implementation to obtain an implementation which enforces the architectural control flow and data sharing. Building on results from similar case studies, we chose an application consisting of over 16,000 source lines of Java code and over 90 classes. We describe our process, the detailed steps involved (some of which can be automated), as well as some lessons learned and perceived limitations with the languages, techniques and tools we used.

Analyzing security architectures

We present a semi-automated approach, SECORIA, for analyzing a security runtime architecture for security and for conformance to an object-oriented implementation. Type-checkable annotations describe architectural intent within the code, enabling a static analysis to extract a hierarchical object graph that soundly reflects all runtime objects and runtime relations between them. In addition, the annotations can describe modular, code-level policies. A separate analysis establishes traceability between the extracted object graph and a target architecture documented in an architecture description language. Finally, architectural types, properties, and logic predicates describe global constraints on the target architecture, which will also hold in the implementation. We validate the SECORIA approach by analyzing a 3,000-line pedagogical Java implementation and a runtime architecture designed by a security expert.

Checking threat modeling data flow diagrams for implementation conformance and security

Threat modeling is a lightweight approach to reason about application security and uses Data Flow Diagrams (DFDs) with security annotations. We extended Reflexion Models to check the conformance of an as-designed DFD with an approximation of the as-built DFD obtained from the implementation. We also designed a set of properties and an analysis to help novice designers think about security threats such as spoofing, tampering and information disclosure.

Object graphs with ownership domains: an empirical study

Researchers have proposed many ownership type systems but reported limited experience with most of them on real object-oriented code. Only a few systems have been implemented, and there have been few substantial case studies done with those systems. In order to better empirically evaluate ownership type systems, we have therefore conducted a number of case studies applying the Ownership Domains type system to programs at a larger scale. To facilitate the study of legacy code, we reimplemented Ownership Domains using available language support for annotations. After annotating and typechecking a range of object-oriented systems, we extracted global, hierarchical, Ownership Object Graphs (OOGs) using static analysis. OOGs provide an abstracted view that is consistent with programmer design intent, compared to flat object graphs that can be extracted without the benefit of the ownership annotations. An OOG also visualizes the systems ownership structure and helps developers refine the annotations they add to better express the systems design. This paper shares our observations from studying the annotations and the extracted OOGs across several subject systems. We compute metrics on the annotations and on the extracted OOGs, to gain insights into the ownership relationships latent within object-oriented code and to evaluate the effectiveness of the abstraction mechanisms in OOGs.

Empirical Evaluation of Diagrams of the Run-time Structure for Coding Tasks

With object-oriented design, it is at least as important-possibly more important-to understand the runtime structure, in terms of objects and their relations, as to understand the code structure dealing with source files, classes and packages. Today, many tools and diagrams help developers understand the code structure. Diagrams of the runtime structure, however, are much less mature. One diagram of the run-time structure is a statically extracted, global, hierarchical Ownership Object Graph (OOG). The OOG conveys architectural abstraction by ownership hierarchy by showing architecturally significant objects near the top of the hierarchy and data structures further down. In an OOG, objects are also organized into named, conceptual groups called domains. We evaluate, in a controlled experiment, whether an OOG, as a diagram of the run-time structure, improves comprehension by giving developers the ability to distinguish the role that an object plays, not only by type, but also by named groups (domains) or by position in the run-time structure (ownership). We observed 10 participants, for 3 hours each, perform three feature implementation tasks on a framework application. Our results indicate that, on average, the OOG had a positive effect of varying extents on comprehension that reduced the time spent by 22%-60% and irrelevant code explored by 10%-60%. The difference was significant (p <; 0.05) for two of the tasks.

Improving system dependability by enforcing architectural intent

Developing dependable software systems. requires enforcing conformance between architecture and implementation during software development and evolution. We address this problem with a multi-pronged approach: (a) automated refinement of a component-and-connector (C&C) architectural view into an initial implementation, (b) enforcement of architectural structure at the programming language level, (c) automated abstraction of a C&C view from an implementation, and (d) semi-automated incremental synchronization between the architectural and the implementation C&C views.We use an Architecture Description Language (ADL), Acme, to describe the architecture, and ArchJava, an implementation language which embeds a C&C architecture specification within Java implementation code. Although both Acme and ArchJava specify C&C views, a number of structural differences may arise. Our approach can detect structural differences which correspond directly to implementation-level violations of the well thoughtout architectural intent. Furthermore, supplementing the C&C view extracted from the implementation with architectural types and styles can uncover additional violations.

Static extraction of sound hierarchical runtime object graphs

For many object-oriented systems, it is often useful to have a runtime architecture that shows networks of communicating objects. But it is hard to statically extract runtime object graphs that provide architectural abstraction from existing programs written in general purpose languages, and that follow common design idioms. Previous approaches extract low-level non-hierarchical object graphs that do not provide architectural abstraction, change the language too radically for many existing implementations, or use a dynamic analysis. Static analysis, which takes all possible executions into account, is essential to extract a sound architecture, one that reveals all objects and relations that could possibly exist at runtime. Ownership domain type annotations specify in code architectural intent related to object encapsulation and communication. We propose a static analysis that leverages such types and extracts a hierarchical approximation of all possible runtime object graphs. The representation provides architectural abstraction, first by ownership hierarchy, and then by types. We proved core soundness results for the technique and evaluated it on 68 KLOC of real code.

Ownership Object Graphs with Dataflow Edges

During architectural risk analysis, security experts look for architectural flaws based on a documented runtime structure, which for object-oriented systems can be approximated by an object graph. Architectural risk analysis involves thinking about worst-case scenarios, and thus requires a sound object graph, which shows all possible objects and dataflow communication between them. Extracting a sound object graph that conveys architectural abstraction is challenging. One solution is to apply a hierarchy to the object graph to convey both high-level understanding and detail. Achieving soundness requires a static analysis, but architectural hierarchy is not available in general purpose programming languages. To achieve hierarchy, we annotate the program with ownership types and use abstract interpretation to extract a global, sound, hierarchical object graph that has dataflow communication edges showing the flow of objects due to field reads, field writes, and method invocations. We formalize the static analysis, prove its soundness, then show that the extracted edges are similar to those drawn by a security expert.