Announcements

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

HW1USC CSCI 578, Fall 2014

Jae young Bang ([email protected])

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

• Expand the BOINC task server into a “level 2” architecture in each of the styles you chose

• Discuss your decisions Why did you choose those styles? What are the pros and cons of your choices?

• Compare the two styles Which one is better in which perspective?

• Find flaws in your architectures What are the key architectural challenges that are NOT

covered by your architectures?

• Upgrade your architectures We’ve gotten richer. Let’s throw in a cloud into our

computation.

An architectural style is:

A named collection of architectural design decisions that(1)are applicable in a given development context, (2)constrain architectural design decisions that are specific

to a particular system within that context, and(3)elicit beneficial qualities in each resulting system.

For example,- Client-server- Batch-sequential- Publish-subscribe- And many more …

There is NO “one and only”

right answer.

Introduction to Collaborative DevelopmentUSC CSCI 578, Fall 2014

Jae young Bang ([email protected])

September 8th, 2014

12

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 makeconflicting decisions!

13

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.

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

15

Conflict Scenario

Master Repo

WorkingCopy

Jane

WorkingCopy

John

CommitCommitUpdate

Update

• Heavily test-driven project• Capable of running simulations• Estimating memory usage at runtime• Hard requirement on memory usage

Conventional version control system (VCS)

16Too muchmemory usage!

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

Master Repo

WorkingCopy

Jane

WorkingCopy

John

time

• Makes a change• Finds no issue in

memory usage

Commits the change

• Makes a change• Finds no issue in

memory usage

Commits the change

Remove UpdateCode

[3] Bang, J. et al. “Enabling Workspace Awareness for Collaborative Software Modeling.” Future of Collaborative Software Development 2012.

17

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

• Other names of synchronization conflicts Textual conflicts [6] Direct conflicts [18]

• Other names of higher-order conflicts Indirect conflicts [18]

Synchronization [2, 3]:Higher-order [3, 6]:

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

18

“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

19

Collaborative Software Design

20

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.

21

Collaborative Modeling• Voluminous previous research

Software model merging Software model inconsistency detection Software model version control Collaborative software design tools

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?

23

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.

Questions?