Christine Hofmeister

Symphony: view-driven software architecture reconstruction

Authentic descriptions of a software architecture are required as a reliable foundation for any but trivial changes to a system. Far too often, architecture descriptions of existing systems are out of sync with the implementation. If they are, they must be reconstructed. There are many existing techniques for reconstructing individual architecture views, but no information about how to select views for reconstruction, or about process aspects of architecture reconstruction in general. In this paper we describe view-driven process for reconstructing software architecture that fills this gap. To describe Symphony, we present and compare different case studies, thus serving a secondary goal of sharing real-life reconstruction experience. The Symphony process incorporates the state of the practice, where reconstruction is problem-driven and uses a rich set of architecture views. Symphony provides a common framework for reporting reconstruction experiences and for comparing reconstruction approaches. Finally, it is a vehicle for exposing and demarcating research problems in software architecture reconstruction.

Modeling and verification of adaptive navigation in web applications

The navigation of a web application is the possible sequences of web pages a user can visit. In the simplest case the next page is determined by the current page and the action (e.g. link, button) selected by the user. However, many web applications now incorporate adaptive navigation, where the next page also depends on the users mode, for example whether they are a customer or an administrator, or depends on what pages the user has visited previously.Navigation models are useful for clarifying requirements and specifying implementation behavior. When a model is formal, it can also be used to generate design or implementation artifacts, and can be verified for properties such as broken links or length of navigation path. These uses are all important for the case of simple navigation, but even more important for adaptive navigation because of the added complexity. However, none of the current formal approaches can support adaptive navigation.In this paper we present an approach that uses Statecharts to formally model adaptive navigation, and show how important properties of a navigation model are verified using existing model-checking tools. We summarize the kinds of properties that can be checked with such a model, and describe how to use the Symbolic Model Verifier (SMV) tool to perform the verification. Finally, we use the Blockbuster® web site as a case study to demonstrate how our approach can uncover navigation problems that arise when new requirements are imposed.

Global Analysis: moving from software requirements specification to structural views of the software architecture

Software architecture design approaches typically treat architecture as an abstraction of the implemented system. However, doing so means that the concepts, languages, notations, and tools for architecture are much more closely related to those of detailed design and implementation than to those of software requirements. Thus the gap between requirements and architecture represents a paradigm shift, while that between architecture and detailed design does not. Global Analysis, which is part of the Siemens Four Views architecture design approach, is a set of activities that serves to reduce the magnitude of this gap by guiding the architecture design process, capturing design rationale, and supporting traceability between requirements and architecture. In this paper Global Analysis is re-examined in light of five years of teaching it, reflecting on it, comparing it to other approaches, and examining how it was applied in four new systems. This experience confirms the value of the Global Analysis activities and the importance of capturing its results. In some cases the benefit went beyond that envisioned, and in other cases Global Analysis was not applied as expected. Because the templates that are provided for Global Analysis results have such a strong influence on how the activities were performed, this will be the focus of future changes.

Relating navigation and request routing models in web applications

A navigation model describes the possible sequences of web pages a user can visit, and a request routing model describes how server side components handle each request. Earlier we developed formal models and analysis operations for such models. While each is useful independently, their utility is greatly improved by relating the models, which is the contribution described in this paper. We describe mappings between the models, and show that the mappings preserve navigation behavior and are bijective, thus supporting traceability and allowing the models to be used in round-trip engineering. With these mappings built into our Model Helper tool, it is now possible to automatically determine whether a Request Routing model conforms to the navigation design, and to automatically generate a Request Routing model from a navigation model. Finally, we describe one of a number of case studies where we used Model Helper in a round-trip engineering scenario.

Separation of navigation routing code in J2EE web applications

The navigation routing code of a web application is the part of the code involved in routing a request from a web page through the appropriate components on the server, typically ending with the display of a response page. Common maintenance activities are to change the sequence of pages or the processing for a page, and for these activities the navigation routing code must be located, understood, and possibly modified. But in J2EE applications this code is spread among a number of components, making maintenance costly. We describe an approach for separating this navigation routing code, using either Aspect Oriented Programming (AOP) or conventional OO techniques. We demonstrate how this improves maintainability by converting three exemplar applications from Sun and Oracle, with a 4- to 11-fold reduction in the number of files containing navigation routing code and in the lines of code in these files.

Analyzing Commercial Component Models

Our goal is this paper was to clarify what commercial component models provide to support component-based systems. One of the key motivations was the evident confusion about what a component is, even within a single component model. In this paper we first make a distinction between the functionality of a component model and the mechanisms it uses to support that functionality. We define three kinds of invocation mechanisms for component model services: explicit, implied, and declarative. We describe the elements of a component, show how they support the different invocation mechanisms, and show the role of packaging standards for well-defined components. The component models we examined fall into three distinct groups, with JavaBeans at the weak end, CORBA 2.3, COM/DCOM, and COM+ in the middle, and EJB and.NET at the strong end. The strong component models have configurable execution semantics for operation invocation, declarative service usage, and, most importantly, a well-defined component concept. They also have the properties of the middle group of component models, which use the implied service usage mechanism to support transparent remote communication, and allow an application to use multiple implementations of a component at a time. COM+ falls between the strong and middle groups.

Architecting Session Report

The Architecting session examined the development of software architectures. Seven papers were presented, covering both the state of the practice and new architecting approaches. Based on the paper presentations and subsequent discussions, we concluded that tool support is a barrier to adoption of methods, and that architectural knowledge, including domain-specific knowledge and understanding of patterns and styles is essential but difficult to communicate. A related issue, the documentation of an architecture, is similarly critical but not easy to do well, and better techniques and tools are needed. Finally, we agreed that agile methods do not bring fundamental changes to the practice of architecting.

Modeling Request Routing in Web Applications

For Web applications, determining how requests from a Web page are routed through server components can be time-consuming and error-prone due to the complex set of rules and mechanisms used in a platform such as J2EE. We define request routing to be the possible sequences of server-side components that handle requests. Many maintenance tasks require the developer to understand the request routing, so this complexity increases maintenance costs. However, viewing this problem at the architecture level provides some insight. The request routing in these Web applications is an example of a pipeline architectural pattern: each request is processed by a sequence of components that form a pipeline. Communication between pipeline stages is event-based, which increases flexibility but obscures the pipeline structure because communication is indirect. Our approach for improving the maintainability of J2EE Web applications is to provide a model that exposes this architectural information. We use Z to formally specify request routing models and analysis operations that can be performed on them, then provide tools to extract request routing information from an applications source code, create the request routing model, and analyze it automatically. We have applied this approach to a number of existing applications up to 34K LOC, showing improvement via typical maintenance scenarios. Since this particular combination of patterns is not unique to Web applications, a model such as our request routing model could provide similar benefits for these systems

Reexamining the role of interactions in software architecture

Describing and understanding the interactions among computation units in a software system remains one of the most interesting challenges of software architecture. In the old days, computation units were statements, and interaction among them consisted of the control flow between them. Structured programming and modern languages have made this quite tractable for developers to describe and understand. But object-orientation, concurrency, and component-based systems have pushed us into a realm where interactions between computation units (components) are often quite complex and difficult to understand.