Rational Software Corp.

TOC PREV NEXT INDEX


Establishing a Model Architecture and Process for Team Development

The following topics are covered in this section:

Model Architecture and Process

Chapters 4, 5, and 6 of this guide describe fundamental concepts about models, how they are stored, and the tools that you use to manage them. As essential as this information is, it is probably even more important that you and your team develop and implement a sound architecture for layering and partitioning your Rational Rose models, as well as defining a process for managing your model and related artifacts throughout the development cycle.

This chapter provides:

Note: The Rational Unified Process (RUP) provides detailed information about the overall development process and should be one of your primary resources for implementing team development.

Establishing Roles and Responsibilities

This section provides an overview of the typical development roles played by team members in a software project. The organization of the remaining sections elaborate on the logical activities associated with these roles.

Typical Roles

A role is a named behavior of an entity participating in team development, and each role has assigned tasks to complete. There are typically seven roles to consider in your team environment:

Roles Vary Based on Team Size

In a large team environment, several people can be responsible for different team tasks associated with the same role, whereas smaller projects can have only one person responsible for most or all of the tasks for a specific role.

A single person can play multiple roles. A user can perform Architect tasks while working on the initial architecture of the system. Later, they can perform Developer tasks when they are performing detailed implementation. After they make changes, the user can perform Integrator tasks to promote this change to the integration branch of their source control system.

Model Architect

The architect role leads and coordinates technical activities and artifacts throughout the project. The Architect establishes the overall structure for each architectural view, including the decomposition of the view, the grouping of elements, and the interfaces between these major groupings.

Figure 1 Architect Role in Team Development

Model Manager

The manager provides the overall version control infrastructure and environment to the product development team. The manager function supports the product development activity so that developers and integrators have appropriate workspaces to build and test their work, and so that all artifacts are available for inclusion in the deployment unit as required. The manager also has to ensure that the version control environment facilitates product review, and change and defect tracking activities.

Figure 2 Manager Role in Team Development

Modeler/Developer

The modeler/developer is a collective name that represents people who view or modify Rational Rose models.

Figure 3 Modeler/Developer Role in Team Development

Model Integrator

Developers deliver their tested components into an integration workspace where integrators combine them to produce a build. An integrator is also responsible for planning the integration, which takes place at the subsystem and system levels, with each having a separate integration workspace. Tested components are delivered from an implementer's private development workspace into a subsystem integration workspace, whereas integrated implementation subsystems are delivered from the subsystem integration workspace into the system integration workspace.

Figure 4 Integrator Role in Team Development

Source Control Administrators

The Source Control Administrator provides the overall source control infrastructure and environment for all required members of the team.

Source Control Administrator Tasks:

Depending on your team organization, the Integrator role can perform one or more of these tasks.

Configuration Managers

The Configuration Manager provides the overall Configuration Management (CM) infrastructure and environment. The CM function supports the product development activity so that developers, integrators have appropriate workspaces to perform work.

The Configuration Manager must ensure that the CM environment facilitates product review, change, and defect tracking activities. The Configuration Manager is ultimately responsible for a comprehensive plan that identifies and deals with pitfalls to team development in the most efficient way for the project.

Developing a Model Architecture

One of the Architect's primary goals is to structure or organize a Rational Rose model so that it can be used effectively by a team.

Product development often starts with a small team working on a single model. As development progresses, the team (and the model) grow to a point where organizing the model appropriately becomes crucial to supporting multiple teams working in parallel.

An Architect also has a profound impact on developing for reuse. You can use Rational Rose to split a model into highly cohesive layers or frameworks that can be reused in multiple models.

The actual division of a model into packages and subsystems is something of an art form and this chapter attempts to describe guidelines to help you get started. Remember that after a model is partitioned into subsystems, you can either work with one model or split the model into separate models for each subsystem.

Understanding Subsystems

Packages group model elements. There are four types of packages in Rational Rose: use case, logical, and component packages. Each type of package can only group certain model elements. For example a logical package can group classes, whereas a component package groups component diagrams and components. Packages can also contain packages of the same kind, so it is possible to decompose your models hierarchically.

