View
30
Download
1
Category
Preview:
DESCRIPTION
Collaborative Modeling Best Practices for Distributed Teams. Ben Constable Chief Operations Officer Sparx Systems. CIM Users Group Meeting, Milan 2010. Overview. Collaborative Modeling Concepts Team Deployment Version Control Modeling workflows for Distributed Teams - PowerPoint PPT Presentation
Citation preview
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
www.sparxsystems.com
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
www.sparxsystems.com
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
www.sparxsystems.com
Sample Real-World Global Model Sample Real-World Global Model DeploymentDeployment
www.sparxsystems.com
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
www.sparxsystems.com
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
www.sparxsystems.com
Version Control: What the user sees Version Control: What the user sees
Packages Checked-in (Locked)
Packages Checked-out (Editable)
www.sparxsystems.com
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»
www.sparxsystems.com
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)
www.sparxsystems.com
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
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
www.sparxsystems.com
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
www.sparxsystems.com
Managing Cross-Package DependenciesManaging Cross-Package Dependencies
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.
www.sparxsystems.com
Managing Cross-Package DependenciesManaging Cross-Package Dependencies
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
www.sparxsystems.com
Managing Cross-Package DependenciesManaging Cross-Package Dependencies
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.
www.sparxsystems.com
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
www.sparxsystems.com
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
www.sparxsystems.com
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
www.sparxsystems.com
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
www.sparxsystems.com
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
thank you for your attention!
Recommended