TOC PREV NEXT INDEX DOC LIST MASTER INDEX



Establishing a Development Process (Apex/Summit)

Note: Information on the development process using Apex/ClearCase can be found in Developing Software using ClearCase and Managing Software using ClearCase. ClearCase with UCM has implemented a software process.

This chapter presents the overall development process that will be the basis for talking about specific Apex capabilities in later chapters. The development process described here focuses on what is needed to support day-to-day development, integration and release. This chapter includes the following topics:


The Problem

To best use the developers, the project needs a development environment that provides stable, protected work spaces for individual developers working on software objects. The environment should support rapid integration and release by:

The environment should also manage source code and architectural information in the same way, because architectural information also changes during development.

Apex Support of Development

The development process is supported by Apex for day-to-day development, integration, release, and variant development.

Views and System Configurations

To build the executables for the system, a consistent set of views will be used. There will be one view from each subsystem. Although any sets of views could be used, it is simplest if the project chooses some naming conventions for choosing consistent sets of views. The project will use the same view name in each subsystem as an indication that those views are intended to work together. For example, the initial task will be to build a first version of the system. The project 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 views is called a system configuration.

Many developers cannot work in a single system configuration. Since changes are constantly being made, there will be few times when everything will compile and execute at the same time. At least one other system configuration that contains a more stable version of each subsystem will be needed. Call this system configuration the base.1.rel system configuration. This set of views will be updated only 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 base.1.rel views for each of the subsystems that they wish to import. The system with these two system configurations and two subsystems is illustrated in Figure 33.

Figure 33 System with Two Subsystems and Two System Configurations


A number of system configurations for different purposes may be needed. 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. For example, each variant may be compiled by a different compiler for a different execution platform.

Apex has the capability to create and manage multiple system configurations. It is not necessary to keep each system configuration; system configurations can be created and populated from the Summit/CM database on demand.

There may be a 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.

Representing the Process

The development process can be represented by a multisystem configuration pipeline whose system configurations represent different development activities. This pipeline supports parallelism in the different software development stages.

The pipeline represents the way in which software objects evolve from development objects to mature released objects as they traverse the stages of the pipeline.

Each system configuration represents either:

1 . A particular activity (which may occur in parallel with other activities) such as development or system integration, or

2 . A well-defined state, such as "released by a developer" or "the current baseline". No activity occurs in such a system configuration; rather the system configuration just represents the fact that the objects in the system configuration are in the designated state.

Software objects start in one system configuration of the pipeline and make transitions to other system configurations under the control of the appropriate personnel.

Development System Configurations

For the purpose of this manual, we define a straightforward pipeline with the following system configurations:

It is possible to add other system configurations for testing, layer integration, etc.

Each system configuration either represents some activity that occurs in the stage or the state of the objects in the system configuration.

Representing the Pipeline in Apex

Library contexts will be used to represent the system configurations of the pipeline. In general, the appropriate library context will be referenced when discussing a system configuration. In addition, "moving" objects into the appropriate library context will indicate making a transition to the system configuration.

For more on views, see Subsystem Structure (Apex/Summit). For Use the File > Copy Object command is used to move objects between stages.The File > Copy Object command is used to move objects between stages. This pipeline is illustrated in Figure 34.

For example, consider a source file that is changed by the user Tom in his working view. When Tom is finished with the view, he moves it into the developer.rel view. When system integration occurs, the source file is moved into the integration view. When the system is ready to be baselined, the source file is moved into the baseline.rel view. When the system is ready to be released, the baseline view is moved into a system release view. The final stage updates the developer working views from the baseline.

The aggregate of the system configurations in the individual subsystems can be used to form a pipeline for the system as a whole. For example, when system integration occurs, all the developer release views in the entire system will be used to update all the integration views.

Figure 34 Development System Configurations Pipeline

Architectural Information

Architectural information defines the relationships between the different components of the system. In Apex these are the Import/Export relationships.

Exports are defined by the export files in each library context. Export files can be placed under source control and will traverse the development pipeline like any other software object.

System Description

The import relationships of a system may be defined in a system description object. System descriptions contain a specification of the relationship between supplier subsystems and Apex/Summit, these must be realized in actual views of the subsystems.

A system description may be placed under source control and may traverse the development pipeline. Note that because the system description applies to the entire system, it will generally be kept in a special subsystem. However, this subsystem will participate in the pipeline like any other.

The Software Development Process

The software development process starts at the very beginning of a project. It includes creating the library contexts. For Apex/Summit, propagating changes from the developer working views. Baseline versions and external releases are generated as needed. The software development process is provided as a high-level overview of the steps that will be discussed in this manual. The process is illustrated in Figure 35 and may include the following steps:

1 . The system architecture is defined by dividing the system into subsystems and the software architecture is created as described in the Chapter Setting Up a Development:

