collaborative modeling best practices for distributed teams

www.sparxsystems.com

Collaborative Modeling Best Collaborative Modeling Best Practices for Distributed Practices for Distributed TeamsTeamsBen Constable

Chief Operations Officer

Sparx Systems

CIM Users Group Meeting, Milan 2010


OverviewOverview

Collaborative Modeling Concepts

Team Deployment

Version Control

Modeling workflows for Distributed Teams

Managing cross-package dependencies

Merging Changes from incomplete models

Applying Version Control

Q & A


Team based modeling – the challengesTeam based modeling – the challenges

Widely distributed teams

Shared development of standards

Big models and wide scope

Change control, merging work, revisions etc


Sample Real-World Global Model Sample Real-World Global Model DeploymentDeployment


Multi-site Models – How?Multi-site Models – How?

Ideal Scenario: Single, Shared (Master) Repository

Site 2

Site 3Site 1

Site n

Assumes good connectivity between each site


Multi-site Models – How?Multi-site Models – How?

Alternative Scenario: Local Replicas

Site 2

Site 3Site 1

Site n

Allows broad replication even across slow links


Version Control: What the user sees Version Control: What the user sees

Packages Checked-in (Locked)

Packages Checked-out (Editable)


Version Control: Behind the scenes Version Control: Behind the scenes interfaces interfaces

Data Exchange Format: XMI (fi le based) Data Exchange Format: SQL

Enterprise Architect

Subv ersion Repository

CVS Repository CVS Client

Subv ersion Client

Model Repository

TFS Repository TFS Client

SCC Repository SCC Client

Version Control: Multiple Users, Local Version Control: Multiple Users, Local Models Models

Shared :Subv ersion Repository

USER 1 :Enterprise Architect USER 2 :Enterprise Architect USER N :Enterprise Architect

USER N :Model RepositoryUSER 2 :Model RepositoryUSER 1 :Model Repository

USER 1 :Subv ersion Client USER 2 :Subv ersion Client USER N :Subv ersion Client

. . .

XMI File

XMI File

«flow»

XMI File«flow»

XMI File«flow»

XMI File

«flow»

«flow» «flow» «flow»


Versions in Enterprise Architect modelsVersions in Enterprise Architect models

Package-Based Versions:Packages serialized as XMI (XML Metadata Interchange) file

1 Package Version = 1 XMI file

Enterprise Architect allows version comparisons:

Compare utility operates on Baseline vs Current State

Current State: The ‘live’ Package in the model repository

Baseline (snapshot): XMI-based version of the same package

Baseline may take one of these physical forms:

‘Model Baseline’ (Snapshot stored in the model)

XMI exported file (Snapshot exists on disk)

Version controlled Package (Snapshot in VC Repository)


OverviewOverview


Team Deployment

Version Control





Q & A

Managing Cross-Package DependenciesManaging Cross-Package Dependencies

Examples of Cross-Package Dependencies:UML Connector between Elements in different Packages (eg Inheritance)Classifier referenced from an external package (eg. Attribute type)Move Elements between packages class Inheritance A-B

Package A

+ Child

Package B

+ Parent

Package A::Child

Package B::Parent

Model contains all related packages. Avoids info loss during XMI export/import


Model MergeModel Merge

When it’s needed:Concurrent work on a single package needs synchronization

Offline work needs to be ‘uploaded’

Selective roll-back of changes

Selective inclusion of changes (‘Phase based’ development)

Occurs at the package levelBetween versions of a package

1-way merge of Model Baseline to live Package

Baseline may exist in another model, file (eg. version control)

Requires same starting PackageThink version, not ad-hoc model merge



Collaborative Modeling Project: ADDRESSSee: http://www.addressfp7.org/

From the ADDRESS website:ADDRESS is a large-scale Integrated Project co-founded by the European Commission under the 7th Framework Programme, in the Energy area for the "Development of Interactive Distribution Energy Networks".

ADDRESS stands for: Active Distribution network with full integration of Demand and distributed energy RESourceS.

http://www.currentgroup.com/address.php

http://www.currentgroup.com/address.php



Under the current ADDRESS modeling approach:

Minimal dependencies between Working Packages (WP*)Local instances used when defining Sequence modelsSome cross-Package dependencies remain:

Classifier References (From Lifelines to Actor classifier in common Role model)

‘Use’ connector from Actor in Role model to Use Case element in WP*

Benefits from a Model Manager (‘Gate Keeper’)

Changes Made in WP* submitted to Model Manager

Use Baseline Merge to update ‘Master’ Model



Consider some possible synchronization scenarios:

Merging changes made in a complete model (only one external editor supplies)Merging changes made in an incomplete model (out of date with respect to ‘Master’)How Version Control could streamline the above processes in larger scale

Disclaimer: The following suggested workflows may be applicable to the ADDRESS project and other distributed modeling projects within CIMug in future. However, this information does not represent the official position of the ADDRESS project or its methodology.


Merging Changes from Complete Merging Changes from Complete ModelsModels

Example Workflow:1. ‘Editor1’ is assigned to Work Package 1 (WP1)

2. Editor1 adds a new Use Case, Diagram and ‘Use’ relationship

3. No other updates occur to WP1 by other editors

4. Changes to WP1 submitted to Model Manager via Baseline

5. Model Manager reviews and merges into Model Master

Demonstration:Baseline Merge Complete Changes


Merging Changes from incomplete Merging Changes from incomplete modelsmodels

Example Scenario1. Editor1 makes further updates

2. Meanwhile, Editor2 submits other changes to WP1 for merge

3. Editor1 now submits changes to WP1

4. Model Manager must preserve Editor2’s changes while incorporating Editor1’s new updates (resolve conflicts)

Demonstration:Selectively merge changes from Editor1’s Baseline


Applying Version ControlApplying Version Control

Benefits

Allows all editors to work with complete models

Distribution of model information automated

Conflicts avoided by version control locks

Enables check-out of all cross-dependant packages

Demonstration:Version Controlled Packages


Best Practices SummaryBest Practices Summary

Edit complete models, where possible

Use Baseline Merge to selectively include changes, otherwise

Assign ‘Model Manager’ to coordinate efforts

Apply Version Control for wide distribution and ‘auto-update’

Editors use ‘Get All Latest’ to retrieve complete, up-to-date model

Check out all cross-dependent packages, commit atomically

More Info: http://www.sparxsystems.com/WhitePapers/Version_Control.pdf


OverviewOverview


Team Deployment

Version Control





Q & A

thank you for your attention!

collaborative modeling best practices for distributed teams

Documents