Designing the Architecture

1. Designing the Architecture CSSE 477 Software ArchitectureSteve Chenoweth, Rose-Hulman InstituteWeek 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 Modelsand impact on architecture… • Spiral • Evolutionary Prototyping • Staged Delivery • Design-to-Schedule • Evolutionary Delivery

7. SpiralModel • 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. Initial Concept Create Prototype Refine Prototype Release Evolutionary Prototyping • 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. Initial Concept Requirements Architectural Design Stage 1: Detailed design, implement, test, deliver Stage 2: Detailed design, implement, test, deliver Stage n: Detailed design, implement, test, deliver Staged Delivery • 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. Initial Concept Requirements Architectural Design High Priority: Detailed design, implement, test Medium Priority: Detailed design, implement, test Low Priority: Detailed design, implement, test Medium Priority: Detailed design, implement, test Release Design-to-Schedule • “Get done what we can by September” version… • Probably the most common model used (in practice). Ran out of time or money

11. DeliverFinal Version Initial Concept Requirements Architectural Design Incorporate Feedback Develop Version Deliver Version Elicit Feedback Evolutionary Delivery • Bass’s recommendation. • Looks a lot like “staged delivery.”

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 • Choose module to decompose • Refine module: • Choose architectural drivers (from features, and from quality attribute scenarios, in supplemental spec. See next slide ) • Choose architectural pattern (based on tactics in Bass Ch 5) • Instantiate modules, allocate functionality, and represent using multiple views • Define interfaces • Refine use cases and quality scenarios -- make them constraints for sub-modules • 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 

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

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

30. 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. The original Napster architecture, from http://www.slais.ubc.ca/COURSES/libr500/05-06-wt1/www/R_Martin/Nap_Arch.htm.