Software Architecture

and Design
Guidance for the Architect – I

Nguyen Huu Quoc

Lecturer
IT Department
Van Lang University

© 2009, Based on Anthony J. Lattanze’s Lectures

Lecture Topics
During this session we will provide guidance for
architects designing the architecture, specifically, we
will:
 discuss when architecture design occurs in the development
lifecycle
 introduce strategies for decomposition
 provide guidance for designing the architectures
 examine tradeoffs inherit in the architecture design process
This is not a “how to architect” lecture but rather
general guidance for architects

2/33
 Key Questions…
Scope: who are we creating the architecture for?

Timing: When do we architect? Mechanics: How do we architect?

3/33
Timing – 1
Business constraints often influence how and
when architectures are designed
 prescribed schedule of deliverables
 geographically distributed development environment
 size and structure of the organization
 prescribed delivery dates
 prescribed lifecycles, processes, tools,…
Before architecture design begins, it is
necessary to understand these factors and adjust
our design strategy appropriately

4/33
Timing – 2
Preconditions – architectural drivers
 technical and business constraints
 high level functional requirements
 quality attribute requirements
Outputs – design decisions
 architectural decomposition: elements,
responsibilities, relations, and interfaces
 initial documentation including
• representations of the software architecture from the
3 primary perspectives
• data, rationale, descriptive prose, and so forth

5/33
Timing – 3
Detailed requirements specifications are not
required (or often possible) before architecture
design begins
 As you discover architectural drivers and analyze
them, you will discover more about the requirements
space
• usually not new requirements, but a clearer understanding
of exiting requirements
 Architecture design provides a natural springboard
for refining and stabilizing requirements and helps
uncover potential problem areas - All of the
requirements will mature as the architecture is
designed
 This is why design should be incremental and
iterative –but more on 6/33
this later!
Scope – 1
 The architectures of large software intensive
systems are often hierarchical
 one architect's design space is another architect's
element
 may necessitate the use of enterprise and/or system
architectures in addition to software architectures
 usually requires teams of architects

7/33
 Scope – 2

System or
Enterprise
:

Systems
:

What downstream designer or

Software
implementer will you constrain?
... :
...

8/33
 Guidance For the Architect*
Establish perspective and set context
Select a perspective, and begin decomposition
Switch perspective as necessary and continue
decomposition and refinement
Document as you design
Evaluate the architecture
Iterate as necessary

* This is not to imply temporal order.

* Today we will assumes that the architect is engaged in “green field” development.

9/33
 Example
To illustrate the message of this session we will
use the aircraft simulator as an example.
 pilot input: rudder, elevator, aileron, throttle
 output: simulator displays, simulator motion

10/33
Business Context
 Let's assume that we are sub-contractors
building the software for a prime contractor
responsible for building the simulator
 the goal is to build a low cost, general, portable
training, simulator
 simple servo gimbal based motion control
 support for up to 3 (243cm x 138cm x 9.5cm) flat
panel displays for out-the-cockpit views
 1 small flat panel display for instrumentation
 Intel based processors – multiple processors is OK
 Prime contractor is responsible for the gimbal,
simulator housing, pilot controls (rudder,
elevator, ailerons, throttle) and displays
11/33
Simulator Hardware

Side View Top View

12/33
Key Requirements – 1
 Accept input from the pilot via rudder,
aileron, elevator, throttle controls and
 update 3 displays to provide out-of-the cockpit
views
 update instrumentation display (altitude,
artificial horizon, heading, fuel, RPM, rate of
ascent/descent)
 move gimbal to simulate aircraft forces on the
pilot in the simulator
 The system must support basic flight
instruction over a basic terrain, but allow a
range of aircraft to be simulated by
permitting easy configuration of flight rules
during setup/startup
13/33
 Key Requirements – 2
 The system must provide instantaneous response (display and
motion update) to pilot input to provide a realistic experience
and to prevent simulator sickness
 The system must be easy to disassemble and move to another
location
 use standard US power plug and 110v
 Permit the edition of new fight controls after deployment

Clearly, refinement and analysis of these requirements

would be required before design could begin…

14/33
Set Context – 1
 Where do you as the software architect fit into
the larger picture?
 system, enterprise, software, all of it?
 What kind of downstream engineer will your
architecture constrain?
 architects, detailed (software) designers, coders?
 What is internal and external to the
architecture you are designing?
 external data sources, events, interfaces
 legacy systems
 environmental factors

15/33
Set Context – 2
Left display
rudder
right display
elevator Simulator
aileron center display
Software instrumentation
throttle
gimbal

System boundary
You are System input
aileron here.
System output
System

Is there anything you might add? Why or why not?

16/33
Guidance For the Architect
 Establish perspective and set context
 Select a perspective, and begin decomposition
 Switch perspective as necessary and continue decomposition and refinement
 Document as you design
 Evaluate the architecture
 Iterate as necessary

17/33
Decomposition – 1
 The system context sets the stage for subsequent
decomposition of the system
If the system context is inaccurate, incomplete, or never
precisely established, the subsequent decomposition
and resulting implementation may suffer
 ill defined responsibilities between organizations
 undefined inputs/outputs
 integration difficulties (compounded in distributed
development)
 mismatched expectations

18/33
Decomposition – 2
Historically, decomposition has been driven
by functionality
However, as we discussed, the structure of a
system generally has little to do with pure
functionality and more with the satisfaction
of:
 constraints: Constraints become “load-bearing
walls” in the design space. We can only satisfy
or negotiate to relax them
 quality attributes: Quality attribute requirements
are often intertwined with functionality, but
satisfying the quality attribute response measure
usually comes down to structure
19/33
Example – QA Scenarios
 Assume that we have the following high
