TOC PREV NEXT INDEX DOC LIST MASTER INDEX



System Architecture and Rational Subsystems

This chapter presents the concepts associated with software architecture and subsystems and includes the following topics:


The Problem

At the start of a software development project, requirements and a budget are established. For the project to proceed, the system architecture of the project must be defined.

The system architecture is the top- or macro-level design. It is the logical framework that allocates capabilities and requirements of a system, via high-level components —— such as subsystems and Ada packages (which allow grouping of logically related entities) —— plus the interfaces between those components. But it also is the ongoing evolution and enforcement of that design.

Reducing the complexity of the software structure is key to reducing the complexity of the overall project. The advantages of having a good system architecture include:

1 . Making the system resilient to change

2 . Improving productivity

3 . Providing a framework for staffing and release strategies

4 . Making parallel development more feasible

5 . Providing a framework for integration and testing

6 . Increasing the potential for reuse

7 . Making the overall system easier to learn and understand


Software System Architecture

The architecture of a software system defines how the system will do the things it is required to do by:

Effective system architecture involves understanding the problem domain (why the software is needed) and customer requirements, dissecting those requirements, and then planning and controlling the production of a software system to meet those requirements.

Software systems can be organized into cohesive components with controlled interfaces between them. Each component exports only those portions of the interface that need to be visible to other components. The commands import/export construct is an extension of the class/package model. Imports are similar to withs or includes. Exports are similar to specifications defining which objects are visible outside the package in Ada or which objects are in public in C/C++.

A basic way of simplifying the complexity of a software system is to divide it into a manageable set of high-level components that can be designed and implemented relatively independently. Such decomposition serves to break the problem of designing the system into a set of smaller, more tractable problems. The resulting set of high-level components and the dependencies among them form the structural aspect of the software's architecture.

Software design principles such as modularity, abstraction, encapsulation, and hierarchy exist precisely for the purpose of managing and organizing complexity. The features and benefits of partitioning a software architecture are many:

For example, in an object-oriented design, the logical structure of the software would consist of numerous interrelated classes, each representing the structure and behavior common to a collection of objects. In a design organized around functional decomposition, the logical structure would consist of events and data stores related via data flow diagrams.

In either case, the declarations that realize the logical design objects are grouped among some number of interdependent modules —— packages in Ada and files in C/C++.

Rational recommends adoption of a process that allows early stabilization of the architecture by designing the component interfaces first. Rational Apex defines all systems in terms of subsystems and views.


Subsystems

Subsystems are the fundamental units of organization for software systems in Rational Apex. Each subsystem represents a component of a larger software system that can be developed, tested, and released independently.

Subsystems are used to:

1 . Decompose a system into manageable components

2 . Express component interfaces and controlling dependencies between components

3 . Avoid design degradation by preventing unplanned dependencies

4 . Hide implementation details and promote reuse

5 . Support multiple levels of abstraction by layering subsystems

Subsystems are composed of logical entities called objects. These include the source files, documentation files, and any other files that are being developed within the subsystem. An object in a subsystem typically has multiple versions that represent states of the object at different points in its development history.

For Apex/Summit

Each subsystem maintains a version control database, which is used to manage the versions of the objects. The version control database also provides facilities to coordinate multiple developers working in the subsystem in order to avoid conflicts.

For Apex/ClearCase

You must create ClearCase repositories (VOB(s) and ClearCase views) for your Rational subsystems.See the ClearCase User's Guide for more information.

Example Architectures

A typical architecture that is not broken down into subsystems allows any file to import (with or include) any other file. There is no interface control. Also, any change may affect the entire system. The system may have the architecture illustrated in Figure 2.

Figure 2 A Typical Architecture Without Subsystems

This same system broken down into subsystems allows control of the interfaces and isolation of each subsystem for development. This architecture may look like the system illustrated in Figure 3.

Figure 3 A Typical Architecture With Subsystems

Note:

The Apex interface control mechanism prevents objects in Subsystem A to interface with objects in Subsystem C, and prevents object in Subsystem A from interfacing with any object in Subsystem B, except object D. That is, export and import controls have an object granularity, in addition to a subsystem granularity.


