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

Overview

1. Background and Motivation

2. Project Goals

3. Collaborative Design Conflicts

4. CoDesign Architecture and Implementation

5. Ongoing Work

6. 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

!