A model is composed of the four root packages: Use Case View, Logical View, Component View, and the Deployment View. The model is the top level model element which contains all sub elements.

A subsystem is a concept and not an explicit modeling element in Rational Rose. The term represents a set of related packages that can be developed, tested, and released together. Subsystems provide strong separation between major portions of your model and form the basis for reuse between models. In a layered development approach, the model for each layer will share in subsystems for the layers beneath it.

A subsystem will typically consist of one or more logical packages and one or more component packages. The logical packages contain the classes in the subsystem and the component packages contain the components that are used to build the subsystem.

By converting packages that provide discrete, well-defined services into subsystems, you are able to control dependencies better. Subsystems expose services only through an interface and subsystem internals should depend only on the interfaces that are offered by other systems.

Figure 5 Subsystems

One Model Versus Multiple Models

A large development project can result in a correspondingly large model for the complete application. If the model has a layered architecture, then it is possible to produce a set of smaller models that follow the layering of the larger model.

One of the goals of having a separate model for each layer/subsystem is to reduce the number of developers working on the same model. This technique helps to isolate development work and reduce parallel development issues.

To build the full project, one designer, typically called the builder, opens a model that references all the subsystems that make up the project, thus loading all the changes made to the packages in the subsystems, then build from that model.

Before splitting a model into a set of subsystem models, you should first consider the trade-offs.

Advantages of a model for each subsystem:

Disadvantages:

The following sections describe steps you should perform before splitting a model to ensure that your model is well partitioned.

Mapping the Architecture to Subsystems

You can decompose a model by grouping modeling elements into packages then assign a set of these packages to subsystems.

You should consider each subsystem as a distinct unit that you can build and test independently, whether or not you will split the model. You will also need to define and enforce the interfaces between subsystems.

Tasks for Decomposing a Model into Subsystems

Tasks for Splitting a Model:

Checking Package Dependencies for Completeness

Developers can define class-level relationships that may violate dependencies between packages and subsystems. After you create packages and move the model elements into the packages (subsystems), ensure that the subsystems you created have the dependencies that you expect. If the dependencies between subsystems are too complex, it may be difficult to work in teams (changes are not isolated) and split the model.

Show Access Violations

Click Report > Show Access Violations to verify that the designed dependencies between packages (subsystems) are correct and complete.

The Architect should revisit the package dependencies periodically to check that the detailed implementation has not violated the intended architecture.

Click Show Access Violations to verify that there are no violations in the logical packages and component packages in the subsystem. You should also verify that every class and logical package referenced by the components in the subsystem are also part of the subsystem.

Determine the External Dependencies for a Package

The Specification dialog box for a package contains a Relations tab that shows the dependencies for this package. You can determine if a package has any dependencies, but it can be difficult to visualize the dependencies if you only look at this list. In order to properly visualize the package relationships, use a class diagram.

To create a class diagram showing the relationships for a specific package, follow these steps:

1 Open the class diagram.

2 If the package is not already on this diagram, then drag it from the browser onto the diagram.

3 Click Query > Add Classes to add all the classes from a package to a diagram.

4 Press Ctrl + A to select all of the classes in the diagram, then click Query > Expand Selected Elements.

5 The resulting dialog allows you to add related elements to this diagram based on the chosen options. To see the direct dependencies for this package, set the options to expand one level of suppliers. Ensure that dependency relations are selected in the Relations dialog box.

By varying the options chosen in these dialogs you can produce a diagram showing the desired information. If many packages were added to the diagram, then you may want to use the automatic layout feature to produce an initial layout for the diagram.

By reviewing the relationships in this diagram, the Architect can detect any undesirable dependencies. Resolving an undesirable dependency can involve either modifying the class(es) that caused the violation and/or moving some of these classes to another package.

Checking if a Subsystem is Self-Contained

A self-contained subsystem is composed of packages that do not have any dependencies to packages outside of the subsystem. A self-contained subsystem can be shared without requiring any other subsystems.

