Software Architecture

Lecture 5

Roadmap of the course

What is software architecture?
Designing Software Architecture
Requirements: quality attributes or qualities
How to achieve requirements : tactics
How do tactics lead to architectural styles
Case studies on architectural styles, observe the achieved qualities
The ADD method

Documenting software architecture

Today: Bass and all
Next time: Hofmeister and all

10.2.2010

SA definition
Software architecture of a program or computing

system is the structure or structures of the system,

which comprise software elements, the externally visible
properties of those elements, and the relationships
among them. (Bass et all)
Software architecture describes the element types, how
they interact, how functionality is mapped to them, and
the instances that exist in the system. (Hofmeister et all)

10.2.2010

What is a view?
Modern software systems are complex
We focus at any time on a small number of structures of the

system (view)
View representation of a coherent set of architectural
elements, as read/written by system stakeholders (plus
relations)
Structure set of architectural elements as they exist in
software or hardware

10.2.2010

Architectural structures
Module structures
Component-and-connector structures
Allocation structures

10.2.2010

SA structures
Module

Component-and-connector

Concurrency

Decomposition

Allocation

Work
Assignment

Class

Uses

Shared data

Deployment

Client-server
Process
Layered

10.2.2010

Implementation

Module structures
Elements:
Modules units of implementation
Code-based way of considering the system
Assigned areas of functional responsibility
Less emphasis on how resulting SW manifests at runtime
Questions answered here:
Primary functional responsibility of each module
What other SW elements can this module use
Hierarchies

10.2.2010

Component-and-connector structures
Elements:
Runtime components main units of computation
Connectors communication vehicles between components
Questions answered here:
Major executing components and their interactions
Major shared data stores
Replicated parts, data flows, parallel system parts
Changes in system structure as it executes

10.2.2010

Allocation structures
Show the relationship between software elements and

elements in one/more external environments

Where SW is created and executed

Questions answered here:

Processors each SW element executes on
Files for storing elements during system lifetime
Assignment of SW elements to development teams

10.2.2010

Structures and decision types

How is the system to be structured as a set of code units

(modules)?
How is the system to be structured as a set of elements with
running behavior (component) and interactions (connectors)?
How is the system to relate to non-SW structures in the
environment
CPUs, file systems, networks, development teams

10

10.2.2010

Module-based structures
Decomposition
Shows how larger modules are decomposed into smaller ones
Units: modules related by is a submodule of
Recursive decomposition
Common starting point of design
Architect enumerates what the SW units will do
Assigns each item to a module for subsequent detail or implementation

11

10.2.2010

Module-based structures, 2
Decomposition
Modules often have associated products
Interface specs, code, test plans
Provides for system modifiability
Often used as basis for project organization
Structure of documentation, integration, test plans
Units often have organization-specific names

12

10.2.2010

Module-based structures, 3
Uses
Important, often overlooked structure
Units: modules, procedures, resources on the interface of

modules
Units related by uses relation

Unit A uses unit B if the correctness of A requires the presence of a

correct version of B
As opposed to a stub

Used to engineer extendable systems

13

10.2.2010

Module-based structures, 4
Layered
Uses relation controlled in a particular way
Layer: coherent set of related functionality
Layer n may only use services of layer n-1
Many variations occur in practice
Relaxing this structural restriction
Layers designed as abstractions that hide implementation

specifics below from layers above

14

10.2.2010

Module-based structures, 5
Class/generalization
Units: classes
Relation: inherits-from, is-an-instance-of
Supports reasoning about
Collections of similar behaviors or capabilities
Parameterized differences (sub-classing)
Reuse, incremental addition of functionality

15

10.2.2010

Component-and-connector-based
structures
Process (communicating processes)
Orthogonal to module-based structures
Deals with dynamic aspects of a running system
Units: processes or threads
Connected by communication, synchronization, exclusion operations
Relation: attachment
Describes how component and connector related to each other
Important to systems execution performance and availability

16

10.2.2010

Component-and-connector-based
structures, 2
Concurrency
Units: components connected by logical threads
Sequence of computation
Can be allocated to a physical thread later
Allows architect to determine
Opportunities for parallelism
Location where resource contention may occur
Used early in design to identify concurrent execution issues

17

10.2.2010

