Architectural Design

1
Architectural Design

• John Reekie
• john.reekie_at_uts.edu.au

Software Architecture 48433 4th September 2003
2
Background

• Architectural design has been seat-of-the-pants
  for some time
• Various authors propose more systematic methods
  of architecture design
• These methods are still evolving
• We will look at architectural design based on
  three approaches
• Attribute-driven design
• Unified process
• Pattern languages

3
Attribute-driven design

• Attribute-driven design (ADD) is an architecture
  design method proposed by Bass, Bachmann, Kazman,
  ()
• The primary focus of this presentation
• Targets both functional and non-functional
  quality requirements
• Recursive decomposition
• Somewhat confused about patterns

() Different versions of this method have been
published.
4
Architecture in the lifecycle
Software concept
Preliminary requirements analysis
Deliver final version
Design of architecture and system core
Develop version

• Architectural design fits well into Evolutionary
  Delivery

Incorporate customer feedback
Deliver version
Elicit customer feedback
Steve McConnell Rapid Development
5
Lifecycle (2)

• Incremental and iterative design works well with
  architecture-driven development
• Increased visibility of the development process
• Higher adaptability
• Lower risk
• Architectural design
• Architectural design and requirements analysis
  iterate to (hopefully) converge on a fix-point
• The resulting architecture forms a core on which
  iterative activities build

6
Lifecycle (3)
Software concept
Requirements analysis
Architectural design
Stage 1 design, code, test, deliver

• Some projects are suited to more detailed
  architectural design and Staged Delivery

Stage 2 design, code, test, deliver
Stage N design, code, test, deliver
7
Lifecycle (4)
Software concept
Complete and release prototype
Design and implement initial prototype
Refine prototype

• Other projects tend towards less (or no)
  architectural design and Evolutionary Prototyping

Elicit customer feedback
8
A note on requirements

• Requirements are the input to ADD
• Typical requirements documents capture some
  qualities, but not all
• Architectural design attempts to capture both
  functional and non-functional requirements
• ADD requires that requirements be expressed as
  system-specific concrete quality scenarios
• The braking force indicated by the pressure on
  the brake pedal is reached within 100 ms
• Keeps quality requirement real
• Use to identify risks where qualities may not be
  met

9
Requirements and architecture
Constraints and enablers
Requirements
System software
Middleware
Use cases
Legacy systems
Scenarios
Standards and policies
Non-functional requirements
Distribution needs
Architecture
Experience
Previous architectures
Patterns
10
Aside functional vs non-functional

• Increasingly, computer systems are embedded in
  the real world, and some non-functional
  attributes are a critical part of system
  functionality
• Example 1
• Consider a braking system in a car. If the brakes
  respond ten seconds after pressing the brake
  pedal, is the system functioning?

See e.g. Edward Lee, Embedded Software
11
Aside (2)

• Example 2
• Consider a video transmission system. If the
  transmission channel suffers a temporary drop in
  capacity is it better to freeze the image or to
  continue to transmit and display a degraded
  image?
• Example 3
• Consider a control system. The time delay of the
  control loop critically affects correctness too
  much delay and the system can become unstable!

12
ADD in overview
Requirements
Drivers
Patterns
Qualities
Styles
Tactics
Architecture
13
Aside patterns vs styles

• Pattern and style are used interchangeably by
  Bass et al but
• Patterns are more detailed than styles
• Patterns interweave to create a pattern language
  
• Patterns capture context, constraints,
  consequences, and behaviour
• Patterns explain why
• Patterns may be harder to use and document
• (To be continued)

14
ADD is recursive
Two levels is usually enough
System
Scenarios
Decompose
Sub-systems
Scenarios
Decompose
Modules

• Tends to emphasize structural decomposition (i.e.
  the module viewtype)

15
Views produced by ADD

• Module
• Concurrency
• Deployment

16
Decomposition

• Choose drivers from the set of concrete scenarios
  and functional requirements
• Choose tactics and patterns that will fulfill
  requirements
• Instantiate child modules and allocate
  functionality
• Verify and refine use cases and make them
  constraints for children

17
1. Choose drivers

• The architectural drivers contain requirements
  that are architecturally significant
• That is, the combination of functional,
  non-functional, and business requirements that
  shape the architecture
• Drivers are chosen to focus on the most important
  issues
• Architectural design begins as soon as the
  drivers are identified

18
Example drivers

• If an obstacle is detected, the door will halt
  or re-open within 100 ms
• After entering a username, password, and SecurID
  keycode, a response to the authentication request
  is received no sooner than 2 seconds and no later
  than 5 seconds afterwards. Three consecutive
  unsuccessful requests disable logins from that
  connection for 30 seconds and generates a Yellow
  alert notification in the authentication summary
  logs.

19
2. Choose tactics and patterns

