Jeffrey S. Poulin
Lockheed Martin Federal Systems-Owego
This paper describes the evolution of a software architecture developed for use on very large scale applications in the domain of Management Information Systems (MIS). We documented the architecture in 1995 using the concepts of Garlan, Shaw, Zachman, and others. Describing the architecture using well-established and accepted principles allows us to more effectively apply the architecture to existing programs and to reuse the architecture on upcoming programs. However, new requirements and insights derived from 3 years of software development brought the need for several updates to the architecture. This paper describes work in progress to account for these new requirements and what we call a "dual-baseline" architectural description: the objective architecture we seek to achieve, and the current architecture we actually can implement based on the realities of technology, funding, and other resource limitations.
We have completed and documented a software architecture for use in the domain of Management Information Systems (MIS) [Pou96]. However, our experience with software architectures has shown a fundamental problem of incorporating rapidly changing technology and new requirements into an architecture while at the same time balancing real-life constraints regarding what we can actually implement. We present this paper in two parts. First, we describe our method of architecture description. Second, we describe work in progress to account for new requirements and to clarify the difference between the architecture we want and the architecture we have today.
As explained by Zachman, each of the many broad groups that will use an architecture will necessarily have its own locus of concerns. Abstracting the concerns requires a comprehensive set of what Zachman calls views [Zac87]. Each view represents the interests of a specific type of developer or user. A view shows the detail necessary to help developers and users to understand, describe, use, and consistently implement MIS applications as those details affect their particular area of concern.
We originally described our architecture using four views [Eme95]; they include the:
We describe each view in terms of Garlan and Shaw's components, connectors, and constraints [Gar93]:
This view of the software architecture reflects the perspective of the software developer. As shown in Figure 1, the application view contains a total of five application components, or layers. At the top layer, the user sees the Presentation layer, which consists of the window on the user's viewing device. Next, the User Interface layer manages and controls the interactions between the presentation layer and application logic. The connector to the Presentation layer consists of the native window manager Application Programming Interface (API) on the target computer. The User Interface layer consists of a commercial Graphical User Interface (GUI) development tool as well as an internally-developed API that abstracts certain aspects of the tool for our developers and acts as the connector to the next lower layer.
Figure 1: Components in the Application View
The middle layer, Application Processing, primarily consists of application logic. It connects to the Data Access layer via another API. The Data Access layer shields application logic from data by abstracting both the location and the physical format of data so that it appears to the Application Processing layer as a single, integrated database. It includes a data management API to interface with the underlying commercial database product and shields applications from changes to the product. Finally, the Data Store layer controls the physical storage of data using structures such as POSIX-compliant files [IEEE90]. and a commercial Relational Database Management System (RDBMS).
Constraints that apply to this view tell developers how to configure the components and connectors [Abo93]. For example, constraints related to the Application View include:
We implement the software architecture by providing concrete models within our software development environment. These models provide generic templates from which developers begin their definition and high level application design. In other words, applications instantiate the templates to comply with the software architecture.
Figure 2: Template for the Architecture Logical Model
Figure 2 shows an example of the logical model that implements the layers described in the application view of Figure 1. The five process bubbles in the Figure represent the five layers in the Application View. The user of the system (box in the upper left of the Figure) interacts only with the Presentation Layer, modeled here as "Perform Presentation Services." The Presentation Layer handles all user interface requests (UI_Rqst) and user interface responses (UI_Resp) with the "Perform User Interface Services" function. The User Interface Layer, in turn, handles all application requests and responses (Appl_Rqst and Appl_Resp). The "Perform Application Services" function not only handles all user and data transactions but also has the additional responsibility of communicating with all external devices and systems, as represented by the arcs to the box at the middle right of the Figure. We model the fifth layer, Data Store, as "Perform Data Store Services." This layer connects to the Data Access Layer (via (Data_Store_Rqst and Data_Store_Resp) and physically manages data stored on legacy systems, local file systems and RDBMS, and other remote storage devices.
Experience shows that fielding an architecture takes technology, time, money, and other resources. Furthermore, although our architecture has remained relatively stable for over 3 years, constantly changing requirements and concerns dictate that we revise the architecture to emphasize and accommodate those issues. This section describes work in progress on the architecture introduced above.
As requirements evolve, so must the architecture if the architecture does not already meet the new requirements. We faced new requirements that although forced changes in our implementation technology did not significantly affect the architecture itself. However, we also faced several new requirements and concerns that have forced us to revise the description of our architecture.
For example, as the result of hundreds of daily attacks by unauthorized intruders on federal government computers, we have had a heightened emphasis on system security [Edm96] To support this evolving and increasingly more strict security environment, we will add a fifth Security View. This view will describe the component elements, connectors for authenticated and secure interaction, and authorized constraints on their use in order to achieve and maintain a C2 secure operating environment.
Another new requirement involves the ability to deploy a portion of an application in order to support military units that have partially deployed as part of combat or peace-keeping operations, such as has taken place in Saudi Arabia and Bosnia. In this scenario, called "split-base" operations, we must make an architectural decision on the most efficient method of distributing processing power and data between the home-base and the forward area of operations. Since limited bandwidth communications (e.g., low-grade land-line) present the most critically limited resource, we have examined the ability of our architecture to support various client-server models as defined in the TAFIM [DISA94]. Although the architecture supports these scenarios, we did not have the technology (in terms of software and commercial products) or descriptions in the architecture on how to employ that technology. This has caused us to revise our Distribution View to address various methods of most efficiently distributing application components.
Although our architecture has withstood major changes, the description of the architecture has experienced significant revision. Much of the need for this revision has come from the confusion caused by presenting what we ultimately seek to achieve without distinguishing it from what we actually can implement today. For example, we seek to implement the connectors between the components of the Application View in Figure 1 using Remote Procedure Calls (RPCs). However, no satisfactory implementation of RPC in the Ada programming language exists that will meet all of our constraints. Therefore, although we present the connectors as having a RPC implementation, the current architecture uses conventional compile-time binding (Ada with). Our developers find it difficult to separate the two situations.
To clarify this difference, our current work has set out to distinguish between:
We present each view in the objective architecture using components, connectors, and constraints. We present the current architecture as a set of rules that developers must follow when building applications that comply with the architecture. The rules list the constraints in the objective architecture that we currently implement; constraints that we do not implement remain listed as constraints under the objective architecture. To help understand the use of these rules, we have developed matrices that show the software development life-cycle phase in which each rule applies so we can check for architectural compliance.
This paper presents a long-term experiences working with a software architecture and descriptions of an architecture on a very large MIS system. We have found the use of views, components, connectors, and constraints an effective method for documenting our software architecture. Using this description, we have successfully accommodated most new requirements and technologies without changing the structure of our documentation. However, the resource constraints and program-related realities faced in large system development call for a distinction between the desired architecture and what we can actually implement. Current work involves documenting our software architecture as a "dual-baseline" of the objective architecture and current implementation.
Author Information: Dr. Jeffrey S. Poulin (Jeffrey.Poulin@lmco.com), MD 0210, Lockheed Martin Federal Systems, Owego, New York, 13827. URL: http://www.owego.com/~poulinj