1. Agenda – week 4 6:00 – 6:05Questions, announcements, intro 6:05 – 6:35Case study – air traffic control 6:35 – 7:20Lecture: architecture in the development process 7:20 – 7:30Break 7:30 – 8:20Activity: ADD 8:20 – 8:30Break 8:30 – 9:35ADD continued 9:35 – 9:40Wrap up

2. Case study discussion In groups: 1. What qualities do you think the case study architecture achieves? 2. How did the case study description help you to understand the architecture? 3. What questions were you left with? 4. What qualities were negatively influenced by the design?

3. Lecture: architecture in the development process Development process lecture

4. Tools of the architect’s trade (last week) Quality attribute scenarios … A way of defining testable quality requirements Tactics … Bags of tricks you can apply Patterns and styles … Sets of tactics that usually fit together well and are often applied together

5. Using the tools – this week ADD – attribute-driven design 1. Pick a module to decompose … often, start with “the whole system” 2. Identify driver(s) for your selected module … High-priority use cases and qualities 3. Select tactic(s) or pattern(s) … that will satisfy the drivers for your module 4. Identify child modules and allocate responsibilities … guided by the tactics 5. Define interfaces for child modules 6. Check and refine use cases and quality scenarios …Repeat 3-6 if necessary, then 1-6 if necessary 7. Draw your decomposition

6. Activity – try ADD In groups 1. Select a module from the initial decomposition 2. Identify drivers 3. Select tactics/patterns 4. Identify child modules and allocate responsibilities 5. Summarize interfaces for child modules 6. Check whether anything important has been forgotten 7. Repeat 1-6 as long as you have time left 8. Draw your decomposition 9. Report to the class

7. Initial module decomposition CSR support Web site Order and account management accounts, orders orders

8. Customer relationship management functionality Use cases: Open an account Add a service Manage service options Drop a service Close an account Accounts can be opened and closed only on the phone. All other use cases must be supported on the phone and on the web site.

9. Usability scenario Source: customer Stimulus: request for Spanish Artifact: web site Environment: normal operation Response: web site interacts with customer in Spanish Response measures: Labels, links, prompts and agreements are in Spanish On-screen text fits the space available Customer’s default language set to Spanish

10. Availability scenario 1 Source: intranet Stimulus: CSR PCs unable to contact CRM system Artifact: CRM system’s clients/server communications Environment: normal operation Response: Over-the-phone service remains available Response measures: CSRs can accept tentative requests over the phone Transactions processed when network comes back up All of the above without manual intervention

11. Availability scenario 2 Source: web site infrastructure Stimulus: server crash Artifact: web server Environment: normal operation Response: web site continues to work Response measures: All web-based use cases continue to be available Transactions in progress can be restarted by just refreshing the page

12. Performance scenario Source: customer Stimulus: request to modify a service option Artifact: web UI Environment: normal busy-hour operation Response: quick response Response measures: Service options modified within 8 sec Transmission of confirmation page to customer begins within 2 sec after transaction completes

13. Modifiability scenario Source: marketing Stimulus: new RoadRunner option – multiple IP addresses Artifact: Code Environment: development Response: new feature added Response measure: enhanced system software ready for installation in three months

14. Thinking about 1-1-3 Remember that you have to define 2 quality attribute scenarios that are key drivers in the architecture you are documenting And, you have to talk about how those scenarios are achieved See Table 6.1, on page 150 in BCK, for an example