Page 1
S
CoDesignA Highly Extensible
Collaborative Software Modeling Framework
Jae young Bang ([email protected] )
University of Southern California
Daniel PopescuGeorge EdwardsProf. Nenad Medvidovic
Naveen KulkarniGirish M. Rama
Dr. Srinivas Padmanabhuni
Page 2
2
Trends
• Globally distributed software development• Large, multinational
software companies• Emerging economies
(India and China)• Widely distributed
stakeholders• Communication and
coordination challenges
Page 3
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
Page 4
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)
Page 5
5
CoDesign Project Motivation
• Identified a need for a collaborative tool that allows:1. Arbitrary client applications (front-end)
2. Client-specific management functions (back-end)
Page 6
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
Page 7
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
Page 8
8
Parallel Modification
MoveDoctora
teto right
Change name to PostDoc
Page 9
9
Synchronization Conflicts
• Simple conflicts caused by latency
• Can be resolved with little or no human intervention
Delete Doctora
te
Change name to PostDoc
!
Page 10
10
• Conflicts that violate modeling tool’s or language’s constraints
Syntactic Conflicts
Metamodel defines an Ethernet Router can only have 0 to 4 Port(s)
Add a Port Add a Port
!
Page 11
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
Page 12
12
Semantic Conflict
Request from C1 to
C2
Request from C2 to
C1
!
Page 13
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
Page 14
14
CoDesign ImplementationGME: software modeling tool from Vanderbilt Univ.
CoWare: lightweight integration platform for CoDesign
Drools: business logic integration platform from jBoss community
Page 15
15
Event Distribution
Design Decision
Broadcast “clean” event to the other architectsOr, send conflict notificationTo the involved architects
Page 16
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
Page 17
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
Page 18
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
Page 19
19
Contacts & References
• Jae young Bang [email protected]
• Nenad Medvidović [email protected]
• Jae young Bang, Daniel Popescu, George Edwards, Nenad Medvidovic, Naveen Kulkarni, Girish M. Rama, and Srinivas Padmanabhuni, 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!
Page 21
21
Overview
1. Background and Motivation
2. Project Goals
3. Collaborative Design Conflicts
4. CoDesign Architecture and Implementation
5. Ongoing Work
6. Live Demonstration
Page 22
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
Page 23
23
CoDesign ArchitectureGeneric Modeling Environment
From Vanderbilt University
Software Modeling Tool
Drools
From JBoss Community
Business Logic Integration Platform
Prism-MW
From SoftArch, USC
Lightweight Middleware
Page 24
24
Semantic Conflicts
• Conflicts that violate the intended meaning of a model
Intended model: only clients can requestConstraint defined using OCLCloud cannot make requests; it isagainst the rule
!
Page 25
25
• Conflicts that violate the intended meaning of a model
Semantic Conflicts
!