1 Designing the Architecture CSSE 477 Software Architecture Steve Chenoweth, Rose-Hulman Institute Week 3, Day 1, Monday, September 19, 2011

2 Today What’s a viola, anyway? Project 2 – progress report from each team:  Describe any issues with the changes you have tried to make to your system, at the coding and/or design level, to implement the “availability improvement plan.” Bass Ch 7, on Designing the Arch – this  Tomorrow – Second case study (Ch 8) Thursday – Check out this special lecture 

3 That’s this Thursday!

4 Outline Architecture in Lifecycle –  A quick review Attribute-Driven Design Process  And a chance to try it

5 First Cartoon of the Day

6 Review of Incremental Lifecycle Models and impact on architecture… Spiral Evolutionary Prototyping Staged Delivery Design-to-Schedule Evolutionary Delivery

7 Spiral Model If growth of the arch is planned to be early, and to grow along with feature growth, this could work well. Similar to Larman’s iterative model (from 374). (Deliver)

8 Evolutionary Prototyping Initial Concept Create Prototype Refine Prototype Release The “bad” version of the spiral, for arch: Good chance to test arch in the prototype, but -- Team tends to focus on feature prototyping That test, or exposure to the customer, may of course cause arch changes! In particular, arch shortcuts will require a redo… (Deliver)

9 Staged Delivery Initial Concept RequirementsArchitectural Design Stage 1: Detailed design, implement, test, deliverStage 2: Detailed design, implement, test, deliverStage n: Detailed design, implement, test, deliver Note that this is a bigger picture – showing multiple “releases” or “deliveries.” Within any one, could be spiral model, say. These early stages could be like Larman’s (from 374), with prototyping, etc. as requirements are gathered.

10 Design-to-Schedule Initial Concept RequirementsArchitectural Design High Priority: Detailed design, implement, testMedium Priority: Detailed design, implement, testLow Priority: Detailed design, implement, testMedium Priority: Detailed design, implement, test Release Ran out of time or money “Get done what we can by September” version… Probably the most common model used (in practice).

11 Evolutionary Delivery Initial Concept RequirementsArchitectural Design Develop VersionDeliver VersionElicit FeedbackDeliver Final Version Bass’s recommendation. Looks a lot like “staged delivery.” Incorporate Feedback

12 Second Cartoon of the Day

13 Attribute-Driven Design Recursive decomposition Start with:  Functional requirements (use cases)  Constraints  Quality attributes (scenarios like Bass’s) We’re trying to discover, top-down, the pieces for the Reference Model (from Ch 2), and then pick an Architectural Pattern to suit…

14 Attribute-Driven Design Process 1. Choose module to decompose 2. Refine module: a) Choose architectural drivers (from features, and from quality attribute scenarios, in supplemental spec. See next slide  ) b) Choose architectural pattern (based on tactics in Bass Ch 5) c) Instantiate modules, allocate functionality, and represent using multiple views d) Define interfaces e) Refine use cases and quality scenarios -- make them constraints for sub-modules 3. Repeat until done Reference Model Architectural Pattern Reference Architecture Software Architecture

15 2.a) Choose Architectural Drivers Drivers are combination of functional requirements and quality attributes Prioritize requirements and select those that will "shape" the architecture May need some investigation to determine drivers

16 2.b) Choose Architectural Pattern Use tactics to achieve quality attributes Patterns package tactics Document your choice of tactics in your Design Notebook! Much of this work tends to be “how it works at runtime” – The key view looks like component and connector diagrams 

Pattern for Garage Door Opener This design allowed for: Semantic coherence and information hiding Increased computational efficiency Scheduling wisely 17

18 2.c) Instantiate Modules Refine (or interpret) the pattern for your particular problem Result is a decomposition into sub-modules

19 First-Level Decomposition

20 2.c) Allocate Functionality Use the use cases to identify flow of information  Try to “walk through” use cases in your component & connector view Assign responsibilities to sub-modules Pattern may help this process  Is there an architectural style that applies?  Can we apply a standard design pattern (e.g., proxy, façade)?  Is there a known algorithm for this kind of problem?

21 2.c) Represent Using Multiple Views Pick one view from each major category:  Module Decomposition, Uses, Class  Component and Connector Client-server, Concurrency, Process, etc.  Allocation Work assignment, Deployment, Implementation

22 2.d) Define Interfaces Child views need to show how they connect to other views: Each view provides information about interfaces Need to identify services provided and used

23 2.e) Refine Use Cases and Quality Scenarios Associate use cases and quality attributes to sub-modules  may need to break up use cases Quality scenarios:  may be satisfied by decomposition  may impose constraints on sub-modules  may be neutral with respect to decomposition  may not be satisfiable with decomposition

24 Let’s try it Your quiz refers to the Music4Sale system, which you and a partner will design. See the other quiz page for the requirements. See the next slides for some “competition.”

25

26

27

28

29

30 The original Napster architecture, from Napster: This one’s an example of a peer-to-peer system. Once the central index server provided the information to make a connection, all the file activity was between peers on the network.