Ownership type qualifiers clarify aliasing invariants that cannot be directly expressed in mainstream programming languages. Adding qualifiers to code, however, often involves significant overhead and difficult interaction.

During impact analysis on object-oriented code, statically extracting dependencies is often complicated by subclassing, programming to interfaces, aliasing, and collections, among others. When a tool recommends a large number of types or does not rank its recommendations, it may lead developers to explore more irrelevant code. We propose to mine and rank dependencies based on a global, hierarchical points-to graph that is extracted using abstract interpretation. A previous whole-program static analysis interprets a program enriched with annotations that express hierarchy, and over-approximates all the objects that may be created at runtime and how they may communicate. In this paper, an analysis mines the hierarchy and the edges in the graph to extract and rank dependencies such as the most important classes related to a class, or the most important classes behind an interface. An evaluation using two case studies on two systems totaling 10,000 lines of code and five completed code modification tasks shows that following dependencies based on abstract interpretation achieves higher effectiveness compared to following dependencies extracted from the abstract syntax tree. As a result, developers explore less irrelevant code.

To evolve object-oriented code, one must understand both the code structure in terms of classes, and the runtime structure in terms of abstractions of objects that are being created and relations between those objects. To help with this understanding, static program analysis can extract heap abstractions such as object graphs. But the extracted graphs can become too large if they do not sufficiently abstract objects, or too imprecise if they abstract objects excessively to the point of being similar to a class diagram, where one box for a class represents all the instances of that class. One previously proposed solution uses both annotations and abstract interpretation to extract a global, hierarchical, abstract object graph that conveys both abstraction and design intent, but can still be related to the code structure. In this paper, we define metrics that relate nodes and edges in the object graph to elements in the code structure, to measure how they differ, and if the differences are indicative of language or design features such as encapsulation, polymorphism and inheritance. We compute the metrics across eight systems totaling over 100 KLOC, and show a statistically significant difference between the code and the object graph. In several cases, the magnitude of this difference is large.

During Architectural Risk Analysis (ARA), security architects use a runtime architecture to look for security vulnerabilities that are architectural flaws rather than coding defects. The current ARA process, however, is mostly informal and manual. In this paper, we propose Scoria, a semi-automated approach for finding architectural flaws. Scoria uses a sound, hierarchical object graph with abstract objects and dataflow edges, where edges can refer to nodes in the graph. The architects can augment the object graph with security properties, which can express security information unavailable in code. Scoria allows architects to write queries on the graph in terms of the hierarchy, reachability, and provenance of a dataflow object. Based on the query results, the architects enhance their knowledge of the system security and write expressive constraints. The expressiveness is richer than previous approaches that check only for the presence or absence of communication or do not track a dataflow as an object. To evaluate Scoria, we apply these constraints to several extended examples adapted from the CERT standard for Java to confirm that Scoria can detect injected architectural flaws. Next, we write constraints to enforce an Android security policy and find one architectural flaw in one Android application.

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.

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.

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.

Ownership domain annotations enable obtaining at compile-time the system's execution structure from the annotated program. The execution structure is sound, hierarchical (and thus more scalable) and conveys more design intent than flat object graphs obtained by existing static analyses that do not rely on annotations.

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.

Existing approaches to differencing and merging architectural views are based on restrictive assumptions such as requiring view elements to have unique identifiers or exactly matching types. We propose an approach based on structural information by generalizing a published polynomial-time tree-to-tree correction algorithm (that detects inserts, renames and deletes) into a novel algorithm to additionally detect restricted moves and support forcing and preventing matches between view elements. We incorporate the algorithm into tools to compare and merge component-and-connector (C&C) architectural views. Finally, we provide an empirical evaluation of the algorithm on case studies to find and reconcile interesting divergences between architectural views

We demonstrate a tool to incrementally synchronize an Acme architectural model described in the Acme Architectural Description Language (ADL) with an implementation in ArchJava, an extension of the Java programming language that includes explicit architectural modeling constructs.

In practice, there are many differences between an implementation-level architecture (such as one derived using architectural recovery techniques) and a more conceptual architecture used at design time. We present a lightweight, scalable, semi-automated, incremental approach for synchronizing a Componentand- Connector (C&C) view retrieved from an implementation with a conceptual C&C view described in an Architectural Description Language. Our approach can automatically detect corresponding elements in the presence of insertions, deletions, renames, and moves, and incrementally synchronize the two views.

Without rigorous software development and maintenance, software tends to lose its original architectural structure and become more difficult to understand and modify. ArchJava, a recently proposed implementation language which embeds a component-and-connector architectural specification within Java implementation code, offers the promise of preventing the loss of architectural structure. We describe a case study in which we incrementally re-engineer an existing implementation with an eroded architecture to obtain an ArchJava implementation that more closely matches an idealized architecture. Building on results from similar case studies, we chose an application consisting of over 16,000 source lines of Java code and 80 classes that exhibited many characteristics of real-world legacy applications. We describe our process, some lessons learned, as well as some perceived limitations with the tools, techniques and languages we used.

One of the difficulties in requirements negotiation is to determine a feasible and mutually satisfactory set of requirements for the developer and the user, a problem related to C.P. Snow's (1959) "Two Cultures" problem. During the last year of our experience with an annual series of digital library projects, we have been experimenting with expectations management and domain specific lists of "simplifiers" and "complicators", as a way to address the "Two Cultures" problem involving librarians and computer scientists. Initial results indicate that the simplifiers and complicators approach successfully reduced the number of projects having serious feasibility problems, and helped manage the expectations of both the developers and the customers/users. We see no obstacles to applying the approach to other domains.