Over the last several years, there has been an increased emphasis on techniques for specifying and analyzing software architecture. During this time, software architecture research has generally fallen into one of the following four areas:
One of the basic premises of architecture-based research is that systems can be specified, designed, analyzed, built, tested, and evolved through architecture. Thus researchers are seeking to make architecture explicit and, to some degree, formal, and are seeking to provide manipulation and analysis tools supporting architecture-based development and evolution.
The use of architecture specifications in the development of software intensive systems is depicted in Figure 1. As seen in the figure, architecture specifications typically identify three elements:
Architecture Description Languages (ADLs) generally provide support for specifying these three elements, although the level of support varies between ADLs. For example, Wright [2] emphasizes component interaction protocols while UniCon [10] emphasizes architectural styles. As can be inferred from this discussion, there is no widely accepted definition of the term “software architecture.” “Architecture ” is generally taken to be a view of a system that includes the system’s major components, the behavior of those components as visible to the rest of the system, and the ways in which the components interact and coordinate to achieve the system’s mission. [5] Rather than attempt to provide a formal definition of software architecture, this article reviews the major research areas listed above and identifies a few usage considerations.
Software architecture involves descriptions of elements from which systems are built, interactions among those elements, patterns that guide their composition, and constraints on those patterns. ADLs provide language support for expressing these elements and lend themselves to providing a scientific and engineering basis for design, analysis, and composition. Some language and tool development efforts, such as the Domain Specific Software Architecture program, have as an additional goal support for domain specific language in architectural specification.
Some progress has been made with respect to representation and generation:
UniCon: components are loci of computation and state, and connectors are loci of relations between components; generates C/C++ code. [10]
Wright: defines component interaction using process algebras. [2]
Aesop: defines a system for developing style-specific architectural development environments. [12]
Jakarta: defines a software generator environment that uses constraint propagation to refine and integrate reusable software artifacts. [4]
Planware: Architecture is defined as a diagram of formal specifications. [11]
Although certain needs are shared by all ADLs, such as support for multiple views and tool support for control and data flow analysis, ADLs have been developed to meet different needs; thus expressive and analytical capability varies between them. Rather than developing multiple architectural specifications for a given system (or family of systems), a group of researchers is developing an architecture interchange language called ACME whose goal is to facilitate the exchange of architectural information.[1] These researchers are designing ACME along with translators into and out of ACME so that, for example, architectures described in UniCon can be translated through ACME into another ADL such as Aesop. This interchange language provides a way for different ADLs and ADL tool suites to work together. An interesting by-product of this research is that it is leading to a better understanding of what ADLs should be capable of representing and reasoning about.
Figure 2 depicts architecture interchange using ACME. The heavy arrows in the figure represent language to language transformations. Another type of transformation is one that takes place within the same language. These transformations seek to recast architectural elements into alternate representations. In conjunction with his work on the SADL language, Moriconi has developed several architectural transformations that can be used, for example, to enhance system performance. [9]
Architecture specifications are more than “boxes and arrows” diagrams. They are formal entities subject to analysis; they can be investigated to determine properties of the system(s) they specify. Investigating system properties at the architectural level has at least two advantages:
Unnecessary implementation details are abstracted away, allowing a developer to concentrate on architectural rather than implementation issues.
Early analysis. It is not necessary to have an implementation constructed before investigating family/system properties. For example, both Wright and Rapide were used to model the Department of DefenseĄs High Level Architecture (HLA) simulation framework. Analysis of the Wright specification revealed HLA problems associated with distributed start-up, paused on join, and in-transit messages after a resign. [3]
Similarly, analysis of the Rapide specification revealed that the run time interface could lose the event order and that there were orphaned attributes after a player resigned from the simulation.
The depth and type of investigation will vary between ADLs, but generally speaking, investigations include:
Static analysis. Ambiguities, incompleteness (e.g., missing connectors), wrong directionality, and, depending on the ADL, syntactic and semantic data type compatibility can be investigated. [13]
Model checking, including insufficient preconditions, faulty control models, and latent deadlocks. [2]
Simulation-based testing, including event order and causality anomalies. [7]
As a further example, the Model Integrated Computing (MIC) framework developed at Vanderbilt University has been used to investigate production flow at Saturn. [6] . This investigation (through architectural modeling) led to a 10% increase in the throughput of Saturn’s Spring Hill, Tennessee plant.
This line of research seeks to make better use of architecture specifications in software generation. As shown in Figure 3, rather than have a target architecture implicitly defined by the generator, researchers are developing generators that take as input an architecture specification of the target system. A closely related research topic is the specification of product line architectures.
The basic idea of product line development is to specify the architecture of a family of systems. Several efforts are underway in this area, including the Jakarta work at the University of Texas [4] and the Planware system under development at the Kestrel Institute.[11] The Planware system defines an architecture for a family of scheduling applications using formal specifications; implementations satisfying developer-selected constraints are generated from these specifications. Researchers at Kestrel have proven that the systems generated using Planware will find feasible schedules provided such schedules exist an important property of this family.
Several changes to current system development practices may occur:
Training. Developers will need training to understand and use ADL technology and architectural concepts/styles effectively.
Change/emphasis in life cycle phases. Architectural design and analysis may precede code development; an ADL specification should provide a good basis for programming activities. [10]
Documentation. Because the structure of a software system can be explicitly represented in an ADL specification, separate documentation describing software structure may not be necessary.
Expanding scope of architecture. ADLs are not limited to describing the software architecture; application to system architecture (to include hardware, software, and people) is also a significant opportunity.
About the AuthorMajor Gerken has been a computer engineer with the Air Force for over 11 years. He was initially assigned to support large scale acquisition efforts, including the C-17 and AMRAAM systems. He later transferred to the Air Force Institute of Technology where he researched formal approaches for representing and reasoning about software architectures. After receiving his Ph.D., Major Gerken was assigned to the Air Force Research Laboratory's Rome Research Site where he directed research into formal methods and software architecture. He is currently assigned to the Air Force Operational Test and Evaluation Center where he supports test and evaluation of software intensive systems. Further ReadingFor a comparison of several ADLs, see [8] and for an in-depth treatment of architecture-based development, see [13]. |
Contact InformationMajor Mark J. GerkenAir Force Operational Test and Evaluation Center HQ AFOTEC/TSS 8500 Gibson Blvd, SE Kirtland AFB, NM 87117-5558 DSN: 246-7827 |
 |
 |
 |