Design Process for Architecture

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 Release Req. Analysis Design Architecture, System Core Develop a version Incorporate customer feedback Deliver the version Get customer feedback

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 Monitor Module5 Decomposes into ping ping notification Primary Warm spare

12. Next, decompose the primary Module to decompose: Primary Drivers: one or more performance scenarios Tactics: introduce concurrency, increase available resource Monitor Monitor Decomposes into Dispatcher Warm spare Primary Warm spare 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!