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

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

Lecture: architecture in the development process Development process lecture

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

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

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

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

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.

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

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

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

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

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

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