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