Subsystem Structure (Apex/ClearCase)

Each Rational subsystem has a structure similar to the following:

Note: A Rational subsystem can be created anywhere in a directory hierarchy except in another Rational subsystem —— subject, of course, to normal permission restrictions; however, it must be in a ClearCase VOB to be controlled.

The following is a summary of the function of each object:

my_subsystem.rss

Specifies the directory that represents the subsystem.


Subsystem Structure (Apex/Summit)

Each subsystem has a structure similar to the following:

The following is a summary of the function of each object:

my_subsystem.ss

Specifies the directory that represents the subsystem.


Views (Apex/Summit)

Each subsystem contains a set of views. Each view is an alternative specification or implementation of the subsystem. A view contains actual files that represent the logical objects in the subsystem.

Views are used for:

Views support version control and build management/ compilation activities involving the files in the view. For version control, a view provides:

For development, a view provides the build/compilation context by managing:

Apex also integrates the management of version control with the compilation information in a view to maintain consistency and to reduce the recompilation effects of version control operations.

Each view of a subsystem is either a working view or a release view. Different views are used to represent different stages of the development process.

View Structure

Each view has a structure similar to the following:

Ada Views:

C/C++ Views:

The following is a summary of the function of each object in the view:

my_view.wrk

Specifies the directory representing the view.

Remote View Structure (Apex/Summit)

When a subsystem has a view with remote storage the following structure is created:

my_subsystem.ss/   
 .Rational/  
 .Rational_Location -> /parent/my_subsystem.ss
 Policy/   
  Switches  
 my_view.wrk/ 
 remote_view.wrk => /storage_parent/my_subsystem.remote_view.wrk  

The objects are the same as for subsystems without remote views except for the following:

The storage directory of a remote view has the following structure:

Ada:

C/C++:

The objects are the same as for a non-remote view except for the following:

Working Views (Apex/Summit)

Working views are areas used for development and integration. Typically, each developer has a personal working view that provides insulation from other developers working simultaneously in the same subsystem. However, version control can prevent a user from changing a file that is already being updated by another developer. Working views also provide integration areas when the work of multiple developers must be merged.

Release Views (Apex/Summit)

Release views represent the products of the development process that occurs in a subsystem. To provide flexibility for different methodologies, three different kinds of release views are provided: development, stable, and frozen.

Development View Release

Development view releases can be useful in early stages of product development when limited changes are still allowed. In a development release view, the only source changes allowed are the Control > Update Objects or Control > Update Views command from other views. This limitation permits development releases to be constructed incrementally, but promotes stability by prohibiting in-place editing. Import changes and recompilation are allowed in development release views.

The following activities are allowed in development release views:

Stable Release Views

Stable release views serve as an interim step on the way to frozen release views. In a stable release view, source changes are not allowed, but import changes and recompilation are permitted. Stable release views are appropriate when the source is frozen but import changes might still be required to get a system of release views into its final form. Also a stable release may be transformed into a development release.

The following activities are allowed in stable release views:

Frozen Release Views

Frozen release views are the final step in the release process for views. All characteristics are frozen. All directories and files are read-only. No source changes, import changes, or recompilation are allowed in frozen release views.

The following activities are allowed in a frozen release view:

Changing View Release Kinds

The kind of an existing release view (development, stable, or frozen) may always be changed to a more restricted kind. In particular, the unfrozen kinds (development and stable) may always be frozen in-place after all import and compilation characteristics have been established. Use the remodel command to change the view kind. The allowed transitions between release kinds are defined in the matrix in Table 1 and illustrated in Figure 4

Table 1 Release Kind Transition Matrix
From \ To
Development
Stable
Frozen
Development
no-op
OK
OK
Stable
OK
no-op
OK
Frozen
Error
Error
no-op

Figure 4 Allowed Transitions Between Release Kinds of Views

Interface Views

