S

CoDesignA Highly Extensible

Collaborative Software Modeling Framework

Jae young Bang (jaeyounb@usc.edu)

University of Southern California

Daniel PopescuGeorge EdwardsProf. Nenad Medvidovic

Naveen KulkarniGirish 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:1. Arbitrary client applications (front-end)2. 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

MoveDoctora

teto right

Change name to PostDoc

9

Synchronization Conflicts

• Simple conflicts caused by latency• Can be resolved with little or no human

intervention

Delete Doctora

te

Change name to PostDoc

!

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

!

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 ImplementationGME: software modeling tool from Vanderbilt Univ.

CoWare: lightweight integration platform for CoDesign

Drools: business logic integration platform from jBoss community

15

Event Distribution

Design Decision

Broadcast “clean” event to the other architectsOr, send conflict notificationTo the involved architects

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• Nenad Medvidović neno@usc.edu• 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!

20

Backup Slides

21

Overview1. Background and Motivation2. Project Goals3. Collaborative Design Conflicts4. CoDesign Architecture and Implementation5. Ongoing Work6. 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

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

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

!

25

• Conflicts that violate the intended meaning of a model

Semantic Conflicts

!