Design Process for Architecture Architectural Lifecycle Not all

Design Process for Architecture

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

Evolutionary Delivery Lifecycle Software Concept Req. Analysis Release 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 n n 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 Use cases, Quality attribute scenarios ADD Architecture

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

ADD Inputs Requirements n n 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 n For the first iteration, there’s often only one choice Refine: n n n 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: Module 5 Drivers: one or more availability scenarios Tactics: passive redundancy, ping/echo, removal from service Module 5 Monitor Decomposes into 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 Primary Decomposes into Warm spare Monitor Dispatcher Worker Warm spare 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 n n 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 n n 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 n n n Requirements change Problem fixes Developer initiative Solutions n n Architect as overseer of the architecture Keep architecture docs up to date!