1. ® IBM Software Group © 2009 IBM Corporation Essentials of Modeling with IBM Rational Software Architect V7.5 Module 17: Team Modeling

2. 2 Module objectives  After completing this module, you will be able to:  Describe team modeling tools and best practices in Rational Software Architect.  Compare, merge and combine models in Rational Software Architect.  Publish and share model documentation with other team members.

3. 3 Where are we?  Team modeling best practices  Configuration management options  Compare, merge, and combine models  Model publishing

4. 4 Best practice: develop a model organization strategy  Model organization and partitioning strategy  Logical partitioning  Physical organization  Model organization and ownership  Loose coupling between partitions  High cohesion inside partitions  Strong ownership  Model management  Minimize physical partitioning  Only partition to avoid the need for non-trivial merges  Isolate business functions using packages and multiple models  Model component usage with package import and element import relationships

5. 5 Structure models to manage dependencies Diag1 Diag2 Diag3 Diag4 Diag5 Diag6 Hub Ring Spoke Dependency types Best Acceptable Avoid, if possible If there are many, need broader ownership assignments to avoid complex merging Avoid always  Logical wheel structure:  Common elements reside in a central hub  Packages organized along spokes, with more widely shared packages toward the center  Diagrams that span concerns belong in the outer ring  Diagrams that focus on a particular package or concern belong in that package

6. 6 Model partitioning  Partition the model to avoid unnecessary merges  Factors to consider when deciding how to partition a model:  Stabilize abstraction levels  Minimize dependencies between models  Establish ownership policies  Avoid broken references

7. 7  To partition a model, you can:  Create packages  logical partitioning  Create fragments  Store elements in a model fragment file (.efx)  Extract a package to top level  Create a separate model (.emx) file for a particular package  Absorb fragments and top- level packages back into the model Model partitioning (cont.)

8. 8 Partition and fragment files  Physical partitions are represented as physical files:  Fragment (.efx)  Model file (.emx) Original Model Fragments Top-level package Fragments Original model

9. 9 Where are we?  Team modeling best practices  Configuration management options  Compare, merge, and combine models  Model publishing

10. 10 Configuration management (CM)  CM allows change in software assets to occur in a structured, controlled, and repeatable fashion.  A CM tool can:  Give team members simultaneous access to models  Control who can update different model elements  Help introduce changes in a controlled manner  Maintain the evolutionary history of a model and its elements  A CM process defines how tools will be used to manage change in a project. Business.emxsrc Repository

11. 11 CM in Rational Software Architect  IBM Rational ClearCase  Pessimistic locking: must check out each artifact  Full-context findmerge compatible with UCM  IBM Rational Team Concert  Optimistic locking: download artifacts and then commit changes  File changes are noted in real time or when polled  Does not yet have full-context logical model merge  CVS  Optimistic locking  Has full-context merge Change Local File System Repository 2 1

12. 12 Where are we?  Team modeling best practices  Configuration management options  Compare, merge, and combine models  Model publishing

13. 13 Compare and merge models  Merge model and diagram files using the compare and merge feature.  Compare models to identify changes between model versions.  Merge models when:  Parallel development occurs  Alternative approaches are explored  Circumstances dictate  Avoid situations that require frequent merging.

14. 14 Merging models  Begin with a base contributor, the common ancestor of the models that you wish to merge.  Have up to three contributors (modified versions of the base model) in a merge session. 1 1 2 3 Contributor 1 Base Contributor Contributor 2 1 Merge

15. 15 Compare editor Structural Differences Accept or Reject changes Structural Differences Accept or Reject changes Merged Model Left Contributor Right Contributor Model Merge Diagram Merge

16. 16 Combine models Pending Changes Mark changes from source model to be applied to target model. Pending Changes Mark changes from source model to be applied to target model. Source Model Target Model Change Description Combine models that have no common ancestry

17. 17  In this lab, you will complete the following tasks:  Compare and merge different contributors to the same model  Combine different models Lab 17: Compare, merge, and combine a model To begin the lab:  In the workbench, click Help > Cheat Sheets to open the Cheat Sheet Selection dialog.  Expand Essentials of Modeling Labs.  Double-click 17 Team Modeling.  Follow the directions indicated on the Cheat Sheet.

18. 18 Where are we?  Team modeling best practices  Configuration management options  Compare, merge, and combine models  Model publishing

19. 19 Model publishing  Publish the entire model to HTML  Publish reports to PDF  Model diagram report  Sample UML metric report

20. 20 BIRT publishing  Business Intelligence Reporting Tool  Open source reporting tool Extended by IBM Rational  Provides reports while using these tools:  Rational Software Architect  Rational Software Modeler  Rational RequisitePro  Rational ClearQuest  Rational Asset Manager  Rational Team Concert Palette Navigator Report

21. 21 When and why to publish models  Publish models as an aid for manual model and architecture review  Publish an established API or framework  Work with developers using IBM ® Rational ® Application Developer  Share models with customers and partners who are not Rational Software Architect users

22. 22 Demo: Model publishing  The instructor will now show you how to:  Publish a model to HTML  Explore the published model  Start page  Packages  Elements  Diagrams

23. 23 Review  Why should you partition model files?  What are model fragments?  Why might you want to combine models that are not related by a common ancestry?  Name some examples of when you might need to Web-publish a model.

24. 24