The document discusses team development using Rational Rose and configuration management. It describes how to: 1. Create controlled units to partition the model and place components under configuration control. 2. Define an integration workspace and developer workspaces using a configuration management system like ClearCase. 3. Determine which model components should be controlled units and provide access to configuration management tools within Rational Rose.

1. Introduction to Rational Rose 98i Module 10: Team Development

2. Objectives: Team Development You will be able to: Create controlled units to facilitate team development Discuss a team development process

3. What are Controlled Units? A controlled unit is an entity that may be placed under configuration control The model itself, packages, and the deployment diagram may be made controlled units in Rose When the model is loaded, the individual controlled units are loaded only when they are needed Reduces “startup” latency Reduces resource consumption Maintains references to unloaded units

4. How Are Controlled Units Stored? Controlled units are stored in files, using specific filename extensions to designate their contents Example controlled units Model itself ==> .mdl Logical packages ==> .cat Component packages ==> .sub A Rose .mdl file references controlled units (if they are in use)

5. Sample Model File .mdl file .cat file .cat file .cat file .cat file .cat file .cat file

6. Designating Controlled Units

7. Showing Unit Visibility on a Diagram U means the package is a controlled unit

8. Loading and Unloading Controlled Units When a model is opened in Rose, the user is asked if all units should be loaded Rose maintains references between components in unloaded units and components in the model The references are automatically resolved when the unloaded unit is loaded Unloaded components may be adorned with an icon to show that they are not loaded The adornment is an octagon containing the letter M with a slash through it

9. Loaded/Unloaded Units in the Browser Unloaded unit Loaded unit

10. Unresolved Reference Adornment

11. Unresolved References Specification information for unresolved references is not available Once the package containing the unresolved references is loaded Specification information is available The adornment is removed from the model

12. Write-protecting Controlled Units A controlled unit may be write-protected A nested controlled unit maintains write-protection independently of its parent If a controlled unit is write-protected The drawing palette is grayed out on all of its diagrams The capability to create a new attribute or operation is removed Rose will automatically make a controlled unit write-protected if the file is read-only

13. Integrating Rose with a CM System Rose may be integrated with many commercial configuration management systems On Windows, the chosen CM system must be SCC compliant Some popular configuration management systems ClearCase SourceSafe PVCS SCCS RCS

14. Rose Model Integrator The Rose Model Integrator allows you to compare, discover differences, and merge up to seven different files. The files you can compare are: Multiple versions of the same file Unrelated models Any combination of model files (.mdl) and subunit files (.cat, .prc, .prp, .pty, .sub)

15. Model Integrator - Load/Unload Subunits When using the Model Integrator, if one or more contributor files has controlled units, the Subunits dialog appears. The Subunits dialog box allows you to load or unload controlled units before comparing or merging files.

16. Model Integrator - Load/Unload Subunits

17. Rose Model Integrator - Comparing Files Item Changed Item Moved Item Added Item Deleted Set Merge Mode

18. Rose Model Integrator - Merge Files The Merge mode allows you to compare files and create a recipient into which files can be merged. Input files are called contributors. A contributor file can be a model file or a controlled unit. If there is a conflict, the Model Integrator will find and mark it with an ‘X’. You can click on that item to see more information about that conflict.

19. Rose Model Integrator - Merge Files Number of contributor Merge menu Set Compare Mode

20. Source Code Control Add-in The source code control add-in allows access to any SCC compliant configuration management system The SCC API is the Microsoft standard API for source code control tools The SCC add-in automatically determines what SCC tool is installed The add-in adds menu options to the Tools:Source Control menu and to the File:Units:CM menu

21. Source Code Control Menu

22. Team Development Step by Step 1. Identify configuration management system 3. Identify developer workspaces 2. Identify integration workspace 4. Define integration strategy 5. Create virtual pathmap symbols 7. Determine controlled units and place them under CM control 6. Provide access to the configuration management tool

23. Step 1: Identify CM System Rational ClearCase is the configuration management system used for this example

24. Step 2: Identify Integration Workspaces In ClearCase, the central repository that contains all versions of all files is called a Versioned Object Base (VOB) A ClearCase view is a collection of specified versions of some or all of the files in the VOB Each view is mapped to a drive letter An integration workspace is a directory or set of directories that contain baselined or integrated work

25. Integration Workspace integration_view on ‘view’ (Z:) model_vob reuse_vob

26. Step 3: Identify Developer Workspaces Each developer has their own private workspace Set up as ClearCase views moe_view on view (Z:) model_vob reuse_vob curly_view on view (X:) model_vob reuse_vob MOE CURLY

27. Step 4: Define Integration Strategy A consistent integration strategy must be developed Rose Team Development strategy All development is done on the integration (main) branch No branching of model files is permitted Only one developer works on a controlled unit at a time (ClearCase reserved checkout)

28. Step 5: Create Virtual Pathmap Symbols Using Rose’s path map mechanism, define path map names, which are used to store and retrieve Rose components Create a path map name to point to the .mdl file’s current directory ($CURDIR = &) Allows Rose to reference controlled units relative to the directory containing the model file Independent of the directory with which a view is associated

29. How Does Rose Use Virtual Path Names? Rose will create model files whose embedded pathnames are relative to the defined symbol If the model file for moe_view is stored at z:\model_vob\model.mdl z:\model_vob\logical\database.cat is stored as $CURDIR\logical\database.cat If the model file for larry_view is stored at y:\model_vob\model.mdl z:\model_vob\logical\database cat will always be referenced as $CURDIR\logical\database.cat

30. Step 6: Provide Access to the CM System The Version Control menu includes the following: Add to Version Control - place a new unit under CM control Remove from Version Control Start Version Control Explorer - start ClearCase Details tool Check In - put controlled unit into the CM system Check Out - get controlled unit from CM system (read-write access, unit is locked)

31. Step 6: Provide Access to the CM System Version control menu options (con’t) Undo Check Out - return unit to CM system, undo any edits made by the current developer Get Latest - update Rose model with units checked in by other developers which impact the current developers view File Properties - display properties of a selected file File History - display history of a selected file

32. Step 7: Determine Controlled Units All packages should be made controlled units Rose will automatically make a package a controlled unit when the package is added to a version control system Nested packages should also be controlled units Allows two developers to check out packages “belonging” to the same higher level package

33. Team Development Example LARRY Y:\model_vob\database.cat, register.cat, errors.cat CURLY X:\model_vob\database.cat, register.cat, errors.cat Z:\model_vob\database.cat, register.cat, errors.cat Get Latest Get Latest Get Latest MOE W:\model_vob\database.cat, register.cat, errors.cat

34. Team Development Example Moe, Larry, and Curly views do not contain checked-out copies of packages in the model The following updates need to be made Moe needs to update database.cat Larry needs to update register.cat Curly needs to update errors.cat Each developer will check out the package they need They will have read-write access to the packages they check out of the CM system

35. Team Development Example LARRY Y:\model_vob\database.cat, register.cat, errors.cat CURLY X:\model_vob\database.cat, register.cat, errors.cat Z:\model_vob\database.cat, register.cat, errors.cat Check out database.cat Check out register.cat Check out errors.cat MOE W:\model_vob\database.cat, register.cat, errors.cat

36. Team Development Example LARRY Y:\model_vob\database.cat, register.cat, errors.cat Z:\model_vob\database.cat, register.cat, errors.cat Check in register.cat Larry finished his changes and asked the CM system to check-in register.cat A new version of the file is checked in on the element branch that is referenced by Larry’s view Changes to register.cat are available to other developers after it is check-in to the VOB provided their views reference Larry’s branch

37. Exercise: Create a CURDIR Pathmap

38. Exercise: Controlled Units Make each package a controlled unit

39. Exercise: Write Protection Write protect the Business Objects controlled unit

40. Exercise: Verify Write Protection