Assuming the package dependencies are complete (see Checking Package Dependencies for Completeness ), then checking whether a subsystem is self-contained means examining the dependencies for the packages in the subsystem to ensure that all of them are to other packages within the subsystem.

A subsystem does not need to be self-contained in order to be shared, as long as the sharing model contains all the other subsystems that are required.

Defining Subsystem Interfaces

By reducing the coupling between subsystems, you can lessen the chance of having integration problems caused by using subsystems that have complex dependencies.

It is important for the subsystem producer to pay close attention to which classes in a subsystem are public (visible and usable outside of the subsystem) and which are private. It is also recommended that the subsystem contain a set of class diagrams that illustrate the public classes.

Best practices include:

You may also use different visual clues (such as color) for the public classes in a class diagram.

Configuring Subsystem Components

Rational Rose can support general types of components such as:

A small model may have a single executable component that is built to produce the application. A large model has an executable component and many library components, typically corresponding to the layering in the architecture.

In addition to the components used to build the complete application, it is useful to have components that build subsets of the model, for example for unit testing purposes.

Components in Subsystems

Ideally, each subsystem contains one or more external library components. These components are built as part of the build process of a subsystem and are referenced in models that use the subsystem.

An external library component allows the sharing model to reuse the prebuilt library, which can dramatically reduce build times for a large model.

A subsystem often includes multiple variations of each component, such as a debug component and a release component. For ease of navigation and organization, group the subsystem components into packages (a Debug package and a Release package) containing the debug and the release components.

The subsystem model requires one or more executable components used to test the subsystem. Typically, the executable component only contains the testing classes and has a dependency on the library component for the subsystem.

The following component diagram shows three components for a sample subsystem. The BaseRelease component is a library that contains the subsystem. The SanityTests and FullRegressionTests components are executables that use the BaseRelease component.

Figure 6 Component Diagram for a Sample Subsystem

After you create the necessary components and the dependencies between them, you must determine which classes belong to which components. Typically, this follows from the architecture of the model, although there can be issues that arise during development. As new classes are created, they must be added to the appropriate component(s). If multiple developers create classes referenced by the same component, then the component can become a source of contention.

The contention for a component can sometimes be avoided, or at least reduced, when the component references logical packages instead of classes themselves. Referencing a package from a component is equivalent to referencing all the classes in that package.

The added benefit is that the component does not need to be updated when a new class is added to the package as long as that class belongs in that component. The risk is that a component may contain classes that it does not require.

Providing Support for Unit Testing

While working within a subsystem model, a developer may find it useful to create a component for use in unit testing changes. If this component has lasting value, then it should be created as part of the subsystem model so that it can be reused. To support the organized storage of unit testing components, an Architect may find it useful to create component packages that can be used for grouping these components.

If many developers create components in the same package, then this package can become a source of contention. If your development process requires the creation and version control of unit testing components, then you may wish to create several component packages used for this.

Using Property Sets for Build Settings

Using property sets for common build settings is a suggested method for maintaining and reusing project level configuration information for building components.

Tasks

Creating Processors and Component Instances

Project Level Processors

For each project, there is usually a known set of processors where component instances execute. Since all the subsystems in the model are intended to execute on this set of processors, these project level processors should be defined in a package shared between the various subsystem models.

The builder should set up a package that contains these project level processors. For example, the builder could configure processors for the labs that are available for the development teams. These package(s) can then be shared in each subsystem model. Each package should be owned by one of the models so that modifications can be made to it in a controlled manner.

The processors in these project level packages will not typically contain any component instances. If they did contain a component instance, then sharing them would also require the corresponding component packages which contain the required components. In turn, these components would require the referenced classes and logical packages. Unless these elements are present in all subsystem models, these processors should only be used as templates in the subsystem models.

Subsystem Level Processors

A development team may choose to create additional processors for their own use, either by copying the project level processors or by creating new processors for platforms that are not shared with other teams.

The subsystem level processors can contain component instances based on the components present in the subsystem. Typically, this includes component instances for regression testing the subsystem and for unit testing major classes in the subsystem.

Component Instances

