Announcements

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

2. HW1 USC CSCI 578, Fall 2014 Jae young Bang (jaeyounb@usc.edu) September 8th, 2014

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

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

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

6. How It Works – Participant

7. How It Works – Project

8. BOINC Server

9. 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 • are applicable in a given development context, • constrain architectural design decisions that are specific to a particular system within that context, and • elicit beneficial qualities in each resulting system. • For example, • Client-server • Batch-sequential • Publish-subscribe • And many more …

10. There is NO “one and only” right answer.

11. Introduction to Collaborative Development USC CSCI 578, Fall 2014 Jae young Bang (jaeyounb@usc.edu) September 8th, 2014

12. Collaborative Software Development • Complex modern software developmentoften 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 oftenface 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.

14. 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 communicationbetween users • Pros: may prevent having conflicts • Cons: could distract users and lose parallelism • Examples: Google Docs, ShareJS, DerbyJS

15. Conflict Scenario • Heavily test-driven project • Capable of running simulations • Estimating memory usage at runtime • Hard requirement on memory usage Master Repo Conventional version control system (VCS) Commit Commit Update Update Working Copy Working Copy Jane John

16. Conflict Scenario • Jane and John make conflicting changes • They found they have made changes that [3]: • Are not compatible and cannot be merged together or • Can be merged but together violate system’s intended rules Master Repo time Commits the change Commits the change • Makes a change • Finds no issue inmemory usage • Makes a change • Finds no issue inmemory usage Working Copy Working Copy Jane John Code Too muchmemory usage! Remove Update [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]: • 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] 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

22. 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 proactiveway • 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.

24. Questions?