1. Design Process for Architecture

2. Architectural Lifecycle Not all lifecycle plans support Architecture! It is hard to achieve architecture based design without support in lifecycle No recognition of the architecture documents No support for conformance control No explicit penalty for bad architecture choices

3. Evolutionary Delivery Lifecycle Software Concept Develop a version Incorporate customer feedback Deliver the version Get customer feedback Release Req. Analysis Design Architecture, System Core

4. Skeletal System Usually the first version developed Like a skeleton – supports the “flesh” of the system Supports major behavioral aspects of system Includes central components Stubs for the other parts “End to End” functioning

5. Benefits of Skeletal System Integration harness Incremental develop and test Early interface testing Locate complex dependencies early Concentrate on major trouble spots Improved test and integration Schedule can avoid “last minute” crunch

6. Other Processes Traditional water fall Rational Unified Process Extreme Programming

7. Designing and Architecture - Attribute Driven Design ADD Use cases, Quality attribute scenarios Architecture

8. ADD products First several levels of Module Decomposition Containers for functionality and interactions Other views as needed, for example Concurrency Deployment

9. ADD Inputs Requirements Functional (authors prefer Use Cases) Quality (probably declarative, quality attribute scenarios are preferred if available) Tactics Patterns

10. ADD Cycle Generate quality attribute scenarios, if necessary Choose module to decompose For the first iteration, there’s often only one choice Refine: Choose architectural drivers Choose an architectural pattern or set of tactics (this choice determines sub-modules) Allocate functionality to sub modules Define interfaces Verify and refine use cases Select next module and repeat refinement

11. Driver => sub-module example Module to decompose: Module5 Drivers: one or more availability scenarios Tactics: passive redundancy, ping/echo, removal from service Module5Decomposes into PrimaryWarm spare Monitor ping notification

12. Next, decompose the primary Module to decompose: Primary Drivers: one or more performance scenarios Tactics: introduce concurrency, increase available resource Decomposes into PrimaryWarm spare Monitor DispatcherWarm spare Monitor Worker Thread manager

13. Extended ADD example Text shows Garage Door example (pg 156)

14. Team Structure After design, architecture gets mapped onto the developing organization Modules become work products Interfaces between modules limit communication needs At runtime At design time (meetings!)

15. Team Structure (cont) Good module design reflects domain knowledge – e.g. User interface, math, OS or containers (Web, EJB, etc.), DB Remember the ABC Organization can limit the architecture Architecture will affect the organization

16. Architecture Conformance Possibly the hardest problem: how to get (and keep) conformance to the architecture Sources of Architectural Change Requirements change Problem fixes Developer initiative Solutions Architect as overseer of the architecture Keep architecture docs up to date!