Component instances indicate the ability to run a specified executable component on a specified processor. A component instance is controlled with the processor. As mentioned above, project level processors usually won't have any component instances so they will are typically copied before they can be used to execute/test a component.

Subsystem level processors will often contain component instances that execute/test the entire subsystem. Developers working on the subsystem can use these component instances but they may find it easier to create specific unit testing components and corresponding component instances.

Tasks

Preparing and Releasing Subsystems

In a model composed of multiple subsystems, there should be policies in place that describe how new versions of the subsystems will be made available to other models.

Subsystem Supplier

When a team is ready to release a new version of a subsystem, they must ensure that the correct version of all the necessary elements of the subsystem are made available. This includes:

The team releasing the subsystem will typically prepare the required elements using one of the following mechanisms:

Subsystem Consumer

The architect for a model that requires this subsystem must then ensure that the model includes the new version of the subsystem. The mechanism for this depends on how the subsystem elements were made available.

If the subsystem elements have been copied to a known location, the architect must ensure that this location is referenced by the model. If the location is the same as the previous version of the subsystem, then no changes should be necessary. If the location has changed, then the architect may have to recreate the model by loading the shared packages from the new locations and adding in the packages that are owned by this model.

If the subsystem has been packaged using a version control label, then the architect must ensure that this label is used for getting the new lineup for the model.

If there are changes to the subsystem interface, then the architect of a model which uses this subsystem must ensure that the corresponding changes are made within their model.

Splitting a Model into Subsystem Models

Splitting a large model into smaller subsystem models can improve team development. A developer can then work on the appropriate model for his or her particular subsystem. Working on this smaller model should reduce the Rational Rose footprint and improve the performance of several operations such as opening a model.

It is possible to split a model before or after it has been placed under version control. If a model has not been controlled, we recommend that you split the model first, then add the resulting controlled units to version control.

Before a model is split into subsystem models, you must ensure that the dependencies between the subsystems will support this partitioning. Specifically, you must ensure that the subsystems form a layered architecture that allow each subsystem to exist in a model that does not contain any of the "higher level" subsystems. See Checking Package Dependencies for Completeness for more information.

Should you Split the Model Before Adding to Version Control?

If your model is not currently in version control, split the model before adding it to version control. If your model is already in version control, you can also split the model into separate models, however, this process is different.

Splitting a Model not in Version Control

At present, we assume that you have a base model (in this example we call it Base) and that the model is not yet in version control. We also assume that you will create separate models for each of your subsystems.

Lastly, this description also assumes that you want to keep the controlled units for each subsystem model together so they can be moved into the subsystem directory tree. Moving the files is optional but it can make it much easier to manage the files that make up each model.

See Dividing a Model into Controlled Units for more information on loading and importing controlled units.

Tasks

1 Ensure that the base model has defined the initial controlled units, at least at the package level corresponding to the subsystem partitioning.

    Note: By default, Rational Rose does not put files in a directory hierarchy.

    The base model (Base) directory hierarchy for the sample model looks like:

    Base.mdl
    <Base>
    UseCaseView.cat
    <UseCaseView>
    <LogicalView>
    SubSystem1.cat
    <SubSystem1> SubSystem2.cat
    <SubSystem2>
    ComponentView.sub
    <ComponentView>
    SubSystem1.sub
    <SubSystem1>
    SubSystem2.sub
    <SubSystem2>
    DeploymentView.prc

    Click File > Edit Path Map to create a Virtual Path Map variable for each top level package in the model (for example, each subsystem package). In our example, we could create path map variables SubSystem1LogicalPkg, SubSystem1ComponentPkg, SubSystem2LogicalPackage, SubSystem2ComponentPkg, and so on.

2 Save the Base model units affected by the new path map variable.

3 If the Base model makes use of custom property sets, then these must be made available to the subsystem models. Click Tools > Model Properties > Export to create a file that can be imported to the subsystem models.

4 Create a new model by selecting File > New. This model will be used for the first subsystem. Ensure that the path map variables are defined correctly.

5 If the Base model makes use of custom property sets, then ensure that these are available in the subsystem model. Click Tools > Model Properties > Replace to import the file containing the property sets.