Component-and-connector-based
structures, 3
Shared data, repository
Comprises components and connectors that
Create, store, access persistent data
Useful for systems structured around shared data repositories
Shows how data is produced and consumed by runtime SW

elements
Can be used to ensure performance and data integrity

18

10.2.2010

Component-and-connector-based
structures, 4
Client-server
Useful for systems built as cooperation of clients and servers
Components: clients and servers
Connectors: protocols, messages between them, for carrying

out the system work

Useful for

Separation of concerns (modifiability)

Physical distribution
Load balancing (runtime performance)

19

10.2.2010

Allocation-based structures
Deployment
Shows how SW is assigned to HW-processing and

communication elements
Elements

SW (process from C&C view)

HW entities (processors)
Communication pathways

20

10.2.2010

Allocation-based structures, 2
Deployment, 2
Relations
Allocated-to: shows on which physical units the SW elements reside
Migrates-to: if allocation is dynamic
Allows engineer to reason about
Performance, data integrity, availability, security
Of particular interest in distributed or parallel systems

21

10.2.2010

Allocation-based structures, 3
Implementation
Shows how SW elements (modules) are mapped to the file

structure(s) in

The systems development

Integration
Configuration control

Critical for management of

development activities
build processes

22

10.2.2010

Allocation-based structures, 4
Work assignment
Assigns responsibility for implementing and integrating the
modules to appropriate teams
Emphasizes that decision about who does what has architectural
and management implications
Architect knows expertise required of each team
Large, multi-sourced distributed development projects
This structure allows to have units of functional commonality

implemented by a single team rather than by everybody

23

10.2.2010

Relating structures to each other

Each structure provides a different perspective and design handle on

a system
Structures not independent
We need to reason about the relations
Typically many-to-many

Sometimes one structure is dominant

Other structures cast in terms of it
Exp: Module decomposition

24

10.2.2010

Relating structures to each other, 2

Not all systems consider many structures
Big vs small

Structures
Main engineering leverage points of an architecture
Bring with them the power to manipulate one/more quality attributes
Powerful separation of concerns approach
Useful for architecture documentation

25

10.2.2010

Which structures to choose?

Many approaches
Kruchten, 1995: Four+1
Focus on four structures
Logical, process, development, physical
Ensure they are not in conflict and do the job:
Key use cases as a check
Rational Unified Process
Soni, Nord, Hofmeister, 1995:
Conceptual, module, execution, code

26

10.2.2010

Which structures?
Among architects obligations
Understand how the various structures lead to quality attributes
Choose the structures that will best deliver those attributes

27

10.2.2010

Summary of architectural structures

Software
structure

Relations

Useful for

Decomposition

Is a submodule of;
shares secret with

Resource allocation, project

structuring, planning; information
hiding, encapsulation, configuration
control

Uses

Requires the correct Engineering subsets; engineering

presence of
extensions

Layered

Requires the correct Incremental development;

presence of; uses
implementing systems on top of
the services of;
virtual machines portability
provides abstraction
to

Class

Communicates with; In OO design systems producing

depends on
almost-alike implementations from
common template

Summary of architectural structures, 2

Software
structure

Relations

Useful for

Client-server

Communicates with;
depends on

Distributed operation; separation

of concerns; performance
analysis; load balancing

Process

Runs concurrently with; Scheduling analysis;

may run concurrently
performance analysis
with; excludes;
precedes; etc

Concurrency

Runs on the same

logical thread

Identifying locations where

resource contention exists;
where threads may fork, join, be
created or be killed

Shared data

Produces data;
consumes data

Performance, data integrity,

modifiability

Summary of architectural structures, 3

Software
structure

Relations

Useful for

Deployment

Allocated-to; migratesto

Performance, availability, security

analysis

Implementation

Stored in

Configuration control, integration,

test activities

Work
assignment

Assigned to

Project management; best use of

expertise; management of
commonality

10.2.2010

30

Summary of architectural structures, 4

We often think of systems structure in terms of its functionality
There are system properties in addition to functionality
Physical distribution
Process communication
Synchronization, etc

Each structure: related to quality attributes

Uses structure: engineered to build an extendable system
Process structure: engineered to eliminate deadlocks and bottlenecks
Module decomposition structure: engineered to build a modifiable

system

31

