Designing the Architecture CSSE 477 Software Architecture Steve

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

Today n n 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. ” n n n Bass Ch 7, on Designing the Arch – this Tomorrow – Second case study (Ch 8) Thursday – Check out this special lecture 2

That’s this Thursday! 3

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

First Cartoon of the Day 5

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

Spiral Model n n 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) 7

Evolutionary Prototyping Initial Concept n n n The “bad” version of the spiral, Create Prototype for arch: Good chance to test arch in the Refine Prototype 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… Release (Deliver) 8

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

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

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

Second Cartoon of the Day 12

Attribute-Driven Design Recursive decomposition n Start with: n ¨ 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… 13

Attribute-Driven Design Process 1. 2. Choose module to decompose Refine module: Reference Model a) Architectural Pattern b) c) Reference Architecture Software Architecture d) e) 3. 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 14

2. a) Choose Architectural Drivers n n n 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 15

2. b) Choose Architectural Pattern n n 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 16

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

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

First-Level Decomposition 19

2. c) Allocate Functionality n Use the use cases to identify flow of information ¨ Try to “walk through” use cases in your component & connector view n n 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? 20

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

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

2. e) Refine Use Cases and Quality Scenarios n Associate use cases and quality attributes to sub -modules ¨ may n 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 23

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

25

26

27

28

29

Napster: n This one’s an example of a peer-to-peer system. n 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/libr 500/05 -06 -wt 1/www/R_Martin/Nap_Arch. htm. 30