6 Control all the elements in the new model by clicking File > Units > Control.

7 Save the model (.mdl file) into an appropriate directory by clicking File > Save As. We recommend that you create a dedicated directory for each subsystem. For example, name the subsystem model SubSystem1 and store it in a directory called SubSystem1.

8 Next, you can optionally move the packages that make up your subsystem from the base model directory hierarchy into the subsystem model directory hierarchy that was created when you saved the new model.

    For each package that will be part of the subsystem, move the package controlled units into the corresponding directory level in the new model, and then move the directories for each package to the corresponding location. The resulting directory hierarchy for the new model looks like:

    SubSystem1.mdl
    <SubSystem1>
    UseCaseView.cat
    <UseCaseView>
    <LogicalView>
    SubSystem1.cat
    <SubSystem1>
    ComponentView.sub
    <ComponentView>
    SubSystem1.sub
    <SubSystem1>
    DeploymentView.prc

    If you move the files, edit the associated path maps to reflect the new file locations.

9 Add the subsystem packages into the subsystem model by clicking File > Units > Load. These packages should be added in at the same location in the subsystem model hierarchy as they were in the base model. In our example, SubSystem1.cat should be added to the Logical View and SubSystem1.sub should be added to the Component View.

10 Save the subsystem model.

Repeat steps 5 - 11 for each remaining subsystem with the following addition:

Before adding the subsystem packages to the new subsystem model (Step 7), you must load the packages from the other subsystems that are required by this subsystem.

After splitting the original model, you will typically not use that model for any further development. You may choose to create an equivalent model that shares in all the subsystems. For example, create a new model called NewBase that shares in the packages in SubSystem1 and SubSystem2. This model cannot be used to edit any of the subsystems, but it might be useful for building and/or testing.

Splitting a Model Under Version Control

At present, we assume that you have a base model (in this example we call it Base) and that the model is under version control. We also assume that you create separate models for each of your subsystems.

Lastly, this description also assumes that you want to keep the controlled units for each subsystem model together and so they will be moved into the subsystem directory tree. Moving the files is optional but it can make it easier to much manage the files that make up each model.

See Dividing a Model into Controlled Units for background information that should be understood before proceeding with this task.

Tasks

1 Ensure that the base model has defined the initial controlled units, at least at the package level that corresponds to the subsystem partitioning.

    The base model (Base) directory hierarchy for the sample model looks like:

    Base.mdl
    <Base>
    UseCaseView.cat
    <UseCaseView>
    <LogicalView>
    SubSystem1.cat
    <SubSystem1>
    SubSystem2.cat
    <SubSystem2>
    ComponentView.sub
    <ComponentView>
    SubSystem1.sub
    <SubSystem1>
    SubSystem2.sub
    <SubSystem2>
    DeploymentView.prc

2 Click File > Edit Path Map to create a Virtual Path Map for each top level package in the model (for example, each subsystem package). In our example, we could create path map variables SubSystem1LogicalPkg, SubSystem1ComponentPkg, SubSystem2LogicalPackage, SubSystem2ComponentPkg, and so on.

3 Check out the root packages in the Base model.

4 Explicitly save the Base model units affected by the new path map.

5 Check in the root packages in the Base model in order to save the modified file path information under version control.

6 If the Base model makes use of custom property sets, then these must be made available to the subsystem models. Click Tools > Model Properties > Export to create a file that can be imported to the subsystem models.

7 Create a new model by clicking File > New. This model will be used for the first subsystem. Enable version control for this model by enabling the SCC (Version Control) or the CC add-in using the Add-In Manager. Ensure that the path map variables are defined correctly.

8 If the Base model makes use of custom property sets, then ensure that these are available in the subsystem model. Click Tools > Model Properties > Replace to import the file containing the property sets.

9 Control all the elements in the new model by right-clicking the Model in the browser and clicking File > Units > Control.

