Using Rose in a Team

Last updated: April. 11, 2006

Objectives: After successfully completing this module, you will be able to

• Define the structure of a model that facilitates a team environment and avoids team development conflicts.

• Identify Rose tools and features that support team development, which allow you to maintain the integrity of your model.

• Use the Rose tool to set up a path map and create a controlled unit.

Team-Based Modeling:

• Rational Rose supports:

  • Controlled evolution of the model.

  • Partitioning of models into architecturally significant units.

  • Reuse of architecturally significant model elements.

• Controlled Evolution:

  • Rose supports architecture-based modeling through the use of UML packages and subsystems.

  • Rose helps users work on low-level design details without affecting the work of others.

    • Specification of architecture-level functionality (interfaces) can be separated from specification of implementation.

  • Rose helps users avoid creating inappropriate dependencies between architectural units.

    • Show Access Violations report supports this.

• Partitioning:

  • In Rose, UML packages/subsystems can be maintained as separate files called controlled units.

Controlled Units:

• Must be packages.

  • Packages:

    • Are a way to group and organize model elements and the smallest architecturally significant units in a model.

    • Are the smallest model elements that can be controlled units.

    • Are designated by a file folder in the UML.

    

    　

• Are files into which Rational Rose stores all or part of the model.

  • The following model elements can be controlled units:

    • Model file itself (.mdl file)

    • Logical View and Use-Case View packages (.cat file)

    • Component View packages (.sub file)

    • Deployment View diagram (.prc file)

    • Model properties (.prp file)

• Are configured  items that a team places under version control.

• Define portions of the model on which individual developers can work.

• Are shared among the team in a team environment

• Allow a project team to develop a model in parallel

• Allow you to load parts of a model, which reduces "startup" latency, resource consumption, and maintains references to unloaded units.

  • A controlled unit can be loaded or unloaded. In Rose, A controlled unit is represented in the browser as follows:

  

  • If a version control system like Clear Case is used, a controlled unit must first be checked out of the system before being loaded.

• Can be write enabled or protected (manually or automatically if a configuration management (CM) system is used).

  • A controlled unit may be write-protected or write-enabled depending on the file's status in the file system.

  • A controlled unit can also be write-protected or write-enabled manually.

  

  • A nested controlled unit, that is, a controlled unit that is contained under another controlled unit, maintains its won write protection independent of its parent.

  • If the controlled unit is write-protected, the diagram toolbar is not visible when you load the unit. You are unable to modify the specifications of the contained model elements.

  • If you use one of the Rose supported version control add-ins, a unit that is checked in to the control system is automatically write protected.

• Even if you are using a version control system, you may want to write-protect or write-enable a controlled unit manually from within Rational Rose. For example, you want to load a checked-in unit, modify it, and save the result to a new file. Or, you simply want to browse a checked-out unit. Manually write-protecting the unit assures that you will not inadvertently change it.

  • After you reload the model, write-protection is no longer applicable, and you will be able to edit the file.

  • Write-protecting or enabling manually does not alter the file's access control in the file system. For example, if you load a checked-in or read-only unit and manually write-enable it in the model, you will not be able to save the unit unless you save it to a new file.

Model Workspaces:

• By defining one or more workspaces, you can set up your working environment in Rational Rose and return to that environment each time you are ready to work.

• A model workspace is a snapshot of all currently loaded con trolled units and open diagrams.

• When you load the workspace, Rose restores the snapshot by loading the specified controlled units and opening the correct diagrams.

• If you are working with large models that are divided into many controlled unit, you will notice even greater productivity gains by using workspaces to load pre-defined units and diagrams.

• A saved Rational Rose model contains the diagrams, elements, and controlled units that make up the complete model. A model workspace contains the actual state of open diagrams and controlled units for a specific saved model at a given point in time.

Virtual Path Map:

•  Let Rose use relative file paths instead of physical file paths when referencing controlled units, freeing your model from its ties to a physical location.

• Allow you to reference controlled units without using absolute path maps.

• Let you move a model between different systems or directories and to update a model from different workspaces.

• Should be set up before creating controlled units and attaching files.

• Should be set up by one person to maintain consistency.

• Are set up differently depending on whether the artifact is being developed, integrated, tested, or archived.

• Using the "&" Symbol:

  • In Rose, the path map reference "&" equals the path to the directory where the current .mdl file or controlled unit is located.

  

  • The use of a consistent path map symbol referenced as "&" makes it possible for all team members to place a Rose model anywhere within their directory structures.

  • This capability is useful when using Rose with a configuration management system like ClearCase, where a user's workspace can be mapped to an arbitrary drive.

