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 ([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 • 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 ([email protected]) 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?