CoDesign: An Extensible Collaborative Software Modeling Framework for Distributed Development

1. CoDesignA Highly Extensible Collaborative Software Modeling Framework Jae young Bang (jaeyounb@usc.edu) University of Southern California Daniel Popescu George Edwards Prof. Nenad Medvidovic Naveen Kulkarni Girish M. Rama Dr. Srinivas Padmanabhuni

2. Trends • Globally distributed software development • Large, multinational software companies • Emerging economies (India and China) • Widely distributed stakeholders • Communication and coordination challenges

3. Collaborative Development • Current collaborative development tools • Traditional software configuration management (SCM) tools • Based on check-in/check-out paradigm • Incur redundant work and wasted effort • Next-generation collaborative integrated development environments (IDEs) • Oriented toward distributed programming, not architecture design and modeling • Software architects still use traditional SCM tools to coordinate model changes

4. CoDesign Project Motivation • Infosys – a globally distributed software developer • Use many proprietary/legacy/domain-specific tools • Found existing collaborative tools are coupled to specific IDEs and lack extensibility • e.g., IBM Jazz (Eclipse) and MSR CollabVS (Visual Studio)

5. CoDesign Project Motivation • Identified a need for a collaborative tool that allows: • Arbitrary client applications (front-end) • Client-specific management functions (back-end)

6. CoDesign Project Goals • Extensible collaborative software modeling framework • Real-time synchronization & conflict detection • Scalability of models and users • Objectives: • Understand collaborative modeling issues • Define methods and processes to resolve issues • Develop designs and patterns for distributed model management and conflict detection

7. Collaborative Design Issues • Multiple architects unknowingly modify related objects • Caused by latency and lack of communication • Two different types of issues • Parallel modification • Changes are compatible, but architects should be alerted • Model conflicts • Changes are not compatible, and must be resolved • Three types: • Synchronization • Syntactic • Semantic

8. Parallel Modification Move Doctorate to right Change name to PostDoc

9. Synchronization Conflicts • Simple conflicts caused by latency • Can be resolved with little or no human intervention ! Delete Doctorate Change name to PostDoc

10. Syntactic Conflicts • Conflicts that violate modeling tool’s or language’s constraints Metamodel defines an Ethernet Router can only have 0 to 4 Port(s) ! Add a Port Add a Port

11. Semantic Conflict • Either can be the server or the client; not both • The one that makes requests be the client • This can be defined using OCL

12. Semantic Conflict ! Request from C1 to C2 Request from C2 to C1

13. Implication • Different types of conflicts require different types of conflict detection engines • Synchronization, Syntactic, Semantic • Conflict detection engines must be chosen based on the model tools and languages used • Extensible collaborative tool is in need

14. CoDesign Implementation GME: software modeling tool from Vanderbilt Univ. Drools: business logic integration platform from jBoss community CoWare: lightweight integration platform for CoDesign

15. Event Distribution Broadcast “clean” event to the other architects Or, send conflict notification To the involved architects Design Decision

16. Ongoing Work • Investigate of the type and nature of conflicts • Causes of conflicts • More complex conflicts • Experiment with conflict resolution processes • Automated or semi-automated • Win-win negotiation • Implement adaptive scope for parallel modification warnings • Based on usage profile and feedback

17. Contributions • Collaborative software modeling framework • Real-time synchronization • Extensible architecture • Categorization of collaboration issues and conflicts • Parallel modification vs. model conflicts • Synchronization, syntactic, and semantic conflicts • Efficient and scalable conflict detection

18. Demonstration • Demo setup: • Machine 1 • CoWare Server • Conflict detection engines • Machine 2 • Two virtual machines • CoWare Client/CoDesign Adapter/GME Modeling Tool • Capabilities shown: • Synchronization between CoDesign instances • Conflict detection and notification

19. Contacts & References • Jae young Bang jaeyounb@usc.edu • NenadMedvidovićneno@usc.edu • Jae young Bang, Daniel Popescu, George Edwards, NenadMedvidovic, NaveenKulkarni, Girish M. Rama, and SrinivasPadmanabhuni, CoDesign – A Highly Extensible Collaborative Software Modeling Framework, Proceedings of the Research Demonstration Track at the 32nd International Conference on Software Engineering (ICSE10) • Thank you!

20. Backup Slides

21. Overview • Background and Motivation • Project Goals • Collaborative Design Conflicts • CoDesign Architecture and Implementation • Ongoing Work • Live Demonstration

22. Current Tools • Collaborative modeling tools • IBM Jazz • Tightly coupled with Eclipse • Microsoft Research CollabVS • Tightly coupled with Microsoft Visual Studio • No open platform available for integration of existing tools • How can we detect and resolve design-time issues? • Infosys had issues in extensibility

23. Drools FromJBoss Community Business Logic Integration Platform CoDesign Architecture Generic Modeling Environment From Vanderbilt University Software Modeling Tool Prism-MW From SoftArch, USC Lightweight Middleware

24. Semantic Conflicts • Conflicts that violate the intended meaning of a model ! Cloud cannot make requests; it is against the rule Intended model: only clients can request Constraint defined using OCL

25. Semantic Conflicts • Conflicts that violate the intended meaning of a model !