Module 4 Principles of

Architecture Design
 Overview

How to think about the design process

Elaborating Generate and test and Design
Decisions
Two Connected Design Philosophies

Design as a collection of decisions

Design as generate and test
Design as a collection of decisions

One method for thinking about design in the
abstract is that it is a collection of decisions
design decisions

We presented a collection of architectural

design decisions in Module 1.
Questions associated with design
decisions

What decision do I make next?

What are my options?

How do I make this decision?

Is the decision worth recording?
 Design as a process of generate
and test

Another way of thinking of design is as a
process of generate and test. An hypothesis
is
 generated,
 tested against a collection of test cases which
expose weaknesses in the hypothesis, and
 the next hypothesis is generated to react to these
weaknesses.

Generate Test Generate

Initial hypothesis Next
Hypothesis Hypothesis
Questions associated with generate
and test

Where does the initial hypothesis come from?

What are the test cases?

What kind of weaknesses do the test cases
expose?

How is the next hypothesis generated?

When am I finished?
The two perspectives are compatible

The process of generating hypotheses
involves making decisions.

The virtue of having two perspectives is that
the generate and test is a macro process
and the design decisions is a micro
process.

Generate Generate
Test
Initial Next
hypothesis
Hypothesis Hypothesis
Outline

Responsibilities as functionality description

Decisions involved in generating the initial
hypothesis

Decisions involved in testing the hypothesis

Decisions involved in generating the next
hypothesis
Responsibilities as Design Description

A responsibility is a general statement about an
architectural element and include the actions an
element performs, the knowledge an element
maintains, and major decisions an element
makes that affect others.

Responsibilities are widely used in O-O design

Wirfs-Brock, R. and McKean, A. Object Design.

Boston, MA: Addison-Wesley, 2003.
Responsibility Example

An Automated Teller Machine (ATM) provides
money to authorized users who have sufficient
funds on deposit.

Responsibilities can be refined

 An ATM requires a user to provide a PIN as an
authorization
 Currency can be provided in multiple denominations
 No currency is distributed until the ATM has received
confirmation from the banks computer system.
 etc
Deciding on the Initial Design
Hypothesis

Non Greenfield

Greenfield
Non-Greenfield source of initial
hypothesis - 1

From similar successful systems to that
being built. Successful systems similar to
the one being constructed have dealt with
most of the issues facing the current system.

From a legacy system. If the current system
is an extension to a legacy system, then the
initial hypothesis comes from the legacy
system and the next hypothesis will deal with
problems raised through the testing process.
Non-Greenfield source of initial
hypothesis 2

Frameworks. A framework is a collection of
existing code that solves many of the
problems involved in the system being
constructed. E.g.
 Drupal is a content management framework.
 JEE is a framework for server side programming
 Enterprise Service Bus provides essential
services for communication
Greenfield Initial Hypothesis

Need to have a sufficient design to test.

It may be very sketchy to begin. Detail will be added
through test and generation of next hypothesis.

Starting point is based on key aspects of system
 Choose key aspect by isolating essential quality characteristics of
system. We will discuss this in more detail later.

Exercise:
 What are key requirements for

Smart phone

Student registration system

Generation of initial hypothesis

Recall Architectural Decisions from Module 1
 Allocation of Functionality
 Coordination Model
 Data and object Model
 Management of Resources
 Mapping Among Architectural Elements
 Binding Time Decisions

Combine key requirement with architectural decisions to
generate initial hypothesis. (Key requirements will be
discussed later in this course)
Initial hypothesis choice
1. Choose one or two architectural decisions that are
important to achieve key requirements
2. Select pattern as initial hypothesis
 Choose pattern that

Helps satisfy key requirements

Reflects chosen architectural decisions.

Example

Suppose you are designing a trading system
 Key requirement is ability to scale
 Relevant architectural decisions are

Coordination model

Binding time

Initial hypothesis is a enterprise service bus
pattern.
 Allows scaling through adding new processors
 Does not have any trading functionality
 Does not have security functionality

The deficiences will be determined through
testing process.
Another method for choosing the
initial hypothesis

From functional/logical view.

Decompose the functions of the system as
specified by O-O techniques.

Choose decomposition based on coupling
and cohesion of responsibilities.

In this case, the testing will disclose missing
quality attribute requirements that needs to
be addressed.
Testing the hypothesis

Test the hypothesis with a collection of test cases.

The output of the tests will be
 Additional responsibilities that need to be addressed

 List of quality attribute problems

Source of test cases

 Key requirements

 View specific use cases

 Other important use cases

 Other quality attribute requirements

 Architectural decisions
Testing techniques

Thought experiments

Modeling

Simulation

prototypes
Key requirements as test cases

Key requirements are the ones that the

architecture design must satisfy

As such, they are obvious test cases for any
design hypothesis.

Requires understanding quality attributes and
how to think about them.
View Specific Test Cases - 1

There are a collection of quality attribute use cases that should be
used as test cases in addition to the key requirements.

Based on consideration of functionality:
 expected operation exercising major capabilities

 exceptions

 growth and exploratory scenarios

 deferred binding time

 version upgrades

 modification scenarios

Look for
 Allocation of responsibilities to modules

 Responsibilities associated with exception management

 Responsibilities associated with deferred binding time.

View Specific Test Cases - 2

Based on consideration of parallelism:
 two users doing similar tasks simultaneously

 one user performing multiple activities simultaneously

 start-up (creating threads that must be in waiting mode, initializing

connected devices, etc.)
 shutdown (cleaning up similar finishing activities, storing data,
etc.)

Look for
 Points of resource contention (synchronization),

 Opportunities for parallelism (creation of new threads)

 Necessity for killing processes (deleting threads)

 Additional responsibilities to manage points of contention and

clean up
 Management of user state