Any view (working or release) may be designated as an interface view. Interface views contain interface units, such as Ada specifications and C++ header files, but no implementation units. Interface views may be used for releasing third-party software where the user needs the interface information, but the implementation information is not available (i.e., no source code).

For example, company X has an error-processing package called Err. The procedures, functions, and associated data declarations of Err must be available to clients of the package. All this visible interface information would be put in an interface view such as Err.inf. The actual implementation of the package would not be available; only object code to be used in linking would be provided in addition to the interface view.

Use of Multiple Views of Each Subsystem (Apex/Summit)

More than one view can exist in a subsystem, and often does. Each view can be used for a variety of purposes. The purpose is determined mostly by convention, but Apex makes a distinction between a "working" view, in which development is done, and a "release" view that is used to represent a "frozen" release of a subsystem. Views can be used for:

To support variants, Apex allows you to specify the "history name" for each file in each view. Files are considered to correspond only if they have the same view-relative name. Corresponding files may or may not have the same version history. Thus, a history can be created for each platform, and the history of the files that are platform-specific can each be set to the corresponding history. This explicitly marks the files as being unrelated in the version sense. More information on corresponding objects is presented in Corresponding Files.


Models

A model is an Apex view (Apex/Summit) or a Rational subsystem (Apex/ClearCase) that serves as a prototype for another view/subsystem. An Apex view (Apex/Summit) or a Rational subsystem (Apex/ClearCase) is called the library context. When a library context is created, a model is used to specify the initial imports, compiler switches, and directory structure. The model imports are usually the predefined language environment, such as the packages Standard and System in Ada and compiler-defined include files in C/C++.

Usually, the models that are supplied with Apex provide the desired properties. The default model being used is displayed when creating new library contexts. Models are also used to propagate changes from the model library context to the library context that use the model.

Models and prototype files are discussed in detail in the Command Reference.


Prototype Files

Prototype files are files whose contents are used to initialize user files at the time of file creation. The contents of prototype files are a combination of literal characters and keyword replacement symbols. During file creation the prototype files are read and if the prototype files contain keyword replacement symbols, those symbols are replaced by the appropriate values.

All prototype files are found in the directories named by the APEX_PROTOTYPE_DIR session switch. If APEX_PROTOTYPE_DIR is not set, the prototype directory defaults to the directory file_prototypes in the directory defined by the APEX_HOME session switch. If a prototype file does not exist for a particular type of source file, the initial contents of the source file will be empty.

Models and prototype files are discussed in detail in the Command Reference.


Switches

Many characteristics of Apex's behavior are controlled through switches. The two kinds of switches are session switches and context switches. An overview of switches is provided in the Programmer's Guide and a listing of all switches is in the Online Reference.

Context Switches

Context switches apply to commands that are executed in, and objects that reside in, a specific library context. Each subsystem and view (Apex/Summit) contains a switch file —— Policy/Switches —— and that file contains switches that apply only to the library context. The switch file in a library context is used when placing objects under version control, compiling and debugging compilation units, spawning new released views (Apex/Summit), and so on. Details on the format of the context switch file are available in the Programmer's Guide.

For Apex/Summit, the switch file in a subsystem is used to initialize the switch file in a newly created working view when no model is specified as part of view creation.

Session Switches

Session switches are environment variables whose names begin with APEX_. They are set in the same manner as any UNIX environment variable. Session switch names are case-sensitive and are all uppercase. These are variables that must be set before the Apex session begins. An example session switch is APEX_DEFAULT_MODEL, which is the fully-qualified path name of the Apex view (Apex/Summit) or the Rational subsystem (Apex/ClearCase) to use as the default model. Details on session switches are available in the Programmer's Guide.

Property Switches

Property switches, like Context switches, are also associated with a context, which is usually a Summit/CM view (Apex/Summit) or Rational subsystem. They are used by Apex to manage various library context properties, such as those associated with build management.


Rational Software Corporation 
http://www.rational.com
support@rational.com
techpubs@rational.com
Copyright © 1993-2002, Rational Software Corporation. All rights reserved.
TOC PREV NEXT INDEX DOC LIST MASTER INDEX TECHNOTES APEX TIPS