2 . The development environment is established. The details are described in the Programmer's Guide.

3 . Individual developers work in their own working views.

4 . If a team is working on one subsystem, team integration is done.

5 . When developers are satisfied with their changes, the changes are moved into the developer release views, which signifies that they are ready for integration with the rest of the system.

6 . At the start of system integration:

7 . System integration happens.

8 . System integration is declared complete when the system compiles and any acceptance tests have been successfully run.

9 . Rebaselining happens.

If an external release is required, it is constructed as a copy of the baseline.

The later chapters describe Apex mechanisms used to perform the various activities. Incompatible changes and other changes requiring coordination are also discussed.

Figure 35 The Software Development Process


Individual and Team Development

Once the development is setup as described in the previous chapter, Setting Up a Development, development can begin. Large, complex software development projects are typically divided among multiple teams of people working in parallel. The individual and team development process permits developers to work independently and then be able to integrate their changes together. This section shows how to use the version control mechanisms for the development of a single subsystem. Each team develops in working views and moves tested units and files into the integration area.

Rational Subsystems and System Configurations

To build the executables for the system, a consistent set of subsystems will be used. Although any sets of views could be used, it is simplest if the project chooses some naming conventions for choosing consistent sets of views. The project will use the same view name in each subsystem as an indication that those views are intended to work together. For example, the initial task will be to build a first version of the system. The project 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 views is called a system configuration.

Many developers cannot work in a single system configuration. Since changes are constantly being made, there will be few times when everything will compile and execute at the same time. At least one other system configuration that contains a more stable version of each subsystem will be needed. Call this system configuration the base.1.rel system configuration. This set of views will be updated only 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 base.1.rel views for each of the subsystems that they wish to import. The system with these two system configurations and two subsystems is illustrated in Figure 29.

Individual and Team Development Process

In general, each subsystem will be assigned an individual developer. On a day-to-day basis, individuals will develop their subsystems in their own developer working system configuration. The steps in this process are:

Advantages of this Process

The advantages of the Individual and Team Development Process include:

The next few topics address special situations that may occur during the Individual and Team Development Process.

Simultaneous Changes to the Same Compilation Unit or File

If a change needs to be made in a compilation unit or file that has already been checked out, a private check out (Apex/Summit) or an unreserved checkout (Apex/ClearCase) is used. The unit or file is then updated, tested, and the changes merged in with the new version.

Getting an Early Version of a New Unit or File in Another View

Sometimes a change that is in the Developer Release System Configuration is not going to be released right away. If the change is needed by a developer on another development team, the developer makes a local copy of the other library context, updates the imports, and uses the temporary environment until the other library context is updated.

Export Changes

As the software is being developed, integrated, and released, the architecture will also evolve, requiring changes and management. Export changes can easily be managed when the export files are controlled. This also leaves a history (Apex/Summit) or a history log (Apex/ClearCase) of all the export changes and who made each change. Controlling export files is one of Apex's unique advantages.

A typical change to an export requires the following steps:

1 . Check out the export file.

2 . Update the export.

3 . Check in the export file.

System Builds Against Varying Source Bases

Normally, when a program is created during a link operation, the object files that participate in the link are those from the library context containing the main unit or file and from the imported library contexts.

Thus, the source that is compiled as part of compiling the closure of the main unit or file corresponds to code that ends up in the executable. While this is normally desired, there are tasks in working with large systems where this is not the case. For example:

Apex offers the ability to link executables by combining object files from library contexts other than those that were compiled against each other. For Apex/Summit, an object called a configuration file is used to specify the specific views of each subsystem that is to supply object files to the link.

An example is illustrated in Figure 36 using the base.3 system configuration of the avionics system. A developer Jones is building a new version of the radio_packet subsystem. For Apex/Summit, this subsystem has a view jones.wrk. Jones now wants to test the new version that is spec-compatible (i.e. the package specifications and function prototypes have not changed) with the current version in the base.3 system configuration. Jones has two library contexts: one for the new radio packet code and one in which to build the executable to try. What Jones needs to do is to link the executable. Rather than specifying that the object files from the imported library contexts be used, he must specify that object files from radio_packet.ss/jones.wrk (Apex/Summit) or radio_packet.rss (Apex/ClearCase) and the base.3 library contexts be used in the link.

To do this, a configuration file must be created that lists exactly these library contexts. Then the link command is performed specifying that configuration in the Link with configuration field.

Figure 36 Linking Executables


System Integration and Baselining

The previous section, Individual and Team Development, presented the development of a single subsystem. Once at least one subsystem has been through the team development process, the entire system must be integrated. In addition, stable baselines must be created for developers to use. These issues are resolved using the baseline area described in Representing the Pipeline in Apex. This section shows how to move from developing a single subsystem to integrating the entire system.

