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: We are currently in the Part 1 / Phase 1  Nov. 21: Part 1 / Phase 1 finishes. Submit Part 1 / Phase 1 deliverables. Part 1 / Phase 2 begins.  Dec. 3:Part 1 / Phase 2 finishes. Part 2  Nov. 19 to Nov. 30:FLAME collaborative design sessions  Dec. 3:Part 2 finishes

Collaborative Software Design USC CSCI 578, Fall 2014 Jae young Bang November 17 th, 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: Repo Working Copy Jane Working Copy John Commit Update The Repository Checkout Ver. 100 Ver. 101 Ver. 102

Too much memory usage! 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 7 Repo Working Copy Jane Working Copy John time Makes a change Finds no issue in memory usage Commits the change Makes a change Finds no issue in memory usage Updates Remove Update Model

Conflict Scenario Jane and John make conflicting changes  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 Other names of synchronization conflicts  Textual conflicts  Direct conflicts Other names of higher-order conflicts  Indirect conflicts 8 Synchronization: Higher-order:

Revisiting Version Control What is the risk of not knowing an outstanding conflict? Repo Working Copy Jane Working Copy John Commit Update The Repository Checkout Ver. 100 Ver. 101 C C C C C C C C Conflict found! What if John was aware of the conflict earlier?

FLAME F ramework for L ogging and A nalyzing M odeling E vents  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? Repo Working Copy Jane Working Copy John Commit Update The Repository Checkout Ver. 100 Ver. 101 C Conflict found! John was able to stop before making further changes

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 14 All system requirements are met Memory requirement not met

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?