• Example:

  • All developers on a team have defined CURDIR = &.

  • Developer A has installed the .mdl file for the model at C:\MyModel and has stored some of the .mdl file's controlled units at C:\My Model\FirstLevel. The children of these controlled units are stored at C:\myModel\ScondLevel. Within the .mdl, Rose will store the paths to the first-level controlled units as $CURDIR\FirstLevel and the children as $CURDIR\SecondLevel.

  • Developer B has installed the .mdl file at D:\TheBigModel. For the .mdl file, Rose will take the internal path of $CURDIR\FirstLevel and will interpret this in terms of where Developer B has placed the model. Rose will expect to find the first-level controlled units at D:\TheBigModel\FirstLevel.

Edit Path Map and Define Controlled Units:

• Edit Path Maps:

  • Open Lab 3_1.mdl

  • File －＞Edit Path Map －＞ Clear －＞ OK

  • Symbol: CURDIR ; Actual Path: & －＞ Add

  • Symbol: LABS ; Actual Path: D:\s??????? －＞ Add

• Define Use-Case Model as a Controlled Unit:

  • Expand Use Case View

  • Right-click Use-Case Model －＞ Units －＞ Control Use-Case Model

  • File name: Use-Case Model

    • Notice you are saving the file as a .cat file.

• Define Actors and Use Cases (under the Use-Case Model) as controlled Units:

  • Expand Use-Case Model

  • Define Actors as a Controlled Unit

  • Define Use Cases as a Controlled Unit

• Load/Unload Actors:

  • Expand Actors

    • View the model elements under Actors

  • Right-click Actors －＞ Units －＞ Unload Actors

    • Notice that the actors in the package are no longer loaded or available in the current model.

  • File －＞Save

  • Double-click Actors to reload the controlled unit.

    • Manually write-protect one of the loaded controlled units.

    • File －＞ Save Model Workspace

      • Note the file extension (.wsp).

Reuse:

• To support reuse, consider the following:

  • Archive significant model artifacts such as patterns and frameworks, and components.

  • Give all team members access to reusable artifacts.

  • Make it easy to catalog, find, and apply these artifacts in a model.

• Organizations gain significant benefits from reusing large-scale design elements like:

  • Frameworks

  • Architecturally-significant packages

  • Subsystems

  • Mechanisms

• Frameworks:

  • A Framework in Rational Rose is a set of predefined model elements that are used to model a certain kind of system and to provide a set of reusable components.

  • In Rose, the Framework Wizard lets you create your own frameworks to capture and reapply entire generic models.

  

Version Control Add-Ins:

• Rose provides two add-ins for version control

  • Version Control Add-In

  • ClearCase Add-In

• Version Control Add-In:

  • The Version Control Add-In provides integration between Rational Rose and any SCC-compliant version control system.

  • Use the Version control Add-In to:

    • Add packages to version control, which you must do before you can check out or check in packages.

    • Check out and check in packages.

    • Start your SCC-compliant version control system.

  • note that this add-in is not available in Rational Rose for UNIX.

• ClearCase Add-In:

  • The ClearCase add-In provides a tight integration between Rational Rose and Rational ClearCase.

  • In addition to the generic commands that the Version Control Add-In provides, the ClearCase Add-In provides:

    • Reserved and unreserved checkouts.

    • Additional ClearCase query and browse commands.

    • Support for managing files generated by the C++ and Ada Add-In.

  • Note that Clear Case must be set up correctly for this add-in to work.

Model Integrator:

• Is a stand-alone tool that can be used to  

  • Compare the differences between Rose models.

  • Merge different Rose models into a resultant model.

• Is especially important if many different users are modifying the same files at the same time (concurrent development).

• Can also be used for a team that may be working on different model components that reside in separate .cat files, but want to periodically merge these files into the base model.

• Should be typically used by a project leader to compare two controlled units and choose the changes to select.

• Works in one of two modes:

  • ClearCase-unaware: It sees models simply as collections of Rose controlled units. This mode is invoked by the user, not by ClearCase.

  • ClearCase-aware: This mode is invoked by Clear Case as the tool to be used to diff/merge ClearCase elements that are of type "rose." Type "rose" is defined as all Rose controlled units (.mdl, .cat, .sub, .prp, and .prc files).