Integration Strategies

When multiple developers work in parallel on a system, there comes a time when the changes that they make must be brought together and the result run as a whole. Before then, it is desirable to insulate the developers from each other's changes so that individual tasks can be completed without interference from unrelated tasks. Preventing such interference is one of the reasons for creating a full or partial system configuration for each developer or for each task.

Integration System Configuration

A common integration strategy is to have an integration system configuration. When developers are ready to release certain sets of changes, they update the integration system configuration with those changes. Then, the integration system configuration serves as a common base from which to do system builds. The system build itself may be done in a different system configuration from the integration system configuration because developers can update the integration system configuration at any time, and engineers doing the system builds require stability during the build process. This situation is illustrated in Figure 37.

After a build has been completed, developers update their personal system configurations to match the last system build that is considered acceptable.

System Integration and Baselining

In the system integration area, each library context imports other system integration library contexts to allow the entire system to be consistent. System integration and testing is done in this area. System integration is an iterative process. The System Integration and Baselining Process includes:

Figure 37 System Builds with Different System Configurations

There are many variations on this basic theme. Baseline system configurations can be created and updated at various times to provide more of a buffer between system builds and development activities. Communication and updating of development system configurations from other development system configurations occurs at various times so that related changes done by developers can be coordinated and mutually compiled and tested.

Propagating Import Changes

When a system is under development, a number of changes and reorganizations of the architecture may occur. As a result, the import structure may change and you will need to update the imports of the system.

When imports of a library context are updated, the imports of the destination library contexts are replaced by a (possibly modified) copy of the imports of the source library context. The imports can be modified by making them relative to the destination system configuration, similar to what is done when a system configuration is copied by copy operation.


System Release

Once the system is integrated, a software release can be created. A software release can be generated at almost anytime and is typically generated for the following purposes:

Software Release Strategy

Constructing a release of a system is the process of building the various pieces that comprise the system. Since the pieces can be built in any system configuration, Apex does not require that a special system configuration be built for a release. Often, though, there is a desire to retain releases for some time and to make sure they are not modified after they are built.

Informal releases can be built anywhere. In a project where frequent releases are built so that integration and testing are done on a continuous basis, a simple process whereby a release system configuration is reused for each release is desirable. The releases are not retained. The release system configuration can consist of library contexts and, as needed, some development work to get a release to work properly might be done in the release system configuration. This approach is illustrated in Figure 38 .

Figure 38 Personal, Development, Integration, Baseline, & Release System Configs

To build more formal releases that might be retained, numbered release system configurations can be built. For each release, a new system configuration is created and the name of that system configuration in some ways identifies the release. The three levels of access to release system configurations are:

The Software Release Process

A software release can be generated at almost anytime after an integration is successful using the following steps:

Advantages of this Approach

This Software Release Process allows:

Deleting a System Configuration

Once a system configuration is no longer needed, it can be deleted. To delete a system configuration, simply delete each of the library contexts in the system configuration. Be careful because uncontrolled files in the system configuration cannot be recovered by Apex. In Apex/Summit, properties of the library contexts such as their imports and the specifics of the set of versions of objects they contain also cannot be recovered by Apex.


Software Development Process Summary

This section discussed the last step in the Software Development Process. This document has described one method of implementing the Software Development Process. This process should be tailored to the specific needs of each project. The next chapter covers some variations of this process, especially in terms of patch releases and multiple target developments.


Variant Development

In many situations the software development environment must support multiple lines of development and/or releases:

This section presents advanced topics of managing parallel lines of development.

Patch Releases

Problems to be solved in building a patch release include:

1 . A development area and a release area need to be created to make the changes, compile and test them, and then build the release.

2 . The changes to be included may be in files that have since had other changes made to them, and these other changes are not desired in the patch release.

Figure 39 Patch Release System Configuration

The development process will proceed as follows:

1 . A system configuration of library contexts will be constructed by copying the library contexts from the release to be patched.

This new system configuration will have the same contents as the release.

2 . Changes can be developed in the new system configuration and compiled and linked.

3 . When the changes are ready, release views are created from the working views. The name of the release view is the name of the patch release.

4 . The system configuration of library contexts can be discarded once the release is completed.

An Example of Patch Releases

1 . Suppose an avionics_rel_1.2.3 system configuration has been shipped. Sometime later, while development is proceeding on the next major release of the system, the need arises to make a patch release for customers using Rev_1.2.3.rel. The patch release will be called Rev_1.2.3.a. Suppose two subsystems require changes: rudder.ss and math_library.ss. To begin, a working system configuration must be created from the release system configuration. The working system configuration will be called Rev_1.2.3a.wrk.