10.2.2010

Common Architectural Idioms

Data flow systems

32

Batch sequential
Pipes and filters
Call-and-return systems
Main program & subroutines
Hierarchical layers
OO systems
Virtual machines
Interpreters
Rule-based systems
Independent components
Communicating processes
Event systems
Data-centered systems (repositories)
Databases
Blackboards
20-Jan-10

Using SA
Blueprint for system and project developing it
Defines work assignments
Primary carrier of system qualities
Artifact for early analysis
Post-deployment system understanding, maintenance,

mining efforts
Conceptual glue

For all phases of the project

For all stakeholders

33

10.2.2010

Documenting SA
Crowning step to crafting it
Good architecture is useless if not understood or wrongly

understood
Architecture should be described
in sufficient details
without ambiguity
organized for information retrieval

34

10.2.2010

Uses of SA documentation
one size fits all does NOT work
Documentation depends on how SA will be used
Documentation should be
Abstract enough for new employees
Detailed enough as analysis blueprint
Specific for specific stakeholders
Security analysis, programmers
Experienced, new

35

10.2.2010

SA documentation
Prescriptive
Prescribes what should be true by placing constraints on
decisions to be made
Descriptive
Describes what is true by recounting decisions already made
about system design
Different stakeholders have different needs
For information kinds, levels, treatments
Stakeholder should quickly find the relevant documentation

36

10.2.2010

SA documentation 2
Single documentation suite and a roadmap
Different stakeholders can navigate through it

Easy to read
One important user of the documentation
The architect in the projects future
Same architect: repository of thought, storehouse of design decisions
Different architect: check how predecessors tackled difficult tasks, why
some decisions made

37

10.2.2010

Views and SA documentations

Basic principle of documenting SA: Documenting the

architecture is a matter of
Documenting the relevant views
2. Adding documentation that applies to more than one view
1.

Parts in documenting
Choosing relevant views
2. Documenting each relevant view
3. Documenting info that applies to more than one view
1.

38

10.2.2010

Choosing relevant views

Needed documentation package is based on
Who the stakeholders are
The future uses of documentation
Quality attributes

Different views
Support different goals and users
Highlight different elements and relationships
May be specific to the system

39

10.2.2010

Choosing relevant views 2

Produce candidate view list (matrix)
List stakeholders
List needed views
Fill in amount of cell info: none, overview only, moderate

detail, high detail

40

10.2.2010

Choosing relevant views 3

Combine views
Too many views
Remove views with overview only info
See if stakeholders of the above can be served by other views

with more needed info

Combine views
Prioritize

Decide what to do first

41

10.2.2010

Documenting a view
Need for standard organization
Allocating specific info to specific sections =>
Documentation writer can approach the task
Documentation writer can recognize completion
Documentation reader finds info of interest

42

10.2.2010

Example of table

Documenting a view 7 parts

Primary presentation
Element catalog
Context diagram
Variability guide
Architecture background
Glossary of terms
And brief description of each

Other info

44

10.2.2010

Primary presentation
Elements and relationships among them that populate the

view

Not necessarily all of them

Should contain the info to be conveyed about system

Exp: normal operation here, exception and error handling in

documentation

Usually graphical, sometimes tabular

45

10.2.2010

Element catalog
Details at least the elements and relationships shown in primary

presentation
Backup for primary presentation
Elements and relations omitted from primary presentation
Belong here
Introduced and explained

Describes
The behavior of elements
The interfaces of elements

47

10.2.2010

Context diagram
Shows how system in the view relates to environment in

vocabulary of view
Exp: C&C view

Show which component and connectors interact with external

components and connectors

Via which interfaces and protocols

48

10.2.2010

Variability guide
Shows how to exercise any variation points part of the

architecture in the view

Exp of variability: product lines
Includes documentation about each point of variation in
architecture, including
The options among which the choice is to be made
Module view: various parameterizations of modules
C&C view: constraints on replication, scheduling, protocol choice
Allocation view: conditions of allocation
The binding time of the option
Design, build, runtime
49

10.2.2010

Architecture background
Explains why the design reflected in the view came to be
Why it is as it is
Provides convincing argument that it is sound
Includes
Rationale: why decisions reflected in view were made and why
alternatives were rejected
Analysis results: justifies design or explain what would have to change
in case of modification
Assumptions reflected in the design

