The ability to systematically construct new software systems from pre-existing components remains an elusive goal.
Why?
The authors call the latter type of incompatibility an architectural mismatch.
Architectural mismatches are usually more subtle and pervasive than the low-level incompatibilities. Frequently the architectural assumptions of a component are implicit; they are seldom documented and often not even acknowledged by the designer of the component.
The authors of the paper, who are software architecture researchers at Carnegie Mellon University, discovered the problem as they were developing Aesop, an implementation platform for experimenting with architectural development environments.
Aesop generates an environment as an open collection of tools built around a shared architectural-design database. The tools execute as separate processes and access the database via remote procedure calls.
Aesop also uses event-broadcast system as a tool-integration mechanism. A tool can register to receive notification of changes to certain database objects; it can also announce important events to other tools via the system.
Example tools include a graphical editor for creating, examining, and modifying architectural design descriptions, managers for the repositories of components, analysis and consistency checking tools, and code generators.
In the design of Aesop, the authors sought to reuse existing components:
The chosen tools seem quite stable; all have been used on several projects. They also seem compatible; all are implemented using either C or C++ with source code available. Thus the task of building an Aesop prototype did not seem to be a massive effort---estimated at approximately one staff-year of work during a six-month schedule.
The authors' rosy development plan failed. The first prototype took five times as long and five times as much effort to get working---approximately five person-years of work during a two-and-a-half-year period. And then the resulting system performed very sluggishly and was very difficult to maintain.
The authors identify six primary difficulties they had in integrating the four components.
For example, the event mechanisms in SoftBench and InterViews are not completely compatible. Since the event communication mechanism was a critical piece of functionality, the code had to be modified for Aesop.
For example, the authors replaced the OBST transaction mechanism by a version that allows the sharing of transactions across multiple address spaces.
What went wrong?
In analyzing the problem, the authors discovered that most of the problems resulted from architectural mismatch. The architectural assumptions made by the various components are in conflict.
To understand the architectural mismatch, it is helpful to view a system as made up of components and connectors.
The authors identify four primary categories of assumptions that can lead to architectural mismatch.
Aesop architecture:
Infrastructure. The pre-existing packages assume they have to provide a large infrastructure, much of which is not needed in Aesop.
For example, OBST provides a large library of standard objects for general purpose programming. The inclusion of these unneeded elements contribute to the code bloat.
Some of the packages make assumptions about the nature of other components in the system.
For example, SoftBench assumes all components have their own GUI interfaces and, hence, have the X library's communication primitives loaded. Thus, to use SoftBench's event system, all other components must load the X library even though they do not need X otherwise---resulting in more code bloat.
Control model. The different packages also make different assumptions about which portion of the system holds the main thread of control.
In particular, SoftBench, InterViews, and the Mach Interface Generator all use event loops to handle communications with other components. Unfortunately, these three are implemented with mechanisms that are incompatible with one another when executed in the same process. For Aesop, the InterViews loop had to be modified to work with SoftBench's X-based events. There was not time to do the modification of the Mach events.
Data model. The packages assume different things about the nature of the data and how it can be manipulated.
For example, Unidraw maintains a hierarchical model for its visual objects and only allows the top-level objects to be directly manipulated by users of the package. Child objects can only be manipulated by their parent objects.
However, Aesop requires that both parent and child objects can be directly manipulated by users. Thus the authors chose to reimplement the hierarchy to get the capability needed by Aesop.
Protocols. The original Aesop design needed two types of connectors: an event broadcast and a remote procedure call (i.e., a request/wait-for-reply interaction).
SoftBench, the chosen tool integration package, supports both types of communication mechanisms. It handles the two more-or-less uniformly by mapping the remote procedure call within the event framework. The remote procedure call is broken into two events---a request and a reply.
Unfortunately, SoftBench's handling of the request/reply pair adds considerably to the complexity of the caller's code. The caller must break its processing of the "procedure call" into two callback routines. The caller must also handle concurrency; it may need to do other processing between a request and the corresponding reply.
To avoid the complications of SoftBench's handling of remote procedure calls, the authors switch to use of Mach's RPC mechanism.
Data model. SoftBench's event mechanism and Mach's RPC assume quite different things about the nature of the data to be transmitted. Mach's RPC supports communication among arbitrary C programs and, hence, supports transmission of C data types. SoftBench assumes that the data transferred will be ASCII strings.
Since the Aesop tools work with general C++ objects, translation between the formats is often necessary. Every call of the database involves a considerable amount of overhead. This developed as one of the most significant performance bottlenecks in Aesop.
OBST assumes that all communications in the system occurs in a star configuration, with itself at the center of the star. It assumes that there is no direct interaction between other tools. It's transaction mechanism is designed to control access and maintain consistency in that type of environment.
However, the Aesop's communication structure is a more general graph and its tools must often cooperate without involving the OBST database. OBST's transaction mechanism can result in deadlock or database inconsistency in this environment.
As a result, the authors found it necessary to build their own transaction mechanism to run on top of OBST.
Several of the packages used assume that there are three categories of code in the system:
However, several of the packages used in Aesop took such an approach. This added a fourth category of code to the above three.
The code in the fourth category makes the build process more complicated and fragile.
For example, to build systems involving SoftBench, OBST, and Mach Interface Generator (MIG), the authors had to "take the output of the OBST preprocessor and specify the resulting procedure calls in MIG's notation, run MIG to generate a server version of the database, and then rebuild all the tools (including rebuilding and linking the SoftBench wrapper code) to recognize the new client interface." ... Doesn't sound like fun to your instructor!
The authors suggest that a long-term solution to the problem of architectural mismatch should have at least the following aspects:
Creation of good documentation is a problem at all levels of design. In the code, the problem is probably more cultural and managerial than technical. For example, good mechanisms exist for documenting code, but they are often not used in practice.
Documentation of the architectural level has the additional problem of having less well-developed concepts, notations, and tools for supporting the documentation. Architectural description languages is an area of current research.
Instructor's note: Part of the authors' research deals with architecture description languages and their formal underpinnings.
In most current systems, the architectural design assumptions are spread throughout the constituent modules. In general, it is very difficult to separate a system into pieces or change the way the components work together.
The principle of information hiding seems just as important at the architectural level as it is at the code level. Architectural assumptions that might change should be hidden (encapsulated) within modules, so that a change in the assumptions would only affect a few modules of the system.
The authors suggest several techniques for alleviating the problems resulting from architectural mismatches.
Some progress is being made in this area. Various systems of design patterns are being recorded and disseminated in books and articles. Architecture- and application-specific software frameworks are being developed.
UP to ENGR 660 Lecture Notes root document?