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 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 B/C/K evolutionary delivery lifecycle is very compatible with RUP It is significantly more iterative than traditional waterfall It shares an iterative approach with Extreme Programming also, but XP is much less interested in up-front documentation such as use cases, quality attribute scenarios and architecture documentation

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 Tactics Patterns 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!