SOFTWARE DESIGN AND ARCHITECTURE

LECTURE 16-18
Ms. Rabia Iftikhar Disclaimer:
presentation
The
have
contents
been
of
taken
this
from
multiple sources, i.e. Books, Research
rabia.iftikhar@faculty.muet.edu.pk articles, Thesis publications, and
websites.
 Fair Use Notice

The material used in this presentation i.e., pictures/graphs/text, etc. is solely

intended for educational/teaching purpose, offered free of cost to the students for
use under special circumstances of Online Education due to COVID-19 Lockdown
situation and may include copyrighted material - the use of which may not have
been specifically authorised by Copyright Owners. It’s application constitutes Fair
Use of any such copyrighted material as provided in globally accepted law of many
countries. The contents of presentations are intended only for the attendees of the
class being conducted by the presenter.
Outlines
Architecture in Life Cycle
Attribute Driven Design (ADD)
Architecture Trade off Analysis Method (ATAM)
Pre-architecture life cycle
stakeholders
requirements quality
(few)

agreement

development
Characteristics
 Iteration mainly on functional requirements

 Few stakeholders involved

 No balancing of functional and quality requirements

Adding architecture, the easy way
stakeholders
requirements quality
(few)

agreement

architecture

detailed design development

implementation
Architecture in the life cycle
stakeholders
(many)

requirements quality

architecture

agreement

development
Characteristics
 Iteration on both functional and quality requirements

 Many stakeholders involved

 Balancing of functional and quality requirements

Attribute-Driven Design
 Choose module to decompose
 Refine this module:
 choose architectural drivers (quality is driving force)
 choose pattern that satisfies drivers
 apply pattern

 Repeat steps for every module that needs further decomposition

Example ADD iterations
 Top-level: usability  separate user interface  three tier architecture

 Lower-level, within user interface: security  authenticate users

 Lower-level, within data layer: availability  active redundancy

Global workflow in architecture design
synthesis architecture
context

evaluation
backlog

evaluation
requirements
results
Design issues, options and decisions
A designer is faced with a series of design issues
◦ These are sub-problems of the overall design problem.
◦ Each issue normally has several alternative solutions (or design options)
◦ The designer makes a design decision to resolve each issue.
◦ This process involves choosing the best option from among the alternatives.
 Taking decisions
Design Problem space
problem

sub- sub-
problem problem
(or issue) (or issue)

Decision =
best option Decision space
Design Design Design Design
option option option option

Decision =
Alternative Alternative best option
solutions solutions
 Decision space
The space of possible designs that can be achieved by choosing different sets of alternatives.

fat-client client in a Programmed in Java

separate
client-server user interface
client layer
style
thin-client Programmed in Visual Basic

Programmed in C++

no separate
monolithic user interface
layer

SE, SOFTWARE ARCHITECTURE, HANS VAN VLIET, ©2008 14

Types of decisions
 Implicit, undocumented
 Unaware, tacit, of course knowledge

 Explicit, undocumented
 Vaporizes over time

 Explicit, explicitly undocumented

 Tactical, personal reasons

 Explicit, documented
 Preferred, exceptional situation
Why is documenting design decisions
important?
 Prevents repeating (expensive) past steps
 Explains why this is a good architecture
 Emphasizes qualities and criticality for requirements/goals
 Provides context and background
Elements of a design decision
Issues: design issues being addressed
Decision
Status: e.g., pending, approved
Assumptions: underlying assumptions
Alternatives
Rationale; the why of the decision taken
Implications: e.g. need for further decisions
ARCHITECTURAL
ASSESSMENT
Architecture evaluation/analysis
 Assess whether architecture meets certain quality goals, such as those w.r.t. maintainability,
modifiability, reliability, performance

 Mind: the architecture is assessed, while we hope the results will hold for a system yet to be
built
Analysis techniques
 Questioning techniques: how does the system react to various situations; often make use of
scenarios

 Measuring techniques: rely on quantitative measures; architecture metrics, simulation, etc

Scenarios in Architecture Analysis
 Different types of scenarios, e.g. use-cases, likely changes, stress situations, risks, far-into-the-
future scenarios

 Which stakeholders to ask for scenarios?

 When do you have enough scenarios?

Preconditions for successful assessment
 Clear goals and requirements for the architecture
 Controlled scope
 Key personnel availability
 Competent evaluation team
 Managed expectations
Benefits
 Financial gains
 Forced preparation
 Captured rationale
 Early detection of problems
 Validation of requirements
 Improved architecture
Participants in ATAM (Architecture
Trade Off Analysis Method)
 Evaluation team (3 to 5 people with different roles)

 Decision makers

 Architecture stakeholders (probably 12 to 15 people)

Phases in ATAM
0: partnership, preparation (informally)

1: evaluation (evaluation team + decision makers, one day)

2: evaluation (evaluation team + decision makers + stakeholders, two days)

3: follow up (evaluation team + client)

 Steps in ATAM (phase 1 and 2)
 Present method
 Present business drivers (by project manager of system)
 Present architecture (by lead architect)
 Identify architectural approaches/styles
 Generate quality attribute utility tree (+ priority, and how difficult)
 Analyze architectural approaches

 Brainstorm and prioritize scenarios

 Analyze architectural approaches
 Present results
Example Utility tree
Transaction response time (H, M)
Performance
Throughput 150 transactions/sec

Training
Utility Usability
Normal operations

Database vendor releases

Maintainability new version
Outputs of ATAM
 Concise presentation of the architecture
 Articulation of business goals
 Quality requirements expressed as set of scenarios
 Mapping of architectural decisions to quality requirements
 Set of sensitivity points and tradeoff points
 Set of risks, nonrisks
Important concepts in ATAM
 Sensitivity point: decision/property critical for certain quality attribute
 Tradeoff point: decision/property that affects more than one quality attribute
 Risk: decision/property that is a potential problem