10 Save the model in the appropriate local working directory for your version control system clicking File > Save As (for example, /vob/SubSystem1). We suggest that you create a dedicated directory for each subsystem.

    For example, name the subsystem model SubSystem1 and store it in a directory called SubSystem1.

    You may want to add the subsystem model to version control at this stage. For the SCC add-in, click Tools > Version Control > Add to Version Control to ensure that all the controllable units are added. For the CC add-in, click Use Tools > ClearCase > Add to Version Control.

11 You can optionally move the packages that make up your subsystem from the base model directory hierarchy into the subsystem model directory hierarchy created when you saved the new model.

    The actual steps involved in moving the files and directories within version control depend on the version control tool used.

    For each package that will be part of the subsystem, move the package controlled units into the corresponding directory level in the new model, and then move the directories for each package to the corresponding location. The resulting directory hierarchy for the new model should looks like:

    SubSystem1.mdl

    <SubSystem1>
    UseCaseView.cat
    <Use Case View>
    <Logical View>
    SubSystem1.cat
    <SubSystem1>
    ComponentView.sub
    <Component View>
    SubSystem1.sub
    <SubSystem1>
    DeploymentView.prc

    If you move the files, edit the associated path maps to reflect the new file locations.

12 Add the subsystem packages into the subsystem model by clicking File > Units > Load. These packages should be added in at the same location in the subsystem model hierarchy as they were in the base model.

    If you previously added the subsystem model to version control, you must manually check out the root packages that are affected.

13 Save the subsystem model.

14 Use the SCC or CC add-in command Add to Source Control to enter the changes for this subsystem model into version control.

15 We recommend that you create a default workspace for each subsystem model.

After splitting the original model, you will typically not use that model for any further development. You may choose to create an equivalent model that shares in all the subsystems. For example, in our example we could create a new model called NewBase which shares in the packages in SubSystem1 and SubSystem2. This model cannot be used to edit any of the subsystems but it might be useful for building and/or testing.

Managing/Administering a Model

The Rational Rose manager or administrator is responsible for providing the overall version control infrastructure and environment for the development team.

Before starting team development work, the following tasks must be completed:

After these steps are completed, development can start. However, consider these additional responsibilities:

Configuring Compatible Workspaces

To effectively work as a team, each team member should have a consistent workspace for working in a model. The starting point is the model structure created by the model Architect.

The tasks for managing a model include:

Configuring a Version Control System and Repository

Before placing Rational Rose models under version control, there are steps that must be followed to configure the version control system to allow proper integration with Rational Rose. Most of these tasks are performed outside of Rational Rose and require knowledge of the version control tools you use. If you are unsure about the procedures, please see your version control documentation.

Before continuing, please review the tool-specific documentation in Working with a Version Control System .

After reviewing this material, ensure that a repository is properly set up for integration with Rational Rose.

Partitioning the Model into Controlled Units

Controlled units are the smallest Rational Rose model elements that you control via a version control system. Therefore, the packages that are controlled should be selected carefully. For example, it is not always correct to control all the packages. Packages that are controlled units may contain packages that are not controlled units and vice versa. Control the units that provide sufficiently low level of granularity to allow project members to do their work without preventing other project members doing theirs. Ownership of packages and controlled units is very important for effectively working in a team.

For complete details on Controlled Units, see Dividing a Model into Controlled Units .

Because controlled units correspond to files in your file system, only one team member should be allowed to work on a given controlled unit at any one time. While this works well in most cases, there are situations when it is necessary to allow multiple team members to work simultaneously on the same controlled unit. The following procedure can be used to that effect:

1 The current owner of the package of interest creates subpackages for each team member who needs to get involved in the work. These packages can even be named after the team members.

2 Within each package, relocate the elements of the parent package that you want to assign to the different team members.

3 Control the new packages and assign them to their intended owners.

When the work is complete, uncontrol the temporary packages, relocate all elements in them to the original package, and delete the temporary packages now empty. This is a tactical solution to a controlled unit access problem that can be used as required so that package structures and controlled units are not permanently created on an arbitrary or expedient basis, but for sound architectural reasons.

Save Model to Local Work Area

Before placing the model under version control, it must be saved to the local work area. Save the model to the directory you have associated with your version control repository.

Adding the Model to Version Control

