Announcements
•
Class website
 http://sunset.usc.edu/classes/cs578_2014/
•
TA Office hour
 Location still TBD
 By-appointment until we get an office
•
Exam schedule
 Exam #1: October 15th (Wednesday)
 Exam #2: December 1st (Monday)
 Both exams during the regular class time – 9:30 to 10:50 AM
•
Homework
 3 + 1; last one being the project
 HW1 has been posted
HW1
USC CSCI 578, Fall 2014
Jae young Bang (jaeyounb@usc.edu)
September 8th, 2014
HW1
•
You be a software architect!
•
From high-level design to more in-depth, detailed design
•
Specific problems in the homework description
•
BOINC Case Study – may be used throughout all HWs
What is BOINC?
•
Berkeley Open Infrastructure for Network Computing
•
An open-source software for volunteer computing and
grid computing
•
Originally developed for SETI@home




Analyzing radio telescope data from outside of the Earth
Searching for extraterrestrial intelligence
Large computation resource needed
Computation resource is expensive
Volunteer Computing
•
Computation resource donation
 Participants who are interested in a project could donate
their computation resource (CPU time, storage, etc.)
 Taking advantage of the idling cycles of personal computers
•
Volunteer computing performance
 SETI@home (July 23, 2014)
 320,121 active participants
 512,197 active computers
 6.6 petaFLOPS
How It Works – Participant
How It Works – Project
BOINC Server
What You Will Be Doing
•
Pick two architectural styles
•
An architectural
Expand
the BOINCstyle
taskis:
server into a “level 2” architecture
in each of the styles you chose
•
Discuss your decisions
•
A named collection of architectural design decisions that
(1)
are applicable in a given development context,
 Why did you choose those styles?
(2)
constrain architectural design decisions that are specific
 What are the pros and cons of your choices?
to a particular system within that context, and
Compare
two styles
(3) elicit the
beneficial
qualities in each resulting system.
 Which one is better in which perspective?
•
•
For example,
- What
Client-server
are the key architectural challenges that are NOT covered
- by
Batch-sequential
your architectures?
- Publish-subscribe
Upgrade your architectures
- And many more …
Find flaws in your architectures
 We’ve gotten richer. Let’s throw in a cloud into our computation.
There is NO
“one and only”
right answer.
Introduction to
Collaborative
Development
USC CSCI 578, Fall 2014
Jae young Bang (jaeyounb@usc.edu)
September 8th, 2014
Collaborative
Software Development
•
Complex modern software development
often involve multiple stakeholders
•
Common challenges
Different expertise
Different goals
Miscommunication
Not fully knowing each
others’ work
 Geographic distribution




•
Stakeholders make
conflicting decisions!
12
Why The Conflicts Are Bad
•
Conflicts persist long (several days) [6]
•
Work done after a conflict was introduced might need to
be reverted in the process of resolving the conflict
•
Wasted time and effort – increased cost
“We often face inconsistencies between
components developed by different engineers at
later stages. Half of the cases lead to full-scale
reverting to earlier stages, and local patches are
made for the other half” [4]
– A quote from an interview with a practicing professional architect
[4] Bang, J. et al. “How Software Architects Collaborate: Insights from Collaborative Software Design in Practice.” CHASE 2013.
[6] Brun, Y. et al. “Early Detection of Collaboration Conflicts and Risks.” TSE 2013.
13
Collaborative Software
Development Environments
•
Conventional “sandbox” Version Control Systems (VCSs)





•
Copy-edit-merge
Loose connection between users
Pros: parallel work from users
Cons: conflicts occur
Examples: CVS, Subversion (SVN), Git, Mercurial
Synchronized group editors





Shared whiteboard
Tight connection / rich communication between users
Pros: may prevent having conflicts
Cons: could distract users and lose parallelism
Examples: Google Docs, ShareJS, DerbyJS
Conflict Scenario
•
•
•
•
Heavily test-driven project
Capable of running simulations
Estimating memory usage at runtime
Hard requirement on memory usage
Master
Repo
Commit
Working
Copy
Jane
Conventional version
control system (VCS)
Commit
Update
Update
Working
Copy
John
15
Conflict Scenario
•
Jane and John make conflicting changes
 They found they have made changes that [3]:
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
•
•
Master
Repo
Commits
the change
Makes a change
Finds no issue in
memory usage
•
•
Working
Copy
Jane
Remove
Makes a change
Finds no issue in
memory usage
Working
Copy
Too much
memory usage!
Code
Update
John
[3] Bang, J. et al. “Enabling Workspace Awareness for Collaborative Software Modeling.” Future of Collaborative Software Development 2012.
16
Conflict Scenario
•
Jane and John make conflicting changes
 They found they have made changes that [3]:
Synchronization [2, 3]: 1.
Higher-order [3, 6]:
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 [6]
 Direct conflicts [18]
•
Other names of higher-order conflicts
 Indirect conflicts [18]
[2] Bang, J. et al. “CoDesign – A Highly Extensible Collaborative Software Modeling Framework.” ICSE 2010.
[3] Bang, J. et al. “Enabling Workspace Awareness for Collaborative Software Modeling.” Future of Collaborative Software Development 2012.
[6] Brun, Y. et al. “Early Detection of Collaboration Conflicts and Risks.” TSE 2013.
[18] Sarma, A. et al. “Empirical Evidence of the Benefits of Workspace Awareness in Software Configuration Management.” FSE 2008.
17
“Software design is an activity that creates
a system’s software architecture – its set of
principal design decisions.”
– R. N. Taylor, N. Medvidović, and E. M. Dashofy
18
Collaborative Software Design
19
Detecting Conflicts via Models
•
Design decisions are conceptual, so are design conflicts
•
Detecting conflicts via tangible software models
•
What is a software model?
 An artifact documenting some or all of the architectural
design decisions about a system [19]
•
Design decisions documented as software models
•
Designs are done for modular systems, merged later [4]
•
Partial models are created, merged, checked for conflicts
[4] Bang, J. et al. “How Software Architects Collaborate: Insights from Collaborative Software Design in Practice.” CHASE 2013.
[19] Taylor, R. N. et al. “Software Architecture: Foundations, Theory, and Practice.” John Wiley & Sons, 2009.
20
Collaborative Modeling
•
Voluminous previous research




Software model merging
Software model inconsistency detection
Software model version control
Collaborative software design tools
21
Dealing with Conflicts
•
The negative consequences of having conflicts could
become worse if we identify and resolve them late.
•
What if we detect them earlier?
Dealing with Conflicts Early
•
Proactively deal with conflicts
 Workspace awareness
 “The up-to-the-minute knowledge of other participants’
interactions with the shared workspace” [11]
 Speculative analysis
 “Anticipating actions a developer may wish to perform and
executing them in the background” [6]
 Positive results from experiments [18] and actual use [6]
 Commonality
 Detecting conflicts earlier in a proactive way
 Preventing software developers from “deviating” far
•
Not yet mature to be widely adopted in industry
[6] Brun, Y. et al. “Early Detection of Collaboration Conflicts and Risks.” TSE 2013.
[11] Gutwin, C. et al. “Workspace Awareness for Groupware.” CHI 1996.
[18] Sarma, A. et al. “Empirical Evidence of the Benefits of Workspace Awareness in Software Configuration Management.” FSE 2008.
23
Questions?