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, theres 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 gt 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
Decomposes into
Monitor
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!