50

10.2.2010

Other information
Contents of this section vary according to standard practice

of the organization
Non-architectural info can come here
May include

Management information
Authorship, change histories, configuration control data
References to specific sections of a requirements document for

traceability

By the architect

First part of this section must detail its specific contents

51

10.2.2010

Documenting behavior
Structural information (views) not enough
Exp. deadlock not captured

Behavior descriptions add info on

Ordering of interactions among elements
Opportunities for concurrency
Time dependencies of interactions

Behavior documented about

An element or elements working in context

52

10.2.2010

What behavior to model

Real-time embedded system
Timing properties
Time of events

Banking system
Event sequence more important than actual time
Atomic transaction
Rollback procedure

53

10.2.2010

Behavior notations
Statechart diagrams

Formalism for reactive systems

Reason about the whole system
Abstraction and concurrency
Can reply to will the response time to this stimulus always be less
than 0.5 s?

Sequence diagrams

54

Document sequences of stimuli exchanges

Collaboration in terms of component instances and their interactions
Time sequence shown
Can reply to what parallel activities occur when the system is
responding to these specific stimuli under these specific conditions?

10.2.2010

Documenting interfaces
Interface: boundary between entities
Over boundary elements interact and communicate

Interfaces are architectural

They carry the properties externally visible to other elements

Consists of
Naming and identifying interface: signature
Document its syntax and semantics

55

10.2.2010

Signature
Exp: interface resources are invokable programs
Signature names the programs
Signature defines their parameters

Parameters defined by their

Order, data type, whether or not their value changed by

program

C/C++ header file, Java interface

56

10.2.2010

Signature use
Can enable automatic build-up checking
Signature matching
Guarantees a system compiles or links successfully
Does not guarantee if the system operates successfully
We need semantics of interface for that
What happens when resources are brought into play

57

10.2.2010

Whats in an interface specification?

Statement of element properties the architect chooses to

make known
Architect should choose:

The permissible and appropriate information to be assumed

about the element

The information unlikely to change
Balance needed
Focus on how elements interact in their operational environment, on
externally visible phenomena
Not on how the element is implemented!

58

10.2.2010

Document only once

Modules correspond to one/more elements in C&C view
These elements are likely to have similar/identical interfaces
Documenting in both places: needless duplication
Refer to the earlier specified interface and only add the info

specific to the later specified view

59

10.2.2010

Template for documenting interfaces

Needed; one possibility

1.
2.

Interface identity
Resources provided

3.
4.
5.
6.
7.
8.
9.

60

Resource syntax, semantics, usage restriction

Data type definition

Exception definition
Variability provided by interface
Quality attribute characteristics of interface
Element requirements
Rationale and design issues
Usage guide
10.2.2010

Documenting element interface

61

10.2.2010

Interface identity
For elements with multiple interfaces
Identify individual interfaces to distinguish them
Naming, version number

62

10.2.2010

Resources provided
Heart of an interface document: resources that the element

provides

Their syntax: resource signature

Includes the information another program will need for writing a
syntactically correct program that uses the resource
Name, names and data types of arguments, etc
Their semantics: result of invoking the resource
Any restrictions on their use

63

10.2.2010

Resource semantics
In natural language, or Boolean algebra, or traces
What:
Assignment of values to data accessible by the actor invoking the
resource
Signaled events, sent messages
Future behavior of other resources as result of using the
resource
Humanly observable results
Resource execution: atomic/suspended/interrupted

64

10.2.2010

Resource usage restrictions

The circumstances under which the resource may be used
Needed initialization or methods to be invoked before
Limit on number of actors that can interact with the resource
Read/write accesses
Security issues
etc

65

10.2.2010

Data type definitions

If interface resources employ non-standard data type, the

architect needs to communicate the definition of that type

If defined by another element: reference

Programmers need to know

How to declare variables and constants of the data type
How to write literal values in the data type
What operations and comparisons may be performed on members of
data type
How to convert values of data type into other data types

66

10.2.2010

Exception definition
Exceptions raised by the interface resources
Same exception may be raised by more than one resource
List each resource exceptions
Define them in a dictionary collected separately
Common exception handling also defined here

67

10.2.2010

Variability provided by the interface

Does interface allow element configuration?
If so, document
the configuration parameters
Their effect on the semantics of interface
Exp: capacities of visible data structures, performance of underlying

algorithms
What

Name and range of values for each parameter

Time when its actual value is bound

68

10.2.2010

Quality attribute characteristics of

interface
Document the quality attribute characteristics the interface

makes known to the element users

Exp: constraints on implementations of elements that will
realize the interface

69

10.2.2010

Element requirements
Specific, named resources provided by other elements
Syntax, semantics, any usage restrictions

Often convenient to document this info as a set of

assumptions that the element has made about the system

They can be reviewed by experts who can confirm or repudiate

the assumptions before design has progressed too far

70

10.2.2010

Rationale and design issues

Architect needs to record the reasons for an element

interface design

Motivation behind design, constraints, compromises

Considered alternative designs
Why the above rejected
Insight the architect has about changing interface in the future

71

10.2.2010

Usage guide
Semantics of resource:
Provided resources + element requirements
Sometimes not enough
Semantics needs to be reasoned about in terms of HOW a broad
number of individual interactions interrelate
Protocol: sequence of interactions documented
Complete behavior of interaction, or
Patterns of usage the element designer expects to come up repeatedly

Static behavioral model useful

72

10.2.2010

Documentation across views

Captures info applicable to

More than one view

The documentation package as a whole

3 major aspects
1.

How the documentation is laid out and organized, so that stakeholder

finds info efficiently and reliably

2.

What the architecture is

3.

Short system overview informing about purpose of system, the way views
relate to each other; list of elements and where they appear; project glossary

Why the architecture is the way it is

73

View catalog and view template

Context of the system, external constraints for the architecture shape,

rationale for coarse grained large-scale decisions

10.2.2010

Documentation across views

74

10.2.2010

How the documentation is organized to

serve stakeholder
View catalog
Readers introduction to views included in the documentation

suit
Using documentation suit as basis for

Communication: necessary for a new reader to determine where

particular info is
Analysis: necessary to know which views contain the info needed for a
particular analysis

75

10.2.2010

How the documentation is organized to

serve stakeholder, 2
View catalog, 2
One entry per each view in documentation suit
Each such entry
View name and what style it instantiates
Description of the views element types, relation types, properties
Description of what the view is for
Management info about the view document (latest version, location and owner
of view document)

76

10.2.2010

How the documentation is organized to

serve stakeholder, 3
View template
Standard organization for a view
Helps reader navigate quickly to a section of interest
Helps writer organize the info
Helps writer establish criteria for knowing how much work is left to

do

77

10.2.2010

What the architecture is

System overview
Short prose description of
What the systems function is
Who its users are
Any important background/constraints
Intent
Provide readers with consistent mental model of the system and its
purpose
If system at large has this, then here we just refer to it

78

10.2.2010

What the architecture is, 2

Mapping between views
Any two views have much in common
Mappings provide clarification of the views relationships
We choose the ones that provide most insight
Generally: parts of view elements can map to other view
elements
Exp: class maps to its object instances
Complications: runtime elements of system do not exist as code
elements at all
Imported at runtime, incorporated at build/load time

79

10.2.2010

What the architecture is, 3

Element list
Index of all the elements that appear in all the views
A pointer to where each element is defined

Project glossary
Lists and defines terms unique to the system that have special

meaning
List of acronyms, their meaning
Reference to an already existing glossary

80

10.2.2010

Why the architecture is the way it is

Cross view rationale
Explains how the overall architecture is a solution to the
requirements
It may explain
Implications of system-wide design choices on meeting the

requirements/satisfying constraints
Effect on architecture when adding foreseen new requirement, or
changing existing one
Constraints on developer in implementing a solution
Rejected design alternatives: why?

why a decision was made

what are the implications in changing a decision

81

10.2.2010

UML notation
Interfaces

82

10.2.2010

UML notation
Modules

83

10.2.2010

UML notation
Relations

84

10.2.2010

UML notation
Decomposition

85

10.2.2010

UML notation
Generalization

86

10.2.2010

UML notation
Layers

87

10.2.2010

UML notation
Instantiation

88

10.2.2010

UML notation
Ports

89

10.2.2010

UML notation
Deployment

90

10.2.2010