• Tactics provide the architecture with specific
  qualities
• Patterns implement a set of tactics
• Styles overlap with patterns some styles are
  patterns, and some are not
• (Bass et al seem to use pattern and style
  interchangeably)

20
Example tactics
Scenario
responds within 100 ms
Quality
Performance time-critical response
Time-triggered Architecture
Pattern
Control interrupt rates
Separate RT and supervisory nodes
Separate real-time scheduler
Tactic
Tactic
Tactic
21
3. Instantiate modules

• Instantiate child modules based on the general
  structure supplied by chosen tactics, styles or
  patterns
• Allocate functionality to child modules
• Elaborate information exchange between child
  modules
• Interfaces
• Patterns of interaction
• Represent modules using different views

22
Example module view
Layered style
Application
Non-RT Services
RT drivers
RT Kernel
RT Sched
Product platform
Note these examples dont make any sense, they
are just illustrative
Module style
23
Example concurrency view
Sensor A
Logger and event handler
Sensor B
Supervisory and application
Actuator X
24
Example deployment view
Platform w/ COTS RT services
Host station
25
4. Verify and refine

• Use informal reasoning to satisfy yourself that
  composition of the children satisfies the
  requirements and constraints of the parent
• Refine scenarios
• Assign to children
• Add constraints to children

26
Example refinement

• RTOS WCRT to interrupt 5 ms
• We require WCRT(RTOS) WCET(A) WCET(Handler)
  WCET(X) lt 100 ms
• Assign new scenarios and constraints
• Sensor A responds to event and generates output
  within 20 ms
• Handler analyzes events, and in the case of an
  error condition on A, generates an actuator
  signal within 50 ms
• Actuator X activates hardware latch within 20 ms
  of receiving positive input

27
Reminder Evolutionary Delivery
Software concept
Preliminary requirements analysis
Deliver final version
Design of architecture and system core
Develop version
We have been looking at this part of the lifecycle
Incorporate customer feedback
Deliver version
Elicit customer feedback
28
Now Implement system core
Software concept
Preliminary requirements analysis
Deliver final version
Design of architecture and system core
Develop version
Now we progress into the first development
cycle -- the system core
Incorporate customer feedback
Deliver version
Elicit customer feedback
29
Produce team structure

• Team structure is (or can be) closely tied to
  architectural divisions
• Communication between teams mirrors communication
  between modules
• Make communication between modules of this nature
  as weak as possible a simple socket protocol is
  better than an API (for example)

30
Produce skeletal system

• The first deliverable is a working implementation
  of the system core
• Basic architectural elements in place
• Additional functionality implemented in later
  stages
• Get it working and keep it working
• Careful! Dont confuse architectural elements
  that allow incremental development with stubs
  that are little more than unfinished designs or
  code

31
Context 41 architectural views
End-user Functionality
Programmers Software management
Logical View
Implementation View
Use-Case View
Analysts/Testers Behaviour
Process View
Deployment View
System integrators Performance Scalability Through
put
System engineering System topology Delivery
installation Communication
32
Which (confusingly) maps to

• The Unified Process model set

Logical View
Implementation View
Use-Case View
Process View
Deployment View
Analysis Model
Implementation Model
Use-Case Model
Deployment Model
Design Model
33
41 overview

• Use cases drive the discovery and design of the
  architecture in the initial phases
• The architectural views are the architecturally
  significant subset of the Unified Process models
• Each model is developed further in subsequent
  design, implementation, and test stages

34
Architectural patterns

• Express a fundamental structural organization
  for software systems that provide a set of
  predefined subsystems, specify their
  relationships, include the rules and guidelines
  for organizing the relationships between them

-- Doug Schmidt
35
Architectural patterns (2)

• Provide a layer of structure that is not present
  in styles and tactics
• Pattern-based design is more concerned with the
  essence of how the software works (in my view,
  anyway)
• Has a significant learning curve
• Less likely to be useful for stakeholder
  communication
• We will examine in detail in a future lecture

36
Online resources

• SEI page on ADD
• http//www.sei.cmu.edu/ata/add_method.html
• Papers and articles
• Edward A Lee, Embedded Software
• http//ptolemy.eecs.berkeley.edu/publications/pape
  rs/02/embsoft/
• Phillipe Kruchten, Architectural Blueprints
• http//www.rational.com/products/whitepapers/461.j
  sp
• Bachmann, Bass, Chastek, Donohoe, Peruzzi,
• The Architecture Based Design Method
• http//www.sei.cmu.edu/publications/documents/00.r
  eports/00tr001.html

37
Concluding remarks

• Architectural design is the process of taking
  requirements to an architecture and system core
• Architectural design forms the foundation for
  subsequent iterative development cycles
• Risk producing an overly-elaborate architecture
  for system needs e.g. anticipating changes that
  will never occur