Collaborative Modeling for Interoperability Standards

1. Collaborative Modeling for Interoperability Standards Ben Constable Chief Operations Officer Sparx Systems CIM Users Group Meeting, Milan 2010

2. Overview • Collaborative Modeling • What does it involve? • Examples in Utilities, Geospatial and beyond… • Challenges, Tools and Techniques • Team-based modeling: What are the challenges? • Model sharing via Version Control • Reconciling changes to models (merging) • Q & A

3. Collaborative modeling and open standards • Interoperability standards typically: • Use models and abstractions to: • Manage complexity – size and scope • Communicate to widely distributed audiences • Reduce risk of technology obsolescence • Use open modeling standards: • Often OMG’s Unified Modeling Language (UML) • For example IEC’s Common Information Model (CIM), • OGC’s Reference Model (ORM) • Involve many collaborating stakeholders and editors • Widely dispersed geographically • Numerous and varied member organizations

4. Collaborative modeling and open standards • Examples In Industry • International Electrotechnical Commission (IEC) CIM • ISO/TC 211 HMMG • JRC, INSPIRE • GeoSciML • UN/CEFACT’s Modeling Methodology (UMM) • Many others…

5. What are other SDOs doing with Enterprise Architect? • ISO/TC 211 Harmonized Model Maintenance Group (HMMG) • Maintenance of the ISO 19100 family of models • Standard meta models for Geospatial domain • Non-trivial size and scope (~240 Packages, 2K Elements) • HMMG adopted UML 2.1 and Enterprise Architect for modeling • Tool migration effort mirrors CIMug effort via XMI • More info CIM User Group: http://cimug.ucaiug.org • UN/CEFACT’s UMM • Modeling standard for describing inter-organizational business process • More info: http://umm-dev.org/tools/uml-case-tools

6. Development of GeoSciML • GeoSciML – CGI’s application of GML for geoscience data • Interoperability: Platform-neutral publishing and interchange of geoscience data between organizations, systems, services etc. • Collaboration: • UML meta-model: https://www.seegrid.csiro.au/twiki/bin/view/CGIModel/WebHome • Case Study says distributed package management critical: “…so that participants in different countries and time zones can concurrently work on the model.”

7. Sample Real-World Global Model Deployment • The Organization: • A Leader in the Media & Communications domain • Develops large-scale, complex systems • Global company, > 10,000 employees, offices worldwide • The Models: • Globally Distributed: Europe, Asia, Middle East, North America • Requirements Scoping, High-Level and Detailed Design • Large-scale Model Driven Development • 10,000’s of elements per model, > 100 concurrent users

8. Sample Real-World Global Model Deployment

9. Overview • Collaborative Modeling • What does it involve? • Examples in Utilities, Geospatial and beyond… • Challenges, Tools and Techniques • Team-based modeling: What are the challenges? • Model sharing via Version Control • Reconciling changes to models (merging) • Q & A

10. Multi-site Models • Why do we want to do this? • Globally distributed development teams • Require a shared view of the system(s) requirements • Increase productivity via parallel work • Inherent Challenges: • Connecting multiple teams to the shared view • Offline editing is often necessary • Models can be huge, performance must be managed • Disparate roles must collaborate remotely & harmoniously

11. Team based modeling – the challenges • Widely distributed teams • Shared development of standards • Big models and wide scope • Change control, merging work, revisions etc • There are tools that help…

12. Collaborative modeling concepts and tools • Shared (DBMS) Repository • Version Control • Model Baseline Merge • Role-based security • Model Auditing

13. Multi-site Models – How? • Ideal Scenario: Single, Shared (Master) Repository Site 2 Site 1 Site 3 Site n • Assumes good connectivity between each site

14. Multi-site Models – How? • Alternative Scenario: Local Replicas Site 2 Site 1 Site 3 Site n • Allows broad replication even across slow links

15. Performance: Big models, complex info Enterprise Models can be HUGE! End-to-end models can yield 100,000’s of Elements! Need robust, scalable solutions…

16. Performance: Big models, complex info • Use a Database Repository • Robust modeling tools use a DBMS! • Load on Demand (‘Lazy Load’) • Only give me what I need when I need it! • Network optimization (‘WAN Optimizer’) • Widely distributed environment must reduce the network chatter • Getting teams connected is a first step, having them work effectively is another matter…

