![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
Defining and Creating the Architecture Before you can begin coding, you need to create the subsystems for your system. The architecture of your system defines the subsystem. If you are using Apex/Summit, use also need to create Apex/Summit views. Please see the Concepts Guide for information on architecture and more details on subsystems and Apex/Summit views. The interface between subsystems is controlled via imports and exports. Imports and exports are described in Importing and Exporting.
About This Chapter
The major topics covered in this chapter are:
- Subsystems
- Apex/Summit Views (Apex/Summit)
- Description of Example
- Creating an Architecture
- Information about Views and System Configurations (Apex/Summit)
Some of the topics in this chapter are covered in more detail in Using and Customizing Summit/CM.
SubsystemsApex subsystems are modules, but at a higher level of abstraction in a system. Subsystems support abstraction, encapsulation, modularization, and the reuse of code.
Apex/Summit Views (Apex/Summit)A view contains the files that represent the objects in a subsystem. Each view represents an alternate implementation or an alternate release of its enclosing subsystem.
If files in different views have the same view-relative name, they are associated with the same logical object in the subsystem. Files that are associated with the same object are said to be corresponding.
Each view provides both a version control context and a compilation context to support the development and compilation activities involving the files in the view.
Working Views and Release Views
Each view of a subsystem is either a working view or a release view.
Working views provide areas for the development and integration of software. Typically, each developer has a personal working view that provides insulation from the work of other developers working simultaneously in the same subsystem. Working views are also used to provide integration areas when the work of multiple developers is merged.
Release views contain the products developed within a subsystem during the development process. There are more restrictive rules governing what operations can be carried out in a release view.
Remote View Storage
By default, the storage for a view is located on the same file system as that of its associated subsystem. However, it is possible to place a view's storage in a remote location (that is, different from that of the associated subsystem) by specifying the -storage option when the view is created or by executing the move -storage_only command. When a view has remote storage, its permanent name is not affected; the permanent name is still derived from that of the subsystem.
When a view is remote, the files in a view are stored in a storage directory. A storage directory has a simple name of the form:
<subsystem-name>.<view-name>.<view-extension>
For example, a view with permanent name object_management.ss/tom.wrk would have a storage directory named object_management.tom.wrk. The parent directory of the storage directory would be the directory that was named by the -storage option when the view was created or by the destination parameter of the move -storage_only command.
The directory containing a view's storage directory is called the storage parent. The storage parent is provided as a parameter to commands that set the storage location for remote views. For example, the following command:
%apex create_working -storage /storage sub1.ss/tom.wrk
creates the storage directory sub1.tom.wrk in the storage parent /storage.
It is usually a good idea to provide the storage parent directory with a permanent name using the set_location command.
Views with remote storage can have their storage moved to a different storage parent by re-executing move -storage_only and specifying a different value for the destination. Also, you can change a view with remote storage to use storage in its subsystem by executing move -storage_only and providing the subsystem as the destination.
Use of Multiple Views of Each Subsystem
So far the discussion has been about subsystem decomposition of systems. Apex uses the term "view of a subsystem" or simply "view" to describe the realization of a version of a subsystem. Each view is populated with files that represent the contents of the subsystem. Each file in a view represents a specific version of some "object" of the subsystem.
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.
There are two factors that need to be considered for Apex: NFS/Automounter common naming and distributing the storage space for subsystems and views. Please see NFS Common Naming and Distributing Storage for Subsystems and Views (Apex/Summit).
Description of ExampleThe example for this section is a system that runs avionics on board a commercial airliner. There are many computer systems involved and many performance reliability issues. Flexibility and configurability are issues, as well as long term maintenance.
Presented here is a simplified (and probably not very realistic) analysis of the system. The problem should be intuitive to most readers: the plane has to fly, its crew must talk to the ground, and there are various services on board for the crew and passengers. There are sensors, displays, controls, and actuators that control physical functions.
As a general architecture, this is a distributed, embedded control system. Since there are physical devices involved, some of the structure will be influenced by physical characteristics of devices and interconnections. Still, you want some isolation from physical characteristics since devices will change over the 40 year life of the plane, and you will probably want to use the same software in a subsequent plane. Reusability is therefore an issue.
First, there is separation of high-level functions. For example, controlling flaps as a function is distinct from controlling cabin lighting. Both may use a common substrate to control actuators, read sensors, and communicate across an on-board network.
Second, a basic message-based distributed system architecture can be used. Processes in different parts of the system can send messages to one another to obtain information or control actuators. Since displaying altitude information for the pilot is more important than displaying interactive video entertainment for the passengers, there will be different levels of service in the messaging system. Basic architectural decisions such as these have a significant effect on the structure and operation of the software, and on its flexibility, reliability, reusability, and performance.
Finally, you can abstract device characteristics for most functions. That is, the basic Air-Phone function for passengers doesn't need to know many details of the actual transmission medium and can be programmed against a general radio-packet interface, whereas functions such as airborne radar and collision avoidance are more sensitive to all of their devices and need to be more integrated with them. Thus, many functions on the plane can be implemented to work with certain classes of devices, and the functions and devices can be interchanged with other functions and devices as long as they present compatible interfaces. Other function are highly integrated and need to be implemented, tested, and validated together.
Figure 1 is a sketch of the basic subsystems (or groups of subsystems) that will be present.
Figure 1 Subsystems for the Avionics Example System
![]()
Each of these might be one or several subsystems. Some of these subsystems clearly make use of interfaces for services from other subsystems. Others provide standalone functions. Some subsystems provide infrastructure for the system as a whole and others are vertical applications that solve some specific problem or provide some specific service.
Architecture
There are very general patterns that occur commonly in systems. More than one organization might be applicable to a given system.
Layering
A system can be decomposed into subsystems using layering. Abstractions in the system are placed into a hierarchy based on their use of other abstractions. In the bottom layer are abstractions that are self-contained. In the next higher layer are abstractions that make use of only the layer below them, and so on. Some logical grouping is usually applied as well.
In the example system, you might put Math Functions, Process Management, and Network Drivers in the bottom layer. IPC Communications might be in the next layer, with abstractions for devices in the layer above that. Initialization would be in one of the top-most layers. The layers are illustrated in Figure 2.
Figure 2 Layered Subsystems
![]()
Thus, there is a hierarchy formed based on using relationships between subsystems. These using relationships are embodied by importing relationships between library contexts. In this way, Apex can represent and enforce a hierarchical layered architecture.
Creating an ArchitectureNow you are ready to create the architecture in which to develop our airplane system. Apex/Summit uses subsystems and Summit/CM views. Apex/ClearCase uses ClearCase VOBs, ClearCase Views, and Rational Subsystems.
Since there will be many subsystems, you will not put them all in one directory, but rather create another layer of directories in which to group the systems. This provides an additional level of logical grouping.
Build Keys and Compiler Keys
The meaning of compilation and build management operations in a library context is determined by the setting of the BUILD_KEY or COMPILER_KEY switches in a library context's switch file. Only one of these switches may be set in any library context and the value of the switch that is set will be referred to as the library context's key. If neither switch is set then compilation is not allowed in the library context. The value of these switches is the name of directory which contains information that is used to configure the library context for compilation and other activities. For example, the directory may contain information about the compiler to use and prototype makefiles if applicable.
Setting a Library Context's Key
Because a library context's key is specified by a switch, it is normally set by specifying a model to use for the library context. For example, specifying a model at the time of library context creation usually ensures that the key is correctly set in the new view or subsystem. Similarly, you can change the key by running the remodel command and specifying a new model that has the selected key.
You can also change the BUILD_KEY or COMPILER_KEY switch directly by editing the switch file. When the switch is edited, it takes affect only after the information is re-analyzed by the remodel -refresh command. If the switch has been edited, but remodel -refresh has not been run, the key is considered obsolete and many operations in the library context are disabled.
Obsolete and Deleted Keys
When a library context's key is either obsolete or names a deleted object, a number of operations are disabled in the view/subsystem and its importers. These operations include:
- No compilation can be performed in a library context with an obsolete or deleted key.
- No compilation can be performed in a library context that imports a view or subsystem with an obsolete or deleted key.
- A library context with an obsolete or deleted key cannot be imported.
For some keys associated with the Rational Compilation Integrator (RCI) there are additional restrictions:
- A library context with an obsolete or deleted key cannot be deleted (unless the -force option is specified).
- The remodel command cannot be run on a library context with a deleted key (unless the -force option is used).
Models
A model is a library context that serves as a prototype for another view or subsystem. For example, in Apex/Summit, when the -model option is supplied to the create_working command, the model view/subsystem determines the initial characteristics of the new library context. A model is used when a library context is created to specify the initial imports for the new view or subsystem. These imports are usually the predefined language environment, such as packages Standard and System in Ada and compiler-defined include files in C/C++. The model also specifies the initial values for compiler switches that are stored in the view/subsystem in the Policy/Switches file. Finally, the model specifies an initial directory structure. If you want to have a common subdirectory structure in each new library context, a view or subsystem with this structure can be created and then used as a model when creating other library contexts.
Usually, models are supplied with Apex that provide the desired properties. The default model to be used is displayed in the dialog when creating new Summit/CM views (Apex/Summit) or Rational Subsystems (Apex/ClearCase). A pop-up list of all known models is also available from which to choose a model. Since any library context can be used as a model, the pop-up menu does not list all possible models, just the standard Apex-provided models.
When a model is supplied for the creation of a new library context, the following characteristics are inherited from the model:
- All imports except for mutual imports are set in the library context.
- All the switches in the model's switch file are set in the library context.
- The directory structure of the model is duplicated in the library context.
When you apply a model as part of a copy operation or through the remodel command, the following characteristics are changed:
- All imports except for mutual imports are set in the library context and any imports not in the model are removed.
- Some switches are changed as specified by options to the command.
- Directories in the model which are not in the library context are added to the view or subsystem.
The properties command displays the last model applied to a library context.
Ada Models (Ada only)
Rational supplies a number of standard Ada models which can be used depending on your requirements. Ada models have the following construction. Table 1 contains a description of each of the components used to construct a model.
<HOST>.<TARGET>.<Ada VERSION>.<RTS TASK>.<IMPORT>.<MATH>.<VERSION>
C/C++ Models (C/C++ only)
Rational supplies a number of standard C/C++ models which can be used depending on your requirements. C/C++ models have the following construction. Table 2 contains a description of each of the components used to construct a model.
<HOST>.<Apex VERSION>
(standard build key, Apex C/C++ compiler)
<HOST>.<Apex VERSION>.<COMPILER_KIND>
Table 2 contains a description of each of the components used to construct a C/C++ model.
Table 2 C/C++ Model Variants
HOST Control
The first element of the naming describes the host and target computer and OS, for example, sun_solaris2. This is the value of $APEX_ARCH. Names are self-explanatory.
Apex VERSION Control
This field has the Apex version number, including patch level. Names are self-explanatory.
COMPILER_KIND Control
Indicates the C++ compiler. There are several alternate ways of indicating the compiler.
<COMPILER_KIND> =>
<ckind> (standard build key)
<ckind>.local (standard build key)
<ckind>.<skind>
<ckind>.<skind>.local
The following table entries indicate values for each of these fields.
<ckind> HP
DEC
SPARCompiler
generic
java
migratedoes not supply a CPP_COMPILER_HOME
JAVA_HOME
Uses architecture-specific .migrate key; used for integration of library contexts not yet migrated to Apex
<skind> java
orbix
oodceJAVA_HOME, standard build key)
IDL_HOME, orbix build key
IDL_HOME, oodce build key
local Provide appropriate default _HOME and _OPTIONS values in Policy/Switches. For example,
sun4_solaris2.3.2.0.SPARCompiler.java.local.rel/Policy/SwitchesCPP_COMPILER_HOME: /venodr/SUNWspro/SunOS5-4.1/SC4.0
JAVA_HOME: /usr/apps/COPTS/jdk1.1.1
SIENNA_HOME: /sierra/products/base/c++/compilers/sun4_solaris2.2.1.1a
If local is not specified, the CPP_COMPILER_HOME and JAVA_HOME switches are not set. In this case, the user must fill in the appropriate locations for the _HOME variables (except for SIENNA_HOME.) For example,
sun4_solaris2.3.2.0.SPARCompiler.java.rel/Policy/SwitchesCPP_COMPILER_HOME: nil
JAVA_HOME: nil
SIENNA_HOME: /sierra/products/base/c++/compilers/sun4_solaris2.2.1.1a
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.
The APEX_PROTOTYPE_DIR switch is actually a path of directories, each separated by a colon. The directories are scanned, in the specified order, for the required prototype file. The scanning is stopped when the prototype file is found.
The directories containing customized prototype files should appear early in the path. The installed Rational prototypes should always be in the path, usually as the last directory. This ensures that the installed prototype files are used by default unless overridden by customized prototype files.
Ada Prototype Files
There are two types of Ada prototype files: file-oriented and unit-oriented.
Ada File-oriented Prototype Files
Ada file-oriented prototype files provide text that is filled in at the beginning and the end of each Ada source file, regardless of the type of unit (for example, a procedure, function, package, or task) being created in the file.
For example, you can use file-oriented prototype files to provide common header information that should occur in every program unit file. The following Ada file-oriented prototype files can be provided:
Ada Unit-oriented Prototype Files
Ada unit-oriented prototype files are used to specify the initial content of Ada units based on the type of unit being created (as derived from the -part and -unit options provided to the create_ada command). The unit-oriented prototype information is inserted in the file between the appropriate head and tail file prototypes.
The following unit-oriented prototype files can be provided:
C/C++ Prototype Files
There are two types of C/C++ prototype files: file-oriented and unit-oriented.
C/C++ File-oriented Prototype Files
File-oriented prototypes provide text that is filled in at the beginning and the end of each C or C++ file. For example, you can use file-oriented prototypes to provide common header information that will occur in each file. The following C and C++ file-oriented prototypes can be provided:
C/C++ Unit-oriented Prototype Files
Unit-oriented prototype files provide a way to initialize header and source files when you are creating a new class, class template, function template or main program.
Customizing Ada and C/C++ Prototype Files
Standard prototypes are placed in the $APEX_HOME/file_prototypes directory. When creating an Ada or C/C++ file, Apex finds the prototypes by using the APEX_PROTOTYPE_DIR switch.
The prototypes can be customized by changing them directly in the original directory or preferably by copying them to another directory, changing them there, and adding the new directory path to the APEX_PROTOTYPE_DIR switch.
Note: Always make backups of the original files. Usually two or three prototypes are used to create one body or specification file for Ada or C/C++. For example, to create a body file "Class.C" for a C++ class with the File > New > New C++ (Class, Implementation) dialog, the following prototype files were used:
- proto.head.source
- proto.class_body
- proto.tail.source
Miscellaneous Prototype Files
There are a few additional templates for other Apex files, including:
Switches Used to initialize the switch file in subsystems.
Session Switches
The following session switches apply to models and prototype files:
- APEX_PROTOTYPE_DIR: directory-paths...
Specifies the names of directories in which to find prototype files. The value of this switch is a list of directory names separated by colons:
Default value: <established during product installation>Creating Subsystems (Apex/Summit)
This example uses the avionics example described in Description of Example. It creates a directory for the project, subdirectories to group related subsystems, and the subsystems themselves.
- 1 . You create the directory /projects/avionics. It needs to be NFS accessible under the same name to all workstations and have a Permanent Name assigned. See NFS Common Naming for details.
- 2 . You create directories on various file systems that will hold the storage for these subsystems and their views. These directories also need to be NFS accessible and have a permanent Name assigned. See Using and Customizing the GUI
for details.You create the directories for the groups of subsystems. This would not be required for all projects. You choose to do it here for clarity in this specific project. If you were not creating this extra level of directories you would place all subsystems in /projects/avionics. The directories to create are:
/projects/avionics/passenger_cabin
/projects/avionics/cockpit
/projects/avionics/ip_communication
/projects/avionics/os_interface
/projects/avionics/ground_communications
/projects/avionics/flight_control
/projects/avionics/navigation
- 3 . You click File > New > New Subsystem to bring up the New Subsystem dialog box.
- 4 . Fill in the name of the first subsystem to create, for example:
/projects/avionics/passenger_cabin/passenger_seat_console.ss
You fill in the storage location as needed.
Since you will be creating a number of subsystems, click Apply to keep the dialog box open.
- 5 . Once the create is started, edit the name for the next subsystem to create, for example:
/projects/avionics/passenger_cabin/video_library.ss
- 6 . Click Apply, and continue until all subsystems are created.
Creating Rational Subsystems (Apex/ClearCase)
This example uses the avionics example described in Description of Example. It creates a directory for the project, subdirectories to group related subsystems, and the subsystems themselves.
- 1 . You create the directory /projects/avionics. It needs to be NFS accessible under the same name to all workstations and have a Permanent Name assigned. See NFS Common Naming for details.
- 2 . You create directories on various file systems that will hold the storage for these subsystems. These directories also need to be NFS accessible and have a permanent Name assigned. See Using and Customizing the GUI for details.
You create the directories for the groups of subsystems. This would not be required for all projects. You choose to do it here for clarity in this specific project. If you were not creating this extra level of directories you would place all subsystems in /projects/avionics. The directories to create are:
/projects/avionics/passenger_cabin
/projects/avionics/cockpit
/projects/avionics/ip_communication
/projects/avionics/os_interface
/projects/avionics/ground_communications
/projects/avionics/flight_control
/projects/avionics/navigation
- 3 . You click File > New > New Subsystem to bring up the New Subsystem dialog box.
- 4 . Fill in the name of the first subsystem to create, for example:
/projects/avionics/passenger_cabin/passenger_seat_console.rss
You fill in the storage location as needed.
Since you will be creating a number of subsystems, click Apply to keep the dialog box open.
- 5 . Once the create is started, edit the name for the next subsystem to create, for example:
/projects/avionics/passenger_cabin/video_library.rss
- 6 . Click Apply, and continue until all subsystems are created.
Views and System Configurations (Apex/Summit)
In a system such as the avionics example where there are many subsystems, there will be many views to create, at least one per subsystem. Views can be used for many purposes.
To build the executables for the system, you will need to use a consistent set of views, one of each subsystem. Although any views could be used, it is simplest if you choose some naming conventions for choosing consistent sets of views. You will use the same view name for each subsystem as an indication that those views are intended to work together for a common purpose. For example, the initial task will be to build a first version of the system. You can name each view for this purpose rev.1.wrk. There will be a view named rev.1.wrk in each subsystem and that is where units will be created, edited, compiled, and debugged.
Such a consistent set of subsystems is called a system configuration. Note that in previous versions of Apex, system configurations were known as "towers". In this case the set of views in the rev.1 system configuration is identified by the pathname:
/projects/avionics/*/*.ss/rev.1.wrk
This wildcard name will match many views, about 25 - 50 in the avionics project example.
It should become clear quickly that you cannot have many developers working all in a single system configuration. Since everyone is constantly making changes, there would be few times when the system would be in a state where everything will compile and be executable at the same time. At least another system configuration that contains a more stable version of each subsystem will be needed. Call this system configuration the stable.1.rel system configuration. This set of views will only be updated at specific times to be decided by the project management team. Developers who want to compile and run against a more stable base of software would use the stable.1.rel views for each of the subsystems that they wish to import.
You can see that there may be need for a number of system configurations for different purposes. Each system configuration represents a version of the entire system that can be compiled, run, debugged, and tested. There may be one or more system configurations for the testing group and the validation group. There may be system configurations for each variant of the system as well, each variant may, for example, be compiled by a different compiler for a different execution platform.
Apex gives you the capability to create and manage multiple system configurations. It is not necessary to keep each system configuration you might want. System configurations can be created and populated from the Summit/CM database on demand.
It may also be the case that there will be the need for personal system configurations for each developer or each development group. If a group has its own system configuration it has complete control over changes in that system configuration. Consequently, the group's work is then insulated from changes being made by the remainder of the development team. On the other hand, the group can fall behind the rest of the project by not keeping in sync with changes going on elsewhere in the system.
For this avionics problem, lets use the following conventions for view names (and hence system configuration names)
To start with, you will create the rev.1.wrk, stable.1.rel, and int.1.wrk views for each subsystem now. If there is a need for personal system configurations or group system configurations, they can be created when that need arises. You will also defer creating system configurations for test groups until the system is more mature and there is something to test.
Creating Summit/CM Views (Apex/Summit)
You now want to create three views in each subsystem. You could simply create each view using the File > New > New View menu command. For each view you would:
- 1 . Fill in the simple View name.
- 2 . Fill in the Subsystem name.
- 3 . If there is no default model, or another model is desired, fill in the Model field with the specific view to be used as a model if you made one, or else use one of the predefined models from the Model field alternatives pop-up menu.
The model in general must be chosen to provide support for the desired target platform architecture, operating system, and compiler.
- 4 . If you had decided to place storage in a specific UNIX file system, then click Place storage in directory and fill in the directory name.
- 5 . Turn off the Visit the new view toggle, since you are creating many views, you probably don't want a viewer window created for each one.
- 6 . Click Apply to create the view.
You will set up imports in the next section.
Since you will be creating many views and then setting up imports between them and doing this for each of the three system configurations, you can reduce the labor somewhat by creating a single system configuration, setting up imports in that system configuration, and then copying this first system configuration to create all of the views in the other two system configurations you want to create. The next section describes the process of setting up and maintaining import relations between the views. The following section describes copying a system configuration.
Assume that you create all of the views of the rev.1.wrk system configuration and you will then setup its imports and then copy it to create the stable.1.rel and int.1.wrk system configurations.
Copying an Existing System Configuration (Apex/Summit)
Once the rev.1.wrk system configuration has been set up, you can create additional system configurations by copying it.
The File > Copy Object menu command brings up the Copy Object dialog box, which provides facilities to copy objects. This dialog box supports the copying of a set of source objects to a destination object or directory. It also supports specialized copying operations such as copying multiple views or a system configuration. In the dialog box, click the Copy Views button to use the specialized system configuration copy operations. The dialog box becomes larger and displays the relevant operations.
To copy a system configuration, follow these steps. (In this example, you will copy the dev.1.wrk system configuration to create the int.1.wrk system configuration.)
- 1 . Choose File > Copy Object to bring up the Copy Objects dialog box.
- 2 . Click the Copy Views button.
- 3 . Add the list of views to be copied to the Source Views list.
/projects/avionics/*/*.ss/rev.1.wrk
- 4 . Click Add or press Return.
Note: If there were any objects listed in the Source Views list field when the dialog box was first brought up they should be removed by selecting them in the Source Views list field and clicking Remove.
- 5 . In the Destination area, click Destination Name is subsystem-relative name.
- 6 . In the Destination area, enter int.1.wrk in the Name field.
- 7 . To copy the system configuration, click OK or Apply.
You can repeat these steps for the stable.1.rel system configuration.
Note: The views you copied were importing other views in the rev.1.wrk system configuration. Conveniently, when you copy a system configuration using the Copy Object dialog box, imports are automatically updated to reference the new, copied view. Thus, at this point, the imports in the int.1.wrk system configuration are referencing other views in the int.1.wrk system configuration, not the views in the rev.1.wrk system configuration that the views that were copied referenced.
More on the Copy Objects Dialog Box (Apex/Summit)
The right-hand side of the Copy Objects dialog box provides a number of options for changing the characteristics of views while they are being copied. Strictly speaking, all of these options are redundant in that the changes they make could be made using another Apex command after the copy is made. However, there are tremendous performance benefits to be gained by making some of the changes as part of the copy operation. This is why the Copy Object dialog box is so large and complex.
For example, suppose you want to change the storage location. You could copy the view and then use the Control > Maintenance > Move Storage command to move the storage for the new view. But this would require first making a complete copy in the wrong location and then moving all of the files to the desired location, a significant amount of extra work for a large view. If you fill in the storage location in the Copy Objects dialog box, then only a single copy will be made with the storage ending up in the desired file system. When copying a large system configuration, this combination could save many hours.
Information about Views and System Configurations (Apex/Summit)For more information on Summit/CM including the check out command, see Using and Customizing Summit/CM and the Command Reference.
Finding All Checked-Out Units or Files in a System Configuration
To find all units that are checked out in a system configuration, follow these steps. In this example you will find all checked-out units in the avionics rev.1.wrk system configuration.
- 1 . From a directory-viewer window, choose Control > Show > Objects.
The Show Objects dialog box is displayed.
- 2 . In the Add field of the Contexts list, enter the names of the views to check and click Add.
In this example, you enter /projects/avionics/*/*.ss/rev.1.wrk.
- 3 . Check the Checked In and Uncontrolled check boxes so that only Checked Out is set (as illustrated in Figure 3).
Figure 3 Show Objects Dialog Box
![]()
- 4 . Click OK to run the query searching for checked-out units. An Objects viewer window should appear with the results as illustrated in Figure 4.
Figure 4 Objects Viewer
![]()
From the Objects viewer, you can, for example, select all the objects (which are checked out in this example) and check them in. This is a good way to find all objects in your system configuration that need checking in. You can then check them in prior to updating the integration system configuration from your system configuration.
Finding All Out-Of-Date Units or Files in a System Configuration
The sequence for this is the same as Finding All Checked-Out Units or Files in a System Configuration, except that the Out Of Date check box is set and the others cleared.
Finding All Importers of a View
To find import references, follow these steps. You must know the range of possible views that might import the one you are asking about. In this example, you look for imports of math_library.ss/rev.1.wrk in the avionics system rev.1.wrk system configuration.
- 1 . Choose Control > Show > Importers.
- 2 . In the resulting dialog box, enter the name /projects/avionics/navigation/math_library.ss/rev.1.wrk in the View field.
- 3 . In the Scope field entry field, enter /projects/avionics/*/*.ss/rev.1.wrk and click Add
- 4 . Click OK or Apply to show all importing views.
Finding All References to Something
To find source code references without semantic information, follow these steps. You will perform a textual search over all files. In this example, you will look for references to Sin in all of the avionics system rev.1.wrk system configuration.
- 1 . Choose Tools > Grep.
- 2 . In the resulting Grep dialog box, enter Sin (the search string) in the Pattern field.
- 3 . In the Objects to search for the pattern text entry field, enter /projects/avionics/*/*.ss/rev.1.wrk and click Add.
- 4 . Click OK or Apply to perform the search.
Comparing Views
To compare the contents or characteristics of two views:
- 1 . Choose Control > Show > View Comparison.
- 2 . In the resulting Compare Views dialog box, enter the name of the first view in the Compare Views field.
- 3 . Enter the name of the second view in the Compare with views named field.
Note: You can compare various characteristics. The Characteristics to Compare option menu controls this.
- 4 . Click OK or Apply to run the comparison and display a window showing the differences.
Lists of Views and the Views Viewer
When working with a number of views, it is sometimes helpful to have a viewer window listing some or all of the views in your system configuration.
- 1 . Choose Control > Show > Views.
A Show Views dialog box is displayed.
- 2 . Enter the names of all of the views in the view list. For example, enter /projects/avionics/*/*.ss/rev.1.wrk in the Add text field and click Add.
- 3 . Click OK or Apply to create the views window.
A number of operations are then available in the views window. It is easy to bring up windows on any particular view, create control objects, and so on. Some or all entries in the views window can be expanded using View > Expand to show the objects in the view. For more information, see Using and Customizing the GUI.
Rational Software Corporation http://www.rational.com support@rational.com techpubs@rational.com Copyright © 1993-2002, Rational Software Corporation. All rights reserved. |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |