![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
System Architecture and Rational Subsystems This chapter presents the concepts associated with software architecture and subsystems and includes the following topics:
- The Problem
- Software System Architecture
- Subsystems
- Subsystem Structure (Apex/ClearCase)
- Subsystem Structure (Apex/Summit)
The ProblemAt 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 ArchitectureThe architecture of a software system defines how the system will do the things it is required to do by:
- Decomposing the system into components
- Defining the relationship between the components
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:
- High-level partitioning reduces the number of components.
- Abstraction/encapsulation reduces dependencies.
- Appropriate partitioning of the software into high-level components provides well-defined interfaces and explicit dependencies.
- Partitioning can simplify the design and localize functionality to minimize change impact.
- Partitioning helps make the system resilient to change and more modular for reuse.
- Changes are made in a controlled fashion leading to iterative development.
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.
SubsystemsSubsystems 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.
- 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:
my_subsystem.rss .Rational/ Compilation/ Exports_Control/ Imports_Control/ Locks_Control/ View_Control Model_Description.cfg View_Properties.prop .Rational_Location (text file containing /<vobs path>/my_subsystem.rss)
Exports/ all_units.exd my_set.exd Imports/ Description.cfg Description.export_sets Mutual_Description.cfg Policy/ Switches comp_unit.1.ada comp_unit.2.ada my_subdirectory/
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:
Specifies the directory that represents the subsystem.
- .Rational
Specifies a directory containing subsystem specific implementation objects used by Apex. In particular, the version control database for the subsystem is stored in this directory.
- .Rational_Location
Text file that contains the canonical name of the Rational subsystem.
- Exports
Specifies a directory containing user files that are part of the export operations.
- Exports/all_units.exd
Specifies a file representing the special all_units export set. This is the default set that is automatically created for you.
- Exports/my_set.exd
Specifies a file containing the program units exported as part of a user-declared export set. There is no limit to the number of .exd files.
- Imports
Specifies a directory containing user files that are part of the import operations.
- Imports/Description.cfg
Specifies the file containing the list of explicit hierarchical imports.
- Imports/Description.export_sets
Specifies the file containing the list of export sets to use for each explicit import.
- Imports/Mutual_Description.cfg
Specifies a file containing views in the same mutual import set.
- comp_unit.1.ada (Ada only)
Specifies the specification part of an Ada compilation unit.
- comp_unit.2.ada (Ada only)
Specifies the body part of an Ada compilation unit.
- my_subdirectory
Specifies a user created subdirectory.
- Policy
Specifies a directory used to store subsystem-specific policy information.
- Policy/Switches
Specifies a file of switches that apply in the subsystem. Use these switches to initialize newly created working views if no model is specified as part of view creation.
- user_files
Subsystem Structure (Apex/Summit)Each subsystem has a structure similar to the following:
my_subsystem.ss/ .Rational/ Version_History/ .Rational_Location -> /parent/my_subsystem.ss Policy/ Switches my_view.wrk/ user_files
The following is a summary of the function of each object:
Specifies the directory that represents the subsystem.
- .Rational
Specifies a directory containing subsystem specific implementation objects used by Apex. In particular, the version control database for the subsystem is stored in this directory.
- .Rational_Location
Specifies a symbolic link that contains the permanent name of the subsystem.
- Policy
Specifies a directory used to store subsystem-specific policy information.
- Policy/Switches
Specifies a file of switches that apply in the subsystem. Use these switches to initialize newly created working views if no model is specified as part of view creation.
- my_view.wrk
Note: Views do not need to reside directly within a subsystem. They can be in a subdirectory of a subsystem:
subsystem.ss/
view1.wrk/
subdirectory/
view2.wrk
view3.wrk- user_files
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.
- Providing a team development environment for managing multiple developers and simultaneous change
- Supporting testing and iterative development
- Making releases
- Controlling dependencies
Views support version control and build management/ compilation activities involving the files in the view. For version control, a view provides:
- A way to specify the desired version for each of the objects in the subsystem
- A way to generate new versions
- Methods to interchange versions with developers working in other views, and ways to limit the interchange when the work of different developers should not be mixed
For development, a view provides the build/compilation context by managing:
- The compiler that will be used to compile the compilation units in the view
- The switches that are used by the compiler
- The visibility to compilation units in other subsystems
- The visibility that the view itself will provide to clients in other subsystems
- All compiler generated files (e.g., object files)
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:
my_view.wrk/ .Rational/ Compilation/ Exports_Control/ Imports_Control/ Locks_Control/ Version_Control/ View_Control/ .Rational_Location -> /parent/my_subsystem.ss/my_view.wrk Exports/ all_units.exd my_set.exd Imports/ Description.cfg Description.export_sets Mutual_Description.cfg Policy/ Switches comp_unit.1.ada comp_unit.2.ada my_subdirectory/
my_view.wrk/ .Rational/ Compilation/ Exports_Control/ Imports_Control/ Locks_Control/ Version_Control/ View_Control/ .Rational_Location -> /parent/my_subsystem.ss/my_view.wrk Exports/ all_units.exd my_set.exd Imports/ Description.cfg Description.export_sets Mutual_Description.cfg Policy/ Switches comp_unit.h comp_unit.C my_subdirectory/
The following is a summary of the function of each object in the view:
Specifies the directory representing the view.
- .Rational
Specifies a directory containing view-specific implementation objects managed by Apex. In particular, this directory contains the version control state associated with the view as well as information related to the importing and compilation mechanisms.
- .Rational_Location
Specifies a symbolic link that contains the permanent name of the view.
- Exports
Specifies a directory containing user files that are part of the export operations.
- Exports/all_units.exd
Specifies a file representing the special all_units export set.
- Exports/my_set.exd
Specifies a file containing the program units exported as part of a user-declared export set.
- Imports
Specifies a directory containing user files that are part of the import operations.
- Imports/Description.cfg
Specifies the file containing the list of explicit hierarchical imports.
- Imports/Description.export_sets
Specifies the file containing the list of export sets to use for each explicit import.
- Imports/Mutual_Description.cfg
Specifies a file containing views in the same mutual import set.
Specifies a directory containing view-specific policy information.
- Policy/Switches
Specifies a file of switches that control operations in the view.
- comp_unit.1.ada (Ada only)
Specifies the specification part of an Ada compilation unit.
- comp_unit.2.ada (Ada only)
Specifies the body part of an Ada compilation unit.
- comp_unit.h (C/C++ only)
- comp_unit.C (C/C++ only)
Specifies the C++ implementation file.
- my_subdirectory
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.wrkThe objects are the same as for subsystems without remote views except for the following:
- remote_view.wrk
Specifies the remote view name that is a symbolic link to the storage directory of the view.
The storage directory of a remote view has the following structure:
my_subsystem.remote_view.wrk/ .Rational/ .Rational_Location -> /parent/my_subsystem.ss/remote_view.wrk Exports/ all_units.exd my_set.exd Imports/ Description.cfg Description.export_sets Mutual_Description.cfg Policy/ Switches comp_unit.1.ada comp_unit.2.ada my_subdirectory/
my_subsystem.remote_view.wrk/ .Rational/ .Rational_Location -> /parent/my_subsystem.ss/remote_view.wrk Exports/ all_units.exd my_set.exd Imports/ Description.cfg Description.export_sets Mutual_Description.cfg Policy/ Switches comp_unit.h comp_unit.C my_subdirectory/
The objects are the same as for a non-remote view except for the following:
- my_subsystem.remote_view.wrk
Specifies the name of the storage directory. The parent of this directory is /storage_parent in this example.
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:
- Use all compilation commands.
- Use some Summit/CM commands, but not control, check out, check in, or delete (of a controlled file).
- Import other release views, but not working views.
- Change the kind of release view from development to stable or frozen.
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:
- Use all compilation commands.
- Use no Summit/CM commands except import and export.
Import and export are allowed so that, if necessary, you can adjust a view's imports before freezing it.
- Change the kind of release view from stable to frozen (or if necessary, from stable back to development).
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:
- Use no compilation commands
- Use no Summit/CM commands
- Import only other frozen release views
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:
- Individual development areas —— Often each developer will have his or her own view of each subsystem on which he or she is working. Developers check out and check in files, edit, compile, and debug using their own views.
- Release processing —— Views can be created that are used for integration or construction of releases of a system. When releasing a system, a consistent set of views of all of the subsystems needs to be built.
- Baselining —— Views can be created to serve as a repository for a specific version of a system or of some subsystems. This might be for a stable version for some clients to use or for testing purposes.
- Variants —— Views can be created to represent variants of a system or subsystem. The contents of files in such a view might be different from the corresponding file (object) in a view for a different variant of the system. Variants might be created to support different hardware platforms.
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.
ModelsA 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 FilesPrototype 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.
SwitchesMany 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. |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |