Last updated: 1600 05 August 95 by Jeff Poulin
Software architectures provide many benefits, ranging from documenting a common framework which developers use to build application programs to standardizing a program's approach to reuse and maintenance. A good software architecture serves as the reference and starting point for all software discussions and designs. Because the architecture tells developers how to start building an application it aids in training new developers while at the same time keeping all developers working towards the same ultimate goal.
This overview of the SBIS software architecture first provides an introduction to software architectures. It then applies the general architectural concepts to SBIS. Finally, it introduces the concept of views, or technical perspectives of some aspect of the architecture. This overview takes many of the abstract concepts surrounding architectures and shows how the SBIS program currently applies these concepts through tools and software.
When discussing software architectures we must begin with a brief overview of the work of David Garlan and Mary Shaw [Gar93]. Garlan and Shaw define architectures as consisting of three major items:
We describe the details of the SBIS software architecture in terms of Garlan and Shaw's components, connections, and constraints. First we introduce the components of the application software. These components fall into one of several categories of objects:
In the architecture, connections between objects primarily take place via Remote Procedure Calls (RPCs); however, objects can also embed other objects and can communicate via the database. In conjunction with other software, RPCs allow synchronous communication between the fully distributed objects which comprise an SBIS application. RPC communication establishes a client-server-based relationship between the three type of SBIS objects and gives SBIS developers a flexible method of distributing objects. For example, a developer might distribute objects across machines to improve performance characteristics resulting from high network traffic or CPU loads. A developer might also distribute objects or applications across installations to minimize support costs, or simply use RPCs to request information and services from other locations. SBIS has the strategic objective of using Distributed Computing Environment (DCE) RPCs as soon as an Ada binding to DCE RPCs becomes available.
The extensive list of SBIS rules comprise the constraints upon the software architecture. These rules pertain to the needs detailed in Appendix A of the SBIS Application Software Architecture document. We will discuss the relationship between requirements, needs, and rules below.
To understand the basis of the SBIS software architecture we start by explaining the different classes of software that make up a typical Management Information System (MIS). As explained in the SBIS Reuse Strategy, Most programs make use of a standard set of domain-independent, general-purpose utility software. As shown in Figure 1, this utility software provides a good example of horizontal reuse, or reuse across domains. Most programmers have experience in horizontal reuse by way of mathematical subroutines or I/O libraries. Although horizontal reuse has stable and low risk benefits, these benefits have upper limits of around 20% of an application due to the generally small size and scope of domain-independent software. [SC93].
Vertical reuse, on the other hand, takes place within a domain or a family of related systems. Vertical reuse has a tremendous potential benefit when building many applications within a related area or domain because each application can make use of common objects and operations. As an example of the benefits of domain-specific reuse over horizontal reuse, the estimated reuse potential in the domain of business applications (management information systems) ranges from 75% to 90% [Jon84]. To achieve these levels of reuse an application must make use of domain-specific frameworks and software.
Figure 2 depicts how these three classes of software contribute to the design of the SBIS software architecture. This figure shows what processes might run on a typical SBIS process server. Note we have built Service Objects to provide functions common to "most" or all SBIS applications. All objects in the picture communicate via RPC. The picture shows that if a developer in the software domain of Resource Management needs 8 major functions to build an "Budget" application, 3 of the 8 already exist as reusable Service Objects. Likewise, if a developer of a "Personnel" application needs 6 major functions, 3 already exist.
Note that some objects running on the process server do not directly support either of the two applications. These Service Objects act as servers to all applications, running in the UNIX background environment ready to accept a request for service via RPC from one of the running applications or from a new application. For example, when an SBIS user invokes a new application by double-clicking the application icon on the SBIS desktop, the Process Control Service Object receives the message and responds by establishing the environment needed by the newly-invoked application.
Starting with Increment 2, we will complete a domain analysis of the SBIS domains, such as Installation Management, Logistics, and Personnel. As a result of this analysis we will construct domain-specific frameworks for each domain. Each framework consists of components for use within the domain, rules and interfaces defining how to connect the components, and perhaps tools to help developers assemble applications using the domain-specific components and rules. The framework provides a kind of "mini-software architecture," complete with families of reusable components for use within each domain. We call these components Business Objects. Figure 3 shows that out of the 8 functions required for the Budget application, 3 already exist as pre-built Resource Management Business Objects (shown in green). Likewise, 2 of the 6 functions required for the example Personnel application exist as Personnel Business Objects (shown in blue). It only remains for the developer to provide the glue code to tie all these reusable functions together and to provide any application-unique logic. We call this remaining code Application Objects.
We should note that having an architecture based on these well-encapsulated, reusable objects allows us to both benefit from and contribute to work done in other programs. We can expect to share (both reuse and provide) useful Service Objects and Business Objects from other programs, such as RCAS, JCALS, etc. Figure 4 shows how we might share reusable objects with other sources (the objects shown in red). This could result in significant savings for the Government.
In terms of Garlan and Shaw's architectural styles this architecture represents a hybrid style of distributed processes, data abstraction with object-oriented organization, and layered systems. The use of object-based design with inter-process communication via RPC gives the architecture a distinctive object-oriented flavor and prepares SBIS applications for transition from Ada83 to Ada95 if the program chooses. The use of RPCs also allows for a high degree of data abstraction in the client-server implementation. Because RPCs operate independently of the location of clients and servers we have the potential to distribute the objects across machines and sites. Finally, the use of programming interfaces insulates functional aspects of the architecture, giving a layered systems perspective to SBIS applications. We feel the SBIS architecture uses the best advantages of each of these architectural styles.
Providing opportunities for reuse only begins the list of these advantages. The software architecture implements many of the long-term goals of the Army with attributes that allow it to grow and adapt. The architecture provides:
These attributes give us confidence that the SBIS software architecture will successfully support SBIS applications for the duration of the program.
The entire SBIS program, including the software architecture, must foremost comply with the Open Systems Environment (OSE) standards as specified by the National Institute of Standards and Technology (NIST). The defining documents for these standards largely come from the IEEE POSIX documents as restricted by the appropriate Federal Information Processing Standard (FIPS). As shown in Figure 5, the Defense Information Systems Agency (DISA) has further codified the standards by relating them within a Technical Architecture for Information Management (TAFIM) [TAFIM94].
In the TAFIM, "Mission Area" Applications form a layer on top of the Application Platform, which provides a foundation layer of services for functions such as data management and networking. This layer, in turn, serves as the External Environment Interface through which users gain access to the applications. The TAFIM specifies which NIST and FIPS standards apply for each area in the diagram above. SBIS has committed to supporting these standards as well as their further refinement in the Army C4I Technical Architecture [ArmyTA95].
In the introduction above, the discussion focussed almost exclusively on the "Mission Area" Applications layer of the TAFIM. This layer contains most of the application logic, with Service Objects providing most of the Support Services. For example, in the Support Service area of Communications SBIS provides a Communications Service Object. In the Support Service area of Database Utilities SBIS provides a Data Access Service Object (DASO). In fact, SBIS handles most Environment Management Support Services via Service Objects. Business Objects make up part of the Business Processing Support Service, wth Application Objects comprising the remainder of this TAFIM layer.
Tying the entire DISA TAFIM together requires a comprehensive set of views of SBIS software. Each view represents the concerns of a specific class of SBIS developer or user. The views add the detail necessary to allow the developers and users understand, describe, use, and consistently implement SBIS applications. This architecture document presents four views of the SBIS architecture; they include the:
The views relate to the TAFIM as shown in Figure 6. Each of these views lists SBIS needs that affect the view and explains the important features of the software architecture as those features appear from that view's perspective. As part of the following discussion, we show how we plan to implement many attributes of each view in the SBIS environment with specific tools and software. In the detailed sections on each view we identify any dependencies between each of the views as well as other external influencing factors such as security needs and operational/fielding needs.
This view of the software architecture reflects the perspective of the Ada program, in other words, the logic that implements each application. As shown in Figure 7, the application view contains a total of five application layers, each of which may contain commercial products, OSE services, and SBIS objects. At the top of the figure, the user sees the Presentation layer, which consists of the MOTIF window on the user's X-station or personal computer. Next, the User Interface layer manages and controls the interactions between the presentation layer and the applications. The middle, Application Processing layer, primarily consists of the Service Objects, Business Objects, and Application Objects as explained above. The Data Access layer shields the applications from the logic by abstracting both the location and the physical format of SBIS data so that it appears to the applications as a single, integrated database. Finally, the Data Store layer controls the physical storage of SBIS data using structures such as POSIX files and commercial database products such as the Oracle Relational Database System (RDBMS). Section 4 explains the Application view in detail.
The Data View of the SBIS architecture depicts SBIS applications from the perspective of accessing, storing, and managing information. SBIS has a key feature in that it presents one integrated logical database to the SBIS user. This means that the SBIS user need not enter data more than once and it means that the data will remain valid and secure during its life in the SBIS database. SBIS applications and the SBIS database enforce access controls over who can read and who can update data, based on guidance from Army regulations and functional users. The SBIS applications and database also guarantee data integrity; in other words, once data changes, all users of the data have access to the most recent and consistent information.
The data view includes all aspects of data management as it pertains to SBIS. This means mapping the source of the data in Army legacy systems through logical data models to the final physical store in SBIS. It also includes the SBIS Repository, which contains meta-data about SBIS components such as data elements. All data in the SBIS logical data model comform to data modeling guidelines specified by the Department of Defense (DoD).
As shown in Figure 8, each SBIS installation has an instantiation of the SBIS Integrated Database (SID) implemented in the Oracle database system. Although each SID contains data specific to that installation, each SID instantiation contains the same data structures, database definitions, scheme, and objects. This allows maximum reuse of data management asset, thereby reducing development and support costs.
In addition to the SID, each MACOM headquarters has a SBIS MACOM Database (SMD) to support MACOM operations. As with the SID, each SMD contains the same tables, database definitions, scheme, and objects. The data within each SMD pertains to a specific MACOM.
The process of getting data into the SBIS system requires several steps. As shown in Figure 9, most data enters the SBIS system in accord with System Interface Agreements (SIAs) made between the SBIS program and the owners of a wide variety of legacy systems. These SIAs specify the types, formats, and frequency of data exchange with the legacy system. Legacy data normally enters SBIS at one of the two network management offices (called an ISMCC) where utilities divide the data into packages destined for specific sites. For example, when the bulk information arrives at the ISMCC, it may contain information for all soldiers in the Army. The ISMCC sorts this information into installation-specific files which contain information on only those soldiers stationed at that installation. The ISMCC then sends the files to the appropriate installations.
Upon arriving at the installation, a portion of the External Interfaces (EIS) Service Object consisting of mostly SQL*Loader utilities loads the legacy data into an Oracle Legacy Database. This database serves two main functions. Foremost, it provides a holding place for legacy data until the EIS Object can extract the subset of the legacy data needed by SBIS, convert it to Army Standard Data Elements, and import the standardized data into the SBIS database. The Legacy Database plays a secondary role of allowing users the ability to issue queries against legacy data in its original form.
The EIS completes the import of legacy data into SBIS by extracting, standardizing, and loading the legacy data from the Legacy Database into the SID. Figure 10 shows how the SID consists of separate Oracle tablespaces which contain information specific to a SBIS application. In addition, the SBIS database has a separate tablespace for SBIS "common" tables, or tables containing data shared by two or more applications. A table containing soldier name and address might fall into this common tablespace. Finally, the SBIS database contains a tablespace for shared "reference" tables. These tables differ from common tables in that they contain information such as zip codes and Military Occupational Specialty (MOS) codes that although many applications share, the information does not change often and usually belongs to an agency outside the purview of SBIS (e.g., the Post Office or the Military Personnel Center). Section 5 gives details of the Data View.
The Distribution View shows the distribution options for objects and applications within the software architecture. Each layer shown in the Application View, above, shares an interface with adjacent layers which we specify via well-defined, shared Application Programming Interfaces (APIs). The APIs hide the implementation of each layer from the other layers and handle communication between layers. In most instances the layers communicate via RPC; however, the Data Access and Data Storage layers also make use of the SQL*Net features provided by the Oracle database system.
The SBIS architecture has provisions for distributing application layers, objects within the layers, and entire applications depending on a variety of implementation issues such as performance needs. The use of DCE RPCs will allow for many of these distribution options while helping to obviate problems such as guaranteeing transaction control, authentication of clients in the client-server model, and security of data as it passes along the network. Section 6 details these issues in its discussion of the Distribution View.
Because a developer looks at an architecture and immediately asks "how do I implement this?" we provide a view which tells the developer which tools and methods to use. The Development/Maintenance View of the software architecture details the software development process in terms of component activities of the SBIS Software Development Methodology Plan (SWM) [SWM94]. and the connecting process flows in the SWM. Figure 11 identifies the tools within the SBIS Integrated Software Engineering Environment (ISEE) which support the Development/Maintenance View of this architecture.
Note that the Cadre tools form the backbone of the SBIS ISEE. Starting with application requirements definition, an Ada developer:
The data required for applications undergoes a similar formal development cycle in parallel with and in conjunction with the application code that will use it. A database developer:
In general, the ISEE automates the transition of information among the tools and repositories as much as possible. However, because it cannot make all the transitions totally automatic or seamless, the ISEE documents areas within the ISEE where developers must perform manual tasks and identifies which of these tasks would make good candidates for automation. Section 7 defines the Development/Maintenance View.
The architecture introduced above and described in detail in the sections that follow results from a methodical process. The process aims to capture and document the architectural needs for SBIS and record those needs for the benefit of those persons most affected by architectural decisions. "Needs" differ from "requirements" in that "requirements" derive directly from official contractual documents such as the CAPSTONE. "Needs" come from many unofficial sources such as presentations and briefings.
Providing different views of the software architecture addresses the concerns of specific classes of users but does not, by itself, specify the level of detail that developers need to understand what they must or must not do to implement the architecture. For this reason, each view details a list of rules that tell developers and users of the architecture what they must specifically do to comply with this document. We sometimes refer to this list as the list of "shalls."
The first step in defining the architecture consisted of identifying and agreeing with the Army customer upon a set of architectural needs. From an academic perspective, defining needs seems simple. However, because no one source effectively lists all the influences upon SBIS, the detailing of needs involves an analysis of many different documents, databases, and evolving conceptual approaches within the Army. The SBIS final architectural needs represents the consolidated list of needs as derived from many official and unofficial sources, including:
The list of SBIS architectural needs appears in Appendix A of the SBIS Application Software Architecture document. This list represents what the Army customer and the Loral Contractor agree have appeared in one of the above sources.
Architectural rules provide specific instructions to SBIS developers and users on how to implement the architecture. In effect, these rules become the architectural constraints within which SBIS must operate. Foremost, the rules provide the maximum amount of detail possible relative to general architectural needs. Almost equally important, the rules specify which subset of the needs our developers will implement on SBIS applications currently under development.
The consolidated list of architectural needs outlines a "wish list" of past, current, future, and possible SBIS requirements. Unfortunately, some needs do not have testable or measurable attributes. Some needs have become overtaken by technology or fallen to program updates requested by the customer. Furthermore, the cost or practicality of implementing other needs exceeds the resources and / or schedule constraints of the program. To distinguish between needs which we cannot or do not intend to implement on current Increments, and to prevent developers from having to distinguish between what they must do and what they must plan for later, each architectural view defines a set of rules to which all applications must adhere.
Some architectural needs do not manifest themselves as rules simply because we do not know of a method to test for or quantify the requirement. Other needs will not become rules because of reasons such as inadequate definition, lack of proven technology, and cost of implementation. An appendix lists the architectural needs that SBIS will not incorporate into current increments for reasons such as these.
The culmination of the software architecture comes with its realization in concrete models within the SBIS toolset. Specifically, the architecture provides for the completion of Essential and Architectural models as defined by the Cadre TeamWork terminology and methods. These models provide generic templates from which SBIS applications can begin their definition and development. In fact, the models define the allowable configurations of components, connections, and constraints. In short, applications become instantiations of the SBIS software architecture [Abo93]. The Cadre models fall under the same configuration management and version control requirements of all SBIS products. An appendix to the SBIS Application Software Architecture document presents the architecture model template and defines the rules for application developers to implement an instance of the model for their applications.