The easiest method of adding all applicable units to version control when using the SCC add-in is to click Tools > Version Control > Add to Source Control. When using the ClearCase add-in, you can add units to source control by clicking Tools > ClearCase > Add to Source Control.

Defining Developer Work Areas

The model manager should think about how each worker (developer, integrator, and other team development roles) will work individually and access specific versions (lineups) of a model. This usually involves defining labeling policies.

The model manager should provide guidelines to the rest of the team as to how work areas should be created for each developer. In some cases the manager may need to actually create the work areas.

Defining work areas is tool dependent, and the steps required for setting up a work area for single stream and parallel stream development can be quite different. See Working with a Version Control System for more information.

Creating Labels and Lineups

Labels, and the use of labels to create lineups, are crucial to any successful development strategy. There are many ways to use labels and lineups, though, and the specifics of each are highly specific to each organizations development environment and version control tools.

Manipulating the Version Control Repository

It may be necessary to move or rename files in the repository. This should only be performed by someone who is familiar with the version control tool being used. In many development environments, moving and renaming is always carried out by the version control administrator, who can carry out the task most effectively.

Developing/Implementing a Model

Developers work day-to-day with a subsystem model under version control. Therefore, each developer should be familiar with the material in chapter 6, Working with a Version Control System .

Setting up Version Control

Before using Rational Rose with your version control system, you must perform any tool-specific configuration as described in Working with a Version Control System .

If you have customized Rational Rose to work with another version control tool, then you should ensure that tool is correctly installed on each developer workstation.

Setting up Developer Work Areas

Before working on a version controlled model, you first have to get a specific lineup of controlled units onto your local disk. From there you can start working on the model. Your Version Control Administrator or Integrator will know how to determine the specific label or configuration that should be used to create a local work area. Next, it is a matter of configuring a local work area before running Rational Rose.

Getting a Specific Lineup of a Model

When a developer begins a development task, they must start with the correct version of the model files. The steps involved vary depending on your team development process and the underlying version control tool. For Rational ClearCase, the developer should be using a config spec that defines the view to include the correct versions of the model elements. For Microsoft Visual SourceSafe, your team may be using labels to mark the correct versions and the developer should perform a Get based on that label by using the Label field available from the Parameters... button in the Get dialog box.

Opening a Model Under Version Control

Opening a model under version control is no different than opening a non-version controlled model. In either case, opening the model file or its associated workspace file is the recommended way to load the model into Rational Rose. Default property settings will typically be made available by the Version Control Administrator, see Make default property set available to project members later in this chapter.

Working under Version Control

After your model has been placed under version control, use the following procedures:

Comparing and Merging Model Elements

See Comparing and Merging Models for more information.

Promoting Changes for Integration

When working in a single stream development process, there is no explicit integration step. Instead, submitting changes to the version control repository effectively integrates them with the existing file versions.

Integrating Changes

Integrating changes is highly dependent on the development process being used. The primary goal of the Integrator is to produce an updated lineup of model elements to use as a basis for subsequent development activities. This often involves merging changes from multiple developers (using the Model Integrator) and performing local builds to verify sanity.

Automating Model Validation

Rational Rose provides an automated method to determine if a model is valid. These steps can be incorporated into an automated build process to determine if the code generation and compilation steps of the build should be performed.

Using the Rational Rose Extensibility Interface (REI), you can write a script that:

1 Opens a specified model (using the Application.OpenModel method).

2 Saves the log to a specified file (using the Application.SaveLogAs method).

3 Closes Rational Rose (using the Application.Exit method)

For more information on the REI, see the Extensibility Interface documentation. This script could be invoked as part of an automated build. The automated build script can then search (for example, grep) the log file to determine if any errors/warnings were encountered when the model was opened. If problems were encountered, then the build script can email the log file to the builder. If no problems were encountered, then the build script can continue with the code generation and compilation steps.

Rational Software Corporation  http://www.rational.com
support@rational.com
techpubs@rational.com
Copyright © 1993-2001, Rational Software Corporation. All rights reserved.
TOC PREV NEXT INDEX