priority quality attribute scenarios:
The system is to be redeployed in a new location. The system can be
disassembled and packed for transportation in 4 hours and
reassembled at the new location in 4 hours

The simulator must be reconfigured to simulate a high performance

airplane. The system is shut down, the new flight rules for the high
performance airplane are loaded, the system is restarted and ready
for use in no more than 15 minutes

Under normal operation for any air vehicle configuration, the simulator
software samples all pilot input and is able to refresh/update all
displays at a rate of 75Hz

20/33
Select A Starting Element – 1
Select initial perspective as decompose –
remember it as you decompose; switch
perspectives as a conscience act!
Select an overall architectural pattern that satisfies
the key architectural drivers
 Some problems may suggest a particular pattern
• Patterns are starting points and need to be refined.
• While systems may exhibit an overall pattern, real systems
are composed of ensembles of patterns
 A single pattern cannot maximize all the required
architectural drivers – tradeoffs will be made
 This highlights the importance of prioritizing
architectural drivers
21/33
Select A Starting Element – 2
If a starting pattern isn't obvious, decomposition
starts with “the system”
 Use all architectural drivers to guide decomposition
 Begin with constraints, then QAs, and finally
functionality
 The system decomposed into “elements” that are
consistent with the perspective
structures
Constrains
Architecture
Quality attributes Design
Forces . Design
High level functionality
.
Architect

22/33
Example – 1
Consider the fight simulator example
 A key constraint is that we must use Intel processors.
Does this force us into other constraints such as:
• using a particular language
• using a particular OS
 Next what quality attributes might drive our
decomposition
• ability to add controls to the simulator
• ability to change flight rules, physical portability
• performance needs,... or something else?
These factors should motivate your intuition

23/33
Example – 2
A simulator is a classic control system and that
there are two potential patterns we can consider:
 polling pattern
 interrupt/event pattern
Do either of these seem like a reasonable starting
position?
What are the merits and shortfalls of each
pattern?
What might motivate the selection one of these
patterns or some other approach?

24/33
 Example – 3
A big concern was performance. To address this QA we
need to study the system from a runtime perspective
and decompose the system into processes. We know
System boundary
that polled loops are fast and deterministic, but a
single loop is limited (in terms of performance) –
maybe concurrent loops?
System input

System output

System

rudder Left display

right display
elevator Simulator center display
aileron
throttle Software instrumentation
gimbal

Left display
right display Update Display rudder
center display Loop Read Input elevator
instrumentation
Repository Loop aileron
Gimbal X
Gimbal Y Gimbal Update throttle
Gimbla Z Loop
Data Data
process Data storage write read
25/33
 Example – 4
Note that decomposition is (and should be) guided in part by intuition and
experience
 A knowledge of structures is helpful and will often temper instinctive, reactionary
decisions
Notice that while the predominate pattern is the polling pattern; a
repository is also used
 Again, real systems are ensembles of patterns
Notice that the application of concurrency is applied as a tactic* to the
initial pattern selection to further promote performance

26/33
Guidance For Decomposition – 1
 The goals of initial decomposition are to
decide upon the gross partitioning of the
system into elements and proceed to refine the
elements through further decomposition
 After the initial decomposition, element
decomposition proceeds iteratively
 assign responsibilities derived from the
architectural drivers to the elements as appropriate
 refine elements by selecting subordinate patterns
and/or further decompose elements as necessary
 applying refining tactics as appropriate
 develop and define the interfaces of subordinate
elements
27/33
Guidance For Decomposition – 2
 As you decompose the system:
 Be consistent of perspective and with the
elements and relations of the perspective
 It is helpful to create the legend first
 Order of decomposition/refinement will vary
 Need for special expertise – specific skills to be
fully utilized argues for depth first decomposition
 Knowledge of domain – no major unknowns
argues for breadth first decomposition
 New technology – requirement for prototypes
argues for depth first decomposition

28/33
Assigning Responsibilities
 Responsibilities are derived from the
architectural drivers
 functional requirements: use cases, textual
descriptions
 quality attribute scenarios
 technical and business constraints
 Functional responsibilities and technical
constraints are usually assigned to specific
elements for satisfaction
 Quality attribute and some business
constraints are often satisfied by the very
partitioning of the system
29/33
 Example Responsibilities
Overall Structure: The overall structure was selected to maximize performance
of the system and features three concurrent loops,… Rejected alternative
include… reasons include…
Read Input: Samples input from the pilot's controls and writes data into a current
value table…
Repository: Volatile memory that houses the current value table (CVT). This
structure contains the most current values sampled from the pilot input
Update Displays: Reads data from the CVT and updates the out-of-the-cockpit
displays based upon the configured vehicle flight rules…
Gimbal Update: Reads data from the CVT and writes data to the gimbal control
hardware moving the simulator based upon the configured vehicle flight rules…

Left display
right display Update Display rudder
center display Loop Read Input elevator
instrumentation
Repository Loop aileron
Gimbal X
Gimbal Y Gimbal Update throttle
Gimbla Z Loop
Data Data
process Data storage write read

30/33
Refining The Elements
 After initial decomposition and assignment of
responsibilities, recursively decompose and
refine each element of the system
 assign responsibilities to elements from the
architectural drivers
 complement architectural patterns or the initial
decomposition with tactics
 refine the subordinate elements
 define interfaces of subordinate elements
 We will continue with refinement in our next
session together…

31/33
Summary
 In this session we:
 set the context for design and discuss the
purpose, role, and important of explicitly defining
the system context as the first step in architectural
design
 discussed those things that should motivate the
initial decomposition
 introduced the notion of explicitly defining
elements and relationships
 started to discuss hierarchical decomposition and
element refinement

32/33
Questions & Answers

33/33