17. Shared Repositories • How DBMS repositories help: • Concurrent users edit/view the same model instance • No need for synchronization • DBMS server can support large teams, large models • Host a single ‘Master View’ • Requires some DB administration to setup • Commonly used for DBMS based repositories: • MySQL • MS SQL Server • Oracle

18. How to maximize parallel work SAFELY • Multiple distributed editors • Consider: Who uses the model? • For what purpose? • Approaches must: • Enable concurrency • Reduce risk of ‘collision’ • Managing concurrent access • Role-based Security • Version Control procedures

19. Safe parallel work: Role-Based Security • Access Controls • Restrict editing privileges per role • Individual user permissions • Group permission (Business Analysts, Architects, QA etc) • Refined Workflow • Require login to the model repository • Locking modes: “Require user lock to edit”, “Optional Lock” • Locking granularity: View, Package or Element level • Not to be confused with operating system or DBMS security!

20. Role-Based Security • Shared models, concurrent editors … • Access controls needed! • Individual user permissions • Group permission (Analysts/BAs, Architects, QA etc) • Role-based security: • Require individuals or groups to login to the model repository • Restricted editing privileges based on role • Locking granularity: View, Package or Element level • Different locking/security modes available: “Require user lock to edit”, “Optional Lock” • Not to be confused with operating system or DBMS security!

21. Safe parallel work: Version Control • Benefits: • Supports concurrent work • Maintain history of changes • Compare current vs prior state • Roll-back changes • Package-Based Versions: • Stored using open standard for model exchange, XMI • Granularity: Down to Package (‘Folder’), Sub-Packages

22. Version Control: What the user sees Packages Checked-in (Locked) Packages Checked-out (Editable)

23. Versions in Enterprise Architect models • Two Basic Approaches: • Entire Model Repository: Simple, ‘coarse’, no concurrency • Package-based: Supports concurrent work • Package-Based Versions: • Packages serialized as XMI (XML Metadata Interchange) file • 1 Package Version = 1 XMI file • Applies to Root (Model), View, Parent or Child Packages

24. Versions in Enterprise Architect models • 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

25. Versions in Enterprise Architect models • 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)

26. Version Controlled Packages • Basic concepts of version control apply: • A mechanism for managing concurrent work • Maintain a history of changes • Changes can be ‘rolled back’ • Revisions stored in XMI format • Note: Default is XMI 1.1 (includes UML 2.1 info!) • More Info: http://www.sparxsystems.com/WhitePapers/Version_Control.pdf

27. Version Control: Behind the scenes interfaces

28. Version Control: Multiple Users, Local Models

29. Version Control: Multiple Users, Shared Model

30. Model 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 level • Between 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 Package • Think version, not ad-hoc model merge

31. Model Merge • Scenario: • User A (Gatekeeper) maintains the baseline/master model • User B (Editor) supplies these changes to IEC 61970 Topology: 1. New Attribute added to existing TopologicalNode class 2. New Class added and associated to TopologicalNode class 3. Aggregation to Terminal class deleted (accident?!) 4. Updated notes for attribute TopologicalNode. sShortCircuit • User A has two options: 1. Overwrite Package IEC 61970 from User B – no work to do 2. Review and selectively merge User B’s changes to IEC 61970 • Option 2 required if User A has own changes

32. User A: Original model

33. User B: Updated model

34. X Merge with XMI?

35. Enterprise Architect Baseline Merge User B User A

36. Enterprise Architect Baseline Merge + User B User A

37. Model Auditing • Do we need to track model changes in real-time? • Large enterprises have strict governance rules • Changes to specifications can be expen$$$ive • Need to know: Who changed What and When • Model Auditing capability provides: • A fine-grained change log for model elements • Change log is continuous vs ‘point-in-time snapshot’ (c/f version control baseline) • Filtering and highlighting of model differences • Accountability for model changes made over time • Exportable as a permanent record of change

38. Overview • Collaborative Modeling • What does it involve? • Examples in Utilities, Geospatial and beyond… • Challenges, Tools and Techniques • Team-based modeling: What are the challenges? • Model sharing via Version Control • Reconciling changes to models (merging) • Q & A

39. thank you for your attention!