2 . Next, the development work is done in the new Rev_1.2.3a.wrk system configuration. Editing and version problems may arise. Suppose in math_library.ss, a change is needed in trig_functions.2.ada. The three possibilities are:

Alternative #1: Create a discontinuity in the version sequence.

The principle here is to check out the latest version in Rev_1.2.3.a.wrk (e.g., version 17), and keep the current contents. This creates a latest version that is equal to the version in the Rev_1.2.3.rel release. The changes are made and the file is checked in (e.g., version 18 and 19). The fix is now in Rev_1.2.3.a.wrk. Then, in another view, the version for trig_functions.2.ada is set to the latest version before the last changes were started (e.g., version 17). That version is checked out, keeping the current contents of the file. The unchanged file is checked in (e.g., version 20). This restores the latest version to what it was. If the change going into the patch release is also to go into the main development path, that change needs to be edited back into the latest version as illustrated in Figure 40.

Figure 40 Version sequence of trig_functions.2.ada

Alternative #2: Change the file's history.

The principle here is to sever the development of the affected file so that the main development (in dev.2.wrk, for example) has its latest version and continues unaffected, and the patch release (Rev_1.2.3.a.wrk) has an unrelated history for the affected file and can have a different latest version in its own history. Both can then be checked out and changes cannot be propagated between the views for that file.

Compilation, linking, and debugging can be done in the normal way in the Rev_1.2.3.a.wrk system configuration. When development and testing in the Rev_1.2.3.a.wrk system configuration are completed, the release system configuration Rev_1.2.3.a.rel is constructed using the steps outlined in a previous section.

Constructing Patch Releases with Partial System Configurations

It may not be necessary to construct complete patch development system configurations or patch release system configurations. Release views may be made of only the subsystems that have actual changes. The possibility of doing this depends on the changes.

A minimal system configuration containing only library contexts with actual changes can be used if:

The reason for these restrictions is that recompilation is necessary only in library contexts that exist in the partial system configuration. If a change does not meet these restrictions, files that are clients of the changed specs must also be recompiled and the partial system configuration must contain the library contexts in which they appear.

Patch Release with Minimal System Configuration

Suppose the Rev_1.2.3.a release does meet the above restrictions and the patch release can be built of only those views containing the actual changes. The patch release with a minimal system configuration would be constructed.

Suppose there are two subsystems with changes required: rudder and math_library. New library contexts need to be built for these two subsystems and the executable library context where the executable files are linked. The desired import structure is shown in Figure 41 .

Editing, compilation, and linking is then done in the Rev_1.2.3.a system configuration. When linking is done, a configuration file must be used that lists the Rev_1.2.3. library contexts except for the three views in the Rev_1.2.3.a system configuration. This results in building a system with all of the 1.2.3 code except when there is a 1.2.3.a library context.

The Rev_1.2.3.a release system configuration can be built by copying the Rev_1.2.3 system configuration. Only the three library contexts that were created in the Rev_1.2.3.a system configuration will exist in the release system configuration.

Figure 41 Minimal System Configuration Patch Release

Patch Release with System Configuration Slice

If a spec in a system is to be changed as part of a patch release and the change does not meet the criterion outlined above, the patch release system configuration must include library contexts for all subsystems above the lowest point in the hierarchy where there is a change. (In theory, it really only needs library contexts that contain references to specs that are actually changed, but for simplification, assume this is true of all subsystems in the hierarchy above the subsystem containing the changed spec.) This situation is illustrated in Figure 42.

Figure 42 Patch Release Import Structure When Spec Change Is Present

Suppose there are two subsystems with changes required: rudder and math_library. Also suppose that there is a spec change in rudder that affects code in engine_displays. New library contexts of these three library contexts, and of executable where the executable files are linked, must be created. Development and release then proceeds as in the previous case.

The Patch Development and Release Process

There are many forms of the patch development process. Some are described in the previous sections: Patch Release with Minimal System Configuration and Patch Release with System Configuration Slice.

1 . Start with the library context(s) of the release needed for the patch (e.g., release 1.0.0) where the file(s) already contain conflicting updates for a new version.

2 . Copy the library context(s) to a patch system configuration.

3 . Change the history file of the file(s) requiring conflicting changes.

4 . Update the file(s).

5 . Release the patch release (i.e., 1.0.3).

6 . Merge the patch version(s) with the latest version(s). This is done in the Common History for Apex/Summit.

7 . Release version 2.

Target Variants

A target variant supports more that one hardware platform. It is similar to the patch development and release process, except it has several histories at the start.

Typically, there is one additional version history family file for each target. For example, if a system is being developed to run on both the Sun 4 and RS/6000, there might be version history families for Common, Sun4 and RS/6000 development. The Common history family would group together the history for files that are target independent while the Sun4 and Rs6000 families would be used to group together the history of all the files that are being developed for those particular targets.


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