View Specific Test Cases - 3

Based on consideration of multiple processors
 installation
 initialization
 processing across processors
 messaging over the network
 disconnected operation
 failure of an element (e.g., process, processor, network)

For each test case

 Determine desired policy
 Determine mechanisms to achieve desired policy
 Determine responsibilities to implement chosen
mechanisms
Other sources of test cases

Important use cases
 Will identify responsibilities not yet in design

Other quality attribute requirements
 Will identify shortcomings in achieving quality
attribute requirements that should be considered
during generation of next hypothesis.

Architectural decisions
 Will focus attention on the architectural decision
aspects of the design
When are you done?

Pass all of the tests (unlikely)

Run out of time and budget

Good enough
Summary of hypothesis testing

Use key requirements to identify specific portions of the
current hypothesis that are relevant to the satisfaction of
these requirements

Use understanding of quality attributes to determine
whether the quality attribute requirements are satisfied
by the current hypothesis

Use view specific test cases and key requirements to
determine additional responsibilities that should be
included in the next hypothesis.

Use architectural decisions to focus attention on
architectural details.
Generating alternatives for the next
hypothesis

Tactics

Tactics -> responsibilities

Generating new hypothesis from tactics
and responsibilities
Architectural Tactic

An architectural tactic is a design
decision that improves the performance
of the system with respect to a single
quality attribute

Ideally, tactics are based on models of
the quality attribute.

We will demonstrate by talking about
performance.
 : Module 4

Understanding Performance - 1

Typical performance measures are the
 time from the arrival of an event to the end of the
processing of that event (latency)
 number of events that can be processed in a unit
of time (throughput)

The time to process an event is key in both
measures.

Two basic contributors to the time to process
an event are resource consumption and
blocked time.
 : Module 4

Understanding Performance - 2

Afteran event arrives, either the system is
processing that event and consuming
resources or the processing is blocked for
some reason.

Resources include central processing unit
(CPU), data stores, network communication
bandwidth, and memory.
Understanding Performance - 3

A computation can be blocked from using a
resource because
 there is contention for the resource,
 the resource is unavailable, or
 the computation depends on the result of other
computations that are not yet available.
 : Module 4

Testing for Performance

When testing for performance
 Consider an event that enters the system and/or
travels between processors
 Identify computation requirements
 Identify potential blockages

Use key performance requirements to identify
source of events, sequence of responsibilities,
and compare to desired latency or throughput.
 Queuing Model for Performance

Scheduling
algorithm
arrivals results
queue
server
Routing of
Parameters: messages
Arrival rate
Queuing discipline
Latency can be affected only by
Scheduling algorithm changing one of the parameters.
Service time
Topology
Network bandwidth
Routing algorithm
Controlling Performance Parameters

Architectural means for controlling the
parameters of a performance model
 Arrival rate restrict access, differential rate/charging structure,
constrain message size
 Queuing discipline first-come first served (FCFS), priority
queues, etc.
 Service time

Increase efficiency of algorithms.

Cut down on overhead (reduce inter-process
communication, use thread pools, use pool of DB
connections, etc.).

Use faster processor.

 Scheduling algorithm round robin, service last interrupt first,

etc.
 Topology add/delete processors
 Network bandwidth faster networks
 Routing algorithm load balancing
Performance Tactic Categories

Performance tactic categories and their
goals:
 Resource demand Reduce or manage the
demand for resources.
 Resource management Manage
resources even though the demand for
resources is not controllable.
 Resource arbitration Control contention for
resources through scheduling.
 Performance Tactics
Performance

Resource Resource Resource

Demand Management Arbitration

Increase Computation Introduce Scheduling Policy

Efficiency Concurrency Synchronization Policy
Reduce Computational Maintain Multiple
Overhead Copies
Manage Event Rate Increase Available
Control Frequency of Resources
Sampling
Tactics are transformations on
responsibilities and structure- 1

A tactic is one (or more) of the following
types of transformations
 modify responsibility. The tactic increase
message content can be achieved by modifying
the responsibilities that construct messages to
construct larger messages.
 introduce new responsibilities. The tactic
introduce concurrency requires that
responsibilities for forking the concurrent
threads and joining those threads together be
introduced.
 Introduce new structural elements. The tactic
maintain multiple copies requires elements to
store the new copy and maintain consistency
among the copies.
Tactics are transformations on
responsibilities and structure- 2.

modify the properties of a
responsibility. The tactic reduce
execution time will result in a
modification of a property
(execution time) of the
responsibility that is being made
more efficient.
 decompose responsibilities.
The tactic maintain multiple
Trade offs

Using a tactic improves the system with
respect to one quality attribute but may
decrease it with respect to others.

Testing will discover this but

May want to choose tactic based on
understanding of what trade offs it introduces.
Generate next hypothesis

At this point we have as a result of the test phase

 Additional responsibilities as a result of responsibilities
discovered through test cases or through tactics
 Revised responsibilities as a result of decomposition.

 Constraints on the allocation of responsibilities to modules as as

result of tactics
 Other constraints on responsibilities such as budgeted execution
time

These responsibilities and their constraints are merged
with the current hypothesis to generate the next
hypothesis.
Exercise

Consider quality attribute we elaborated in
Module 3

What are the tactics to achieve this quality
attribute.
Summary

Design is the combination of process of generate and test and
making decisions.

The initial design is generated from existing or similar systems,
frameworks and components, or patterns.

Early design decisions inform the initial hypothesis

The design is tested against the key requirements and a collection
of quality attribute test cases to derive additional responsibilities and
constraints on responsibilities.

The design is analyzed against quality attribute models to discover
shortcomings.

Tactics are used to propose alternatives for improving the design

The next hypothesis is generated based on additional
responsibilities and constraints discovered during test and analysis.