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
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

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