Fast Conflict Detection for
Remote Collaborative Software Modeling
Jae young Bang

March 8th, 2011
2
Outline
 Phase 1: year 2010
 Motivation
 CoDesign Project Goals
 Results
 Phase 2: year 2011
 Research questions
 Status update
 Fast conflict detection
3
CoDesign Phase I Report
Year 2010

4
Motivation
 Global software engineering
 Outsourcing and off-shoring
 Software designers are
distributed
 Communication challenge
 Existing technology
 SCM tools: CVS, SubVersion
 Collaborative IDEs
 Modeling tools w/ model merging
5
CoDesign Project Goals
 Realtime collaboration from different locations
 Modeling-oriented
 Extensibility: legacy/domain-specific tools (Infosys)
Domainspecific
Domainspecific
Legacy
Legacy
Proprietary
Architect
Collaborative
tool
Proprietary
Legacy
Legacy
Proprietary
Architect
Legacy
Domainspecific
Domainspecific
Legacy
Domainspecific
Proprietary
Architect
Domainspecific
Proprietary
Domainspecific
Legacy
Architect
6
Obstacles of Realtime Collaboration
 Latency between designers
 “What I see now may not be what you see”
 Conflicts occur by unawareness
 Synchronization conflicts
 Syntactic conflicts
 Semantic conflicts
 Detection is tricky and expensive
7
Synchronization Conflict


Student
Name
Simple conflicts caused
by latency
GPA
GetName()
Can be resolved with GetGPA()
little or no human
!
intervention
Doctorate
Year
Advisor
GetYear()
GetAdvisor()
Change
name to
PostDoc
Delete
Doctorate
7
8
Conflicts & Inconsistencies
Most researches focus on
Conflicts
Inconsistencies
Conflicts are huge obstacles
9
CoDesign Phase 1

A framework that provides …




Realtime sync & conflict/inconsistency detection
Extensible collaborative software modeling
Scalability of the size of a model and the number of users
Delivered


High-level categorization and definitions of conflicts
Prototype implementation



Realtime model synchronization
Basic level conflict detection using third party extensions
Publication

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” at ICSE 2010
Generic Modeling
Environment
Drools
From JBoss Community
From Vanderbilt University
Software Modeling Tool
Business Logic Integration
Platform
Prism-MW
From SoftArch, USC
Lightweight Middleware
10
11
CoDesign Phase II Progress
Year 2011

12
Research Question (1)
 Why is it hard to manage realtime concurrent
editing of software models?
 Low level of isolation of design decisions
 No locking involved
 Even locking does not prevent conflicts
 Techniques to keep model consistent
13
Research Question (2)
 Why do conflicts occur? Any way to prevent them?
14
Life of a Design Decision
1. Made by a designer
2. Captured
3. Encapsulated to be passed
4. Sent to server
5. Checked whether it makes conflicts
6. Broadcasted to designers except the original sender
7. Decapsulated and applied to the local models
8. Perceived by designers
15
Research Question (2)
 Why do conflicts occur? Any way to prevent them?
 Latency
 No conflict if 0 latency assumed
 0 Latency is impossible
 Conflict detection is inevitable
 Conflict detection increases latency
 Parallelization
16
Research Question (3)
 How frequently should conflict detection be run?
 Two cases
 Wait for a set of design decisions, run it for all
 Run it for every design decision
 The later a conflict is found, the higher cost to
resolve it
 Too intrusive?
 Too expensive?
17
Research Question (4)
 What is a good granularity of encapsulation of
design decisions?
 Two extreme cases
 Very coarse – group of design decisions
 Very fine-grained – atomic design decisions
 Event
 A design decision made by a designer, encapsulated
as a message to be passed between components
 Non-atomic events aggravate conflicts
18
CoDesign Phase II Goals
 Concurrent collaborative modeling
 Parallelized conflict detection
 Conflict detection for each atomic event, yet still
scalable of the number of designers
19
Definitions (1)
 Inconsistency
 A contradiction between software design decisions
 Conflict
 A type of inconsistency
 Caused by unawareness between multiple designers
 Originated from latency between them
20
Definitions (2)
 Stable model
 A model that has been synchronized to every
designer so no instance of the model differs from
the others
 Everyone sees the same on the screens
 Consistent model
 A model that is stable and has all of its components
consistent with each other
 A model without any inconsistency
21
Intuition
 Incoming event queue
 Conflict detection does not have to be done in
sequence
 Can be parallelized
 For lowest latency >> less conflicts
22
Fast Conflict Detection:
Snapshot Technique
Designers Set
refer
to the
of checked
stateslatest
“snapshot”
7
Snapshots
Based on
7.1
8
7.3
7.2
7.4
9
7.5
Checked
states
Run conflict
detection
against
Will be
based on
all states that
hadstates
not been
Unchecked
checked until the state was
Future snapshots
created
Legend
It is acceptable the order is
reversed – the later events will
catch conflicts
* at the stage of formal proof
9.1
Hierarchical View of the Composition of Events
23
Thank you
 Please refer to the CoDesign paper:
 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 32nd International
Conference of Software Engineering (ICSE 2010)
 Questions?