Announcements
•
Course project is on-going
 Part 1 / Phase 1 description has been updated
(typo in the submission filename convention)
•
HW2 grades are out
•
HW3 in-grading
CS 578 Course Project
•
Part 1
 Today:
 Nov. 21:
 Dec. 3:
•
We are currently in the Part 1 / Phase 1
Part 1 / Phase 1 finishes.
Submit Part 1 / Phase 1 deliverables.
Part 1 / Phase 2 begins.
Part 1 / Phase 2 finishes.
Part 2
 Nov. 19 to
Nov. 30:
 Dec. 3:
FLAME collaborative design sessions
Part 2 finishes
Collaborative
Software Design
USC CSCI 578, Fall 2014
Jae young Bang (jaeyounb@usc.edu)
November 17th, 2014
Collaborative
Software Design
•
Complex modern software systems
are designed by multiple architects
•
Design decisions to models
•
Architects collaboratively
evolve the models
•
Version control systems
(VCS) are often used to
support modeling change
integration (Part 1)
4
Version Control Systems
•
Categories of VCS in terms of synchronization frequency
 Synchronous: realtime synchronization
 Shared whiteboard, Google Docs, etc.
 Asynchronous: loose, on-demand synchronization
 Git, Subversion (SVN), etc.
•
Asynchronous VCSs are widely used
 More widely adopted for collaborative software development
 Parallelized “sandbox” style workspaces – higher productivity
 Not fully aware of each others’ work – causing conflicts
•
Risk of having conflicts
 Changes made after a conflict may need to be reversed
Basics of Version Control
•
How an asynchronous version control system works:
The Repository
100
Ver. 102
101
Repo
Commit
Commit
Update
Update
Ver. 101
100
102
Ver. 102
100
101
Working
Copy
Working
Copy
Checkout
Jane
John
Conflict Scenario
•
Collaborative design, hard requirement on memory usage
 They found they have made changes that:
1.
Are not compatible and cannot be merged together or
2.
Can be merged but together violate system’s intended rules
time
Commits
the change
•
•
Makes a change
Finds no issue in
memory usage
Repo
Working
Copy
Jane
•
•
Updates
Remove
Makes a change
Finds no issue in
memory usage
Working
Copy
Too much
memory usage!
Model
Update
John
7
Conflict Scenario
•
Jane and John make conflicting changes
 They found they have made changes that:
Synchronization: 1.
Higher-order:
2.
•
Are not compatible and cannot be merged together or
Can be merged but together violate system’s intended rules
Other names of synchronization conflicts
 Textual conflicts
 Direct conflicts
•
Other names of higher-order conflicts
 Indirect conflicts
8
Revisiting Version Control
•
What is the risk of not knowing an outstanding conflict?
The Repository
100
Ver. 101
Repo
Commit
Update
Ver. 101
100
Working
Copy
What if John was aware of
the conflict earlier?
C
C
C
C Conflict found!
C
100
Ver. 101
C
C
C
Working
Copy
Checkout
Jane
John
FLAME
•
Framework for Logging and Analyzing Modeling Events
 Provides facilities for proactive detection of higher-order
software design conflicts on top of asynchronous VCS
 Logs design decisions and conflict detection results
•
Key features
 Immediate capture of modeling changes
 Immediate transfer of modeling changes
to conflict detection engines
 Background conflict detection
10
FLAME:
Proactive Conflict Detection
•
What if the conflicts are detected in a proactive fashion?
The Repository
100
Ver. 101
Repo
Commit
John was able to stop before
making further changes
C
Conflict found!
Update
Ver. 101
100
100
Ver. 101
Working
Copy
Working
Copy
Checkout
Jane
John
FLAME: High-Level
Architecture
•
One Detection Engine per architect
•
Maintains a copy of the model that incorporates:
 The head version in the repository
 The local changes made on top of the base version
•
A “future” state of model when you perform an update
FLAME: As-Implemented
Architecture
FLAME: Conflict Notification
•
Delivers conflict information with minimal interruption
 Color flags that present conflict information
 The status of the copy of the model your Detection Engine maintains
 What will happen when you perform an update
All system requirements are met
Memory requirement not met
14
Guidance on
Dealing with Conflicts
•
Update before commit
•
When you see a red flag, fix it before you commit
•
Commit only when you see all green flags
Questions?