160 likes | 170 Vues
Design Process for Architecture. 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
E N D
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
Evolutionary Delivery Lifecycle Software Concept Release Req. Analysis Design Architecture, System Core Develop a version Incorporate customer feedback Deliver the version Get customer feedback
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
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
Other Processes • Traditional water fall • Rational Unified Process • Extreme Programming
Designing and Architecture - Attribute Driven Design ADD Use cases, Quality attribute scenarios Architecture
ADD products • First several levels of Module Decomposition • Containers for functionality and interactions • Other views as needed, for example • Concurrency • Deployment
ADD Inputs • Requirements • Functional (authors prefer Use Cases) • Quality (probably declarative, quality attribute scenarios are preferred if available) • Tactics • Patterns
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
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
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
Extended ADD example Text shows Garage Door example (pg 156)
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!)
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
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!