Software Architectures 456502.0

Software Architectures
456502.0
Lecture 1
This course at:

http://www.users.abo.fi/lpetre/SA11/
Has 5 sp
Weeks 44-51:
Tuesdays and Thursdays, during 10:15-12,
@ Cobol (B3040)
Components
Lectures: 9-12 (18-24h)
Exercises: 3 individually returned studies
Tests: 16.12.2011, 20.1.2012, 17.2.2012, 4.5.2012
@ Alpha Auditorium, during 12-16

Register 7 days in advance to any test
Software Architectures, Lecture 1
1-Nov-11
Materials
1-Nov-11
Materials
C. Hofmeister, R. Nord, D. Soni: Applied Software
Architecture, Addison-Wesley, 2000.

M. Shaw and D. Garlan: Software Architecture Perspectives on an Emerging Discipline,
Prentice-Hall, 1996.
L. Bass, P. Clements, and R. Kazman: Software
Architecture in Practice, Addison-Wesley, 2003.
P. Clements, R. Kazman, M. Klein: Evaluating
Software Architectures, Addison-Wesley, 2002.
1-Nov-11
Software Architecture
Architecture
Old art and ancient engineering discipline
Software
The industry begun in late 40s
Software architecture
Much less mature than computer hardware
architecture
Common excuses
Software industry is young and unique
Yet: our economy relies on software
products
5
1-Nov-11
Our society runs on Software

Software today allows a brother in San Jose to call a sister in St.
Petersburg.
Software today speeds the process of drug discovery, potentially
curing Alzheimer's.
Software today drives the imaging systems that allow the early
detection of breast cancer and other maladies.
Software controls the passive restraint systems and antilock
breaking systems that save children's lives in automobiles every
day.
Software powers our communication and transportation
technologies.
Software allows us to peer deep within ourselves and study the
human genome.
Software allows us to explore and understand our universe.
And, make no mistake about it, we are just getting started
Paul Levy
6
1-Nov-11
What does SA address?

Complexity of software systems increased
Developing software: hundreds/ thousands person-years
Many software systems: complex as skyscrapers
Designing software
Beyond algorithms/ data structures of the computation
New kind of problem: overall system structure
1-Nov-11
Producing software systems

Criteria have changed
Computer hardware improved, affordable
Need for software applications exploded
How to specify requirements for new products and
implement the software quickly, cheaply

Earliest software product on market
Quality?
New criterion: does it have a good SA, understood
by stakeholders and developers?
1-Nov-11
1.
Provides a design plan of a system

Blueprint
Implies purpose
2.
Is an abstraction that helps in managing the

complexity of a system
Software architects limited by

Lack of standardized ways to represent architecture
Lack of analysis methods to predict whether an
architecture will result in an implementation that

meets the requirements
9
1-Nov-11
SA as a design plan
Structural plan that describes
The elements of a system
How they fit together
How they work together to fulfill requirements
Used as blueprint during development
process
Used to negotiate system requirements
Used to set expectations with
Customers
Marketing/management personnel
10
1-Nov-11
SA as design plan
Project manager uses the design plan as input to
the project plan
Domain analysis,
Requirements analysis,
Risk analysis
SA design
Hardware
Architecture
design
Detailed design,
Coding,
Integration, Testing
11
1-Nov-11
SA as an abstraction
SA not a comprehensive decomposition of a
system
Implementation details abstracted away,
encapsulated into elements of the SA

SA should describe elements at a coarse level of
granularity
How elements fulfill the requirements
Element interactions
Element dependencies on execution platform
12
1-Nov-11
Design tradeoffs
Resolving tradeoffs may lead to
Sacrificing some desired qualities
E.g., simplicity
Compromising some requirements
Renegotiating
Reducing portability, modifiability, etc
13
1-Nov-11
SA goal
One should strive for a good architecture
When system is implemented according to the
architecture, it meets its requirements and resource

budget
It is possible to implement system according to
architecture
Not good enough when
Not explicit or not comprehensive or not consistent
or not understandable
14
1-Nov-11
SA terminology
Architectural style/pattern
1.
Reference/domain specific architecture
2.
15
Defines element types and how they interact

Sometimes defines a mapping of functionality to
architectural elements
Defines element types and how they interact
They apply to a particular domain
They define how the domain functionality is
mapped to architectural elements
1-Nov-11
SA terminology, 2
Product-line architecture
3.
Applies to a set of products within a company

Defines element types, how they interact, how
the product functionality is mapped to them
May also define some of the instances of the
architectural elements
16
E.g., error-reporting components would be common to

many products of the product line
1-Nov-11
SA terminology,3
4.
17
Applies to one system

Describes element types, how they interact, how
Describes the instances that exist in the system
Level of specificity needed to design a system
1-Nov-11
SA terminology, 4
Defines element
types and how
they interact
Defines the
mapping of
functionality to
architecture
elements
Defines instances
of architecture
elements
yes
sometimes
no
yes
yes
no
yes
yes
sometimes
yes
yes
yes
Term
An architectural
style
A reference
architecture
A product-line
architecture
A software
architecture
SA terminology, final
ADL (architectural description language)
5.
Gives notation for architectural elements
19
As types and instances, also interconnecting instances

to form configurations
Mostly in research communities

In theory: architects can use an ADL to describe
any of the 1-4 terms
In practice: not all ADLs support all the 1-4 terms
Some ADLs have accompanying tools
1-Nov-11
HENCE:
We need to study software architecture
Our society is software-reliant
Software systems are complex
Addresses the complexity of the systems to build
Course goal
Understand what SA is
SA very much an emerging discipline
The philosophy
One should not focus on designing the ideal architecture
Instead: focus on carefully examining tradeoffs
We will learn to recognize and evaluate
architectures, as well as design them
20
1-Nov-11
Contents of this course

L1: What is SA? Quality Attributes (today)
L2: Architectural tactics and styles
L3: Case studies
Design,
Recognize
L4: Creating an architecture

L5+6: Architectural views
Documenting
L7: Analysing and evaluating an architecture

L8: Architectural Description Languages Generalization,
Research
L9: Product lines, COTS, Software architects

Automating the architecting,
The job
21
1-Nov-11
The ABC cycle

SA result of technical, business, and social
influences
A SA also influences technical, business, and
social influences
That, subsequently, influence future SAs
This is the ABC cycle of influences: Architecture
Business Cycle
Organizational goals requirements SA
systems future new organizational goals
22
1-Nov-11
Stakeholders
Architectures influenced by stakeholders
Management: low cost, keep people employed
Marketing: short time to market, low cost
Customer: timely delivery, not changed often
End user: behavior, performance, security
Maintenance: modifiability
23
1-Nov-11
The business considerations

Determine qualities to be part of the systems architecture
Quality attributes
Such qualities are non-functional

Functionality
Basic statement of the systems capabilities, services,
behavior
Sometimes the only development concern
Systems often need to be redesigned for
Maintainability
Portability
Scalability
Speed
Security etc
Compromise
24
1-Nov-11
More on functionality
Functionality and quality attributes: orthogonal
We therefore need to separate concerns
Functionality: the ability of the system to do the
work for which it was intended

Functionality can be achieved by using various
possible structures
System can exist also as a monolithic module with
no structure
25
1-Nov-11
Architecture and quality attributes

Quality attributes considered during
Design, implementation, deployment
No attribute is dependent only on one phase
Architecture critical for realizing many quality
attributes
These qualities designed and evaluated at
architectural level
Architecture does not achieve these qualities
They are achieved via details (implementation)
26
1-Nov-11
Quality attributes
System qualities
Availability, modifiability, performance, security,
testability, usability
Business qualities
Time-to-market, etc
Architecture qualities
Conceptual integrity, etc
27
1-Nov-11
System qualities
Of interest to software people since 70s
Many definitions, own communities
Problems
Non-operational definitions
Aspects belong to which quality
Distinct vocabularies
28
1-Nov-11
Quality attribute scenarios

Quality-attribute-specific requirement, containing
Source of stimulus
Stimulus
Environment
Artifact
Response
Response measure
29
1-Nov-11
QA scenario parts
Source of stimulus
Human/computer system/other actuator generating
the stimulus
Stimulus
Condition that needs to be evaluated when arrives
at the system
Environment
The conditions the system is in
(overload/running/failed etc)
30
1-Nov-11
QA scenario parts,2
Artifact
Something that is stimulated (whole system/ certain
system part)
Response
Activity undertaken upon stimulus arrival
Response measure
Response should be measurable in some manner
so that the requirement can be tested
31
1-Nov-11
QA scenarios
General QA scenarios
System independent
Can potentially pertain to any system
Concrete QA scenarios
Specific to the particular system under
consideration
Same role as use cases for specifying functional
requirements
32
1-Nov-11
QA Scenario Generation
We need to generate meaningful QA
requirements for a system

Requirements gathering phase
Starting point, but not disciplined enough recording
We generate concrete QA scenarios

First create general scenarios from tables
From them derive system-specific scenarios
33
1-Nov-11
Availability
Readiness of usage
Concerned with system failures and
consequences
Failure
Deviation from intended functional behavior
Observable by system users
Failure vs fault
Fault: event which may cause an error
Error: incorrect internal system state
34
1-Nov-11
Availability concerns
How system failure is detected
How frequently system failure may occur
What happens when a failure occurs
How long is a system allowed to be
unoperable
When can failures occur safely
How to prevent failures
What kind of notifications are required when a
failure occurs
35
1-Nov-11
Repairments and maintenance

Time to repair:
time until failure is no longer observable
Automatic repair
Maintenance: scheduled downtimes
Probability
Mean time to fail/(mean time to fail+mean time to
repair)
36
1-Nov-11
Availability general scenarios

Source
Internal/external to system
Stimulus
Fault: omission, crash, timing, response
Artifact
Systems processors, communication channels,

persistent storage, processes
Environment
Normal operation or degraded mode
Response
Response
measure
Detect event and record it/notify appropriate

parties/disable event sources causing
faults/failures/ be unavailable for an interval/
continue
Time interval of available system, availability time,
time interval of degraded mode, repair time
Modifiability
Concerns cost of change
1.
2.
Upon specifying a change
38
What can change the artifact?

When and by whom is the change made?
New implementation must be designed,
implemented, tested, deployed
All these cost time and money
Time and money can be measured
1-Nov-11
What can change (the artifact)?

Any aspect of a system: add/ delete/ modify
The functions the system computes
The platform the system exists on (=> portability)
HW, OS, MW
System environment
Systems to interoperate with, communication protocols
System qualities
Reliability, performance, modifiability
Capacity
Number of users supported, of supported operations
39
1-Nov-11
When and by whom is the change

made?
Implementation
Modifying source code
Compile-time
Build
Configuration setup
Execution
By
developers, end users, system administrator
40
1-Nov-11
Modifiability general scenarios

Source
End user, developer, system administrator
Stimulus
Wishes to add/delete/modify/vary functionality, QA,

capacity, etc
Artifact
System UI, platform, environment, system that

interoperates with target system
Environment
Runtime, compile time, build time, design time
Response
Locates place in architecture to modify, makes

modification w/o affecting other func., tests modif.,
deploys modif.
Response
measure
Costs in terms of number of elements affected,

effort, money; extent to which this affects other
QAs, functions
Performance
Concerned with timing
how long it takes a system to respond when an
event occurs
Events
Interrupts, messages, requests from users, passage
of time
Complication
Number of event sources and arrival patterns
42
1-Nov-11
Arrival pattern for events

Periodic
E.g., every 10 ms
Most often seen in real-time systems
Stochastic
Events arrive according to some probabilistic
distribution
Sporadical
43
1-Nov-11
System responses
Latency
Time between stimulus arrivaland systems response to it
Deadlines in processing
Throughput in the system
Number of transactions system can process in a second
Jitter of the response
Variation in latency
Number of events not processed
Because system too busy to respond
Lost data
Because system too busy
44
1-Nov-11
Performance general scenarios

Source
Independent sources (possibly from within system)
Stimulus
Periodic or stochastic or sporadic events occur
Artifact
System
Environment
Normal mode, overload mode
Response
Response
measure
Processes stimuli; changes level of service
1-Nov-11
Latency, deadline, throughput, jitter, miss rate, data

loss
45
Security
Measure of systems ability
to resist unauthorized usage
to provide services to legitimate users
Attack: attempt to breach security

Unauthorized attempt to access data/services
Unauthorized attempt to modify data
Attempt to deny services to legitimate users
46
1-Nov-11
Example attacks
Theft of money by electronic means
Theft of credit card numbers
Destruction of files on computer systems
Denial-of-service attacks by worms, viruses
47
1-Nov-11
Security components
Nonrepudiation
Transaction cannot be denied by any of its parties
Confidentiality
Data/service protected from unauthorized access
Integrity
Data/services delivered as intended
Assurance
Parties in a transactions are who they say they are
Availability
System ready for legitimate use
Auditing
System tracks activities within it to be able to reconstruct them
48
1-Nov-11
Security general scenarios

Source
Individual/system: identity, internal/external,

authorization, access
Stimulus
Try to: display data, change/delete data, access

system services, reduce availability
Artifact
System services, data within system
Environment
On/offline, (dis)connected, firewalled or open
Response
Response
measure
various
1-Nov-11
various
49
Security scenario response
50
Authenticates user
Hides identity of user
Blocks/allows acces to data/services
Grants/withdraws permission to access
data/services
Records access/modification or attempts
Stores data in certain formats
Recognizes access/usage roles
Informs users on other systems
Restricts availability of services
1-Nov-11
Security scenario response measure

Time/effort/resources for circumventing security
51
measures successfully
Probability of detecting attack, identifying attacker
Percentage of services still available under DoS
attack
Restore data/services
Extent to which data/services damaged or
legitimate access denied
1-Nov-11
Testability
Easiness with which SW can demonstrate its
faults through testing

Testing: 40% costs of developing good systems
Probability that SW will fail on its next test
execution
Assuming the software has at least one fault
Response measures
Effectivness of tests (in finding faults)
How long do satisfiable tests last
52
1-Nov-11
Testable system
It must be possible
to control each components internal state and
inputs
To observe the outputs
Test harness
Specialized software designed for exercizing the
SW under test
53
1-Nov-11
Who and what

Who does it
Various developers, testers, verifiers, users
Last step of SW development cycle

What to test
Portions of code
Design
Complete system
54
1-Nov-11
Testability general scenarios

Source
Unit developer, increment integrator, system

verifier, client acceptance tester, system user
Stimulus
Analysis, architecture, design, class, subsystem

integration completed, system delivered
Artifact
Design part, code part, complete application
Environment
At design time, at development time, at compile

time, at deployment time
Response
Provides access to state values; provides

computed values; prepares test environment
Response
measure
Percent executable statements executed,

probability of failure if fault exists, time to perform
tests, length of longest dependency chain in a test,
length of time to prepare test environment
Usability
Concerned with
How easy it is for the user to accomplish a desired
task
User support type the system provides
Usability problems are usually discovered during
prototype building and user testing

Later in process and deeper in architecture the
repair needs to go: the more expensive
56
1-Nov-11
Usability areas
Learning system features
Using a system efficiently
Minimizing the impact of errors
Adapting system to user needs
Increasing confidence and satisfaction
57
1-Nov-11
Usability general scenarios

Source
End user
Stimulus
Wants to learn system features, use system

efficiently, minimize impact of errors, adapt system,
feel comfortable
Artifact
System
Environment
At runtime and configure time
Response
Various
Response
measure
Task time, number of errors, number of problems

solved, user satisfaction, user knowledge gain,
ratio of successful operations to total operations,
amaount of time/data lost
Usability scenario response

System provides responses to support
learn system features
use system efficiently
minimize impact of errors
adapt system
feel comfortable
59
1-Nov-11
Communicating concepts
General scenarios
Need to make stakeholders communicate
Each attribute community has own vocabulary
Different terms can mean the same thing
Stimuli can occur during runtime or before
Architects job: understand which stimuli
Represent the same ocurence
Are aggregates of other stimuli
Are independent
When stimuli relations are clear
Communicate them to stakeholders
Use appropriate language for each stakeholder category
60
1-Nov-11
Stimuli
Availabiliy
Unexpected event, nonoccurence of expected

event
Modifiability
Request to add/delete/modify/vary functionality,

QA, capacity, platform, etc
Performance
Periodic or stochastic or sporadic events occur
Security
Tries to: display data, change/delete data, access

system services, reduce availability
Testability
Analysis, architecture, design, class, subsystem

integration completed, system delivered
Usability
Wants to learn system features, use system

efficiently, minimize impact of errors, adapt system,
feel comfortable
1-Nov-11
61
Todays take away

Software architecture is about
Balance
Abstraction
Structure(s)
Quality attributes
Are the requirements for SA
Have to be captured
Scenarios
62
1-Nov-11
To read
http://www.computer.org/portal/web/computingno
w/onarchitecture Grady Boochs podcast On

Architecture
http://www.computer.org/portal/web/software/hom
e Search Grady Booch on Architecture
http://softwarearchitecturezen.blogspot.com/
Peter Cripps, IBM, UK
http://www.bredemeyer.com/papers.htm Papers
and other downloads on SA
63
1-Nov-11
Lecture 2
Roadmap of the course

What is software architecture?
Designing Software Architecture
Requirements: quality attributes or qualities
Today
How to achieve requirements : tactics
Next time:
How do tactics lead to architectural styles
Case studies on architectural styles
8.11.2011
Tactics
Qualities achieved via design decisions
What design decisions needed for achieving a
specific quality?
Tactic
Design decision that influences the control of a
quality attribute response

Architectural strategy
Collection of tactics
8.11.2011
Architectural style
A package of tactics
Tactics can refine other tactics
Redundancy is refined by data redundancy, code redundancy
Example
One availability tactic: introduce redundancy
Implication: we also need synchronization of replicas
To ensure the redundant copy can be used if the original fails
8.11.2011
Availability tactics
Failure
Deviation from intended functional behavior
Observable by system users
Failure vs fault
Fault: event which may cause a failure
Availability tactics
Keep faults from becoming failures
Make possible repairments
8.11.2011
Availability tactics (2)

Availability
Detection
Fault
Recoverypreparation
and repair
Voting
Ping/Echo
Active
Heartbeat
redundancy
Exception
Passive
redundancy
Spare
Recoveryreintroduction
Prevention
Fault masked
Removal
Repair made
Shadow
from service
State
Transactions
resynchronization
Process
Rollback
monitor
8.11.2011
Fault detection: Ping/Echo

Comp. 1 issues a ping to comp. 2
Comp. 1 expects an echo from comp. 2
Answer within predefined time period
Usable for a group of components
Mutually responsible for one task
Usable for client/server
Tests the server and the communication path
Hierarchy of fault detectors improves
bandwidth usage
7
8.11.2011
Fault detection: Heartbeat

Comp. 1 emits a heartbeat message periodically
Comp. 2 listens for it
If heartbeat fails
Comp. 1 assumed failed
Fault correcting comp. 3 is notified
Heartbeat can also carry data
8.11.2011
Fault detection: Exceptions

Fault classes: omission, crash, timing, response
When a fault class recognized, exception is
raised
A fault consequently is recognized
Exception handler
Executes in same process that introduced the
exception
Typically does a semantic transformation of fault
into a processable form
8.11.2011
Component recovery: Voting

Processes running on redundant processors take
equivalent input and compute output

Output sent to voter
Voter detects deviant behavior from a single processor
=> it fails it
Method used to correct
Faulty operation of algorithm
Failure of a processor
10
8.11.2011
Component recovery: active

redundancy
All redundant components respond to events in
parallel => all in same state

Response from only one comp used
Downtime: switching time to another up-to-date
component (ms)
Used in client-server config (database syst)
Quick responses are important
Synchronization
All messages to any redundant component sent to all
redundant components
11
8.11.2011
Component recovery: passive

redundancy
Primary component
responds to events
informs standby components of state updates they
must make
Fault occurs:
System checks if backup sufficiently fresh before
resuming services
Often used in control systems
Periodical switchovers increase availability
12
8.11.2011
Component recovery: spare

Standby spare computing platform configured to
replace many different failed components

Must be rebooted to appropriate SW config
Have its state initialized when failure occurs
Checkpoint of system state and state changes to
persistent device periodically

Downtime: minutes
13
8.11.2011
Component reintroduction: shadow

operation
Previously failed component may be run in
shadow mode
For a while
To make sure it mimics the behavior of the working
components
Before restoring it to service
14
8.11.2011
Component reintroduction: state resynchronization

Passive and active redundancy
Restored component upgrades its state before
return to service
Update depends on
Downtime
Size of update
Number of messages required for the update
One preferable; more lead to complicated SW
15
8.11.2011
Component reintroduction:
checkpoint/ rollback
Checkpoint
Record of a consistent state
Created periodically or in response to specific
events
Useful when a system fails unusually, with
detectably inconsistent state: system restored

using
A previous checkpoint of a consistent state
Log of transactions occurred since
16
8.11.2011
Component prevention
Removal from service
Comp removed from operation to undergo some
activities to prevent anticipated failures

Exp: rebooting comp to prevent memory leaks
Automatic (design architecture) or manual (design
system)
Transactions
sequential steps bundled together, s.t. the whole bundle
can be undone at once

Process monitor
If process fault detected, then monitoring process
deletes non-performing process and creates new

instance of it
initialized to some appropriate state as in the spare tactic
Modifiability tactics
Goal: controlling time and cost to implement, test,
modify and deploy changes

Sets of tactics
Localize modifications
Reduce nr of modules affected by a change
Prevent ripple effects
Limiting modifications to localized modules
Defer binding time
Controlling deployment time and cost
18
8.11.2011
Modifiability tactics (2)

Modifiability
Localize
changes
Changes
arrive
19
Semantic
coherence
Anticipate
expected
changes
Generalize
module
Abstract
common
services
Prevention of
ripple effects
Hide information
Maintain
existing interface
Restrict comm
paths
Use an Intermediary
Defer binding
time
Runtime
registration
Configuration
files
Polymorphism
Component
replacement
Adherence to
defined
protocols
Changes
Made,
Tested,
Deployed
Within
Time and
Budget
8.11.2011
Localize modifications: maintain

semantic coherence
Semantic coherence: relationships among
responsibilities in a module
Goal: ensure all these responsibilities work
together w/o excessive reliance on other modules
Goal achievement: design modules with
responsibilities in semantic coherence
20
8.11.2011
Localize modifications: abstract common

services
Subtactic of semantic coherence
Provides common services through specialized
modules
Reuse and modifiability
Modifications to common services done only once
rather than in every module using them

Modifications to modules using common services
do not impact other users
21
8.11.2011
Localize modifications: anticipate

expected changes
Considering the set of envisioned changes
provides way to evaluate particular assignment of

responsibilities
Questions
For a change: does proposed decomp. limit the set
of modules needing modif?

Fundamentally diff. changes: do they affect the
same modules?
Goal: minimizing effects of changes
22
8.11.2011
Localize modifications: generalize the

module
Generalize a module by making it compute a
broader range of functions due to its input

type
Input defining language for the module
Making constants input paramaters
Implementing the module as an interpreter and
making the input parameters be programs in that

interpreters language
The more general the module
The most likely is that requested changes can be
made by adjusting input language
23
8.11.2011
Prevent ripple effects

Localize modifications vs limit modifications to
localized modules
There are modules directly affected
Whose responsibilities are adjusted to accomplish change
There are modules indirectly affected by a change
Whose responsibilities remain unchanged BUT
implementation needs to be changed to accommodate the
directly affected modules
24
8.11.2011
Ripple effects
Ripple effect from a modification
The necessity of making changes to modules not
directly affected by it
This happens because said modules are
SOMEHOW dependent on the modules directly
dealing with the modification
25
8.11.2011
Dependency types
We assume
Module A changed to accomplish particular
modification
Module B changed only because A changed
There are several dependency types
Syntax, semantics, sequence, identity of interface,
location of A, quality of service, existence of A,

resource behavior of A
26
8.11.2011
Syntax dependency
Of data
B consumes data produced by A
Type and format of data in both A and B need to be
consistent
Of service
B invokes services of A
Signature of services produced by A need to be
consistent with Bs asumptions
27
8.11.2011
Semantics dependency
Of data
Semantics of data produced by A and consumed by
B need to be consistent with Bs asumptions

Of service
B invokes services of A
Semantics of services produced by A need to be
consistent with Bs asumptions
28
8.11.2011
Sequence dependency
Of data
B must receive the data produced by A in a fixed
sequence
Of control
A must have executed previously within certain time
constraints
29
8.11.2011
Identity of interface of A
A may have multiple interfaces
B uses one of them
For B to compile and execute correctly, the
identity (name or handle) of the interface must be

consistent with Bs assumptions
30
8.11.2011
Other dependencies
Runtime location of A
Must be consistent with Bs assumptions
Quality of service/data provided by A

Properties involving the above quality must be
consistent with Bs assumptions

Existence of A
For B to execute, A must exist
Resource behavior of A
Must be consistent with Bs assumptions
31
8.11.2011
Tactics for ripple effect prevention

Information hiding
Maintain existing interfaces
Restrict communication paths
Use intermediary
32
8.11.2011
Information hiding
Decomposition of responsibilities into smaller
pieces and choosing which information to

make private and which public
Public information available through specified
interfaces
Goal: isolate changes within one module and
prevent changes from propagating to others
Oldest technique from preventing changes from
propagating
Strongly related to anticipate expected changes (it
uses those changes as basis for decomposition)
33
8.11.2011
Maintain existing interfaces

B syntax-depends on As interface
Maintaining the interface lets B stay unchanged
Interface stability
Separating interface from implementation
How to implement the tactic

Adding interfaces
Adding adapter
Providing a stub for A
34
8.11.2011
Restrict communication paths

Restrict number of modules with which the given
module shares data

Reduce nr of modules that consume data produced
by given module
Reduce nr of modules that produce data consumed
by given module
Reduced ripple effect
Data production/consumption introduces
dependencies
35
8.11.2011
Use an intermediary
B dependent on A in other ways than semantically
Possible to introduce an intermediary to manage
the dependency
Data (syntax)
Service (syntax)
Location of A
Existence of A
36
8.11.2011
Defer binding time

Decision can be bound into executing system at
various times
Binding at runtime
System has been prepared for that binding
All testing and distribution steps already completed
Supports end user/administrator making settings or
providing input that affects behavior
37
8.11.2011
Tactics with impact at

load/runtime
Runtime registration
Plug-and-play operation, extra overhead to manage
registration
set parameters at start-up

Polymorphism - late binding of method calls
Component replacement loadtime binding
Configuration files
Adherence to defined protocols

Runtime binding of independent processes
38
8.11.2011
Performance tactics
Goal: generate response to an event arriving at
system within time constraint

Event: single or stream
Message arrival, time expiration, significant state
change, etc
Latency: time between the arrival of an event and the
generation of a response to it
Event arrives
System processes it or processing is blocked
39
8.11.2011
Performance tactics (2)

Performance
Resource
demand
Increase
computation
Events efficiency
Reduce
arrive
computational
overhead
Manage event
rate
Control
frequency of
sampling
40
Resource
management
Introduce
concurrency
Maintain
multiple
copies
Increase
available
resources
Resource
arbitration
Scheduling
policy
Response
generated
within
time limit
8.11.2011
Resource demand tactic

Source of resource demand: event stream
Demand characteristics
Time between events in resource stream (how

often a request is made in a stream)
How much of a resource is consumed by each
request
Reducing latency tactic

1.
2.
41
Reduce required resources

Reduce nr of processed events
8.11.2011
Reduce required resources

Increase computational efficiency
Processing involves algorithms => improve
algorithms
Resources may be traded for one another
Reduce computational overhead
If no request for a resource => its processing needs
are reduced
Intermediaries removed
42
8.11.2011
Reduce nr of processed events

Manage event rate
Reduce sampling frequency at which environmental
variables are monitored
Control frequency of samplings
If no control over arrival of externally generated
events => queued requests can be sampled at a
lower frequency (request loss)
Bound execution times
Limit over how much execution time used for an
event
Bound queue sizes
Controls max nr of queued arrivals
43
8.11.2011
Resource management
Introduce concurrency
Process requests in parallel
Different event streams processed on different threads
(create additional threads)

Load balancing
Maintain multiple copies of data and
computations
Caching and synchronization
Increase available resources

Faster processors and networks, additional
processors and memory
44
8.11.2011
Resource arbitration
Resource contention => resource must be
scheduled
Architects goal
Understand characteristics of each resources use
and choose compatible scheduling

Understand possibly conflicting criteria for
scheduling
And effect of chosen tactic
Scheduling policy
Priority assignment
Dispatching
45
8.11.2011
Scheduling
What: network, buffers, processors
Competing criteria for scheduling
Optimal resource usage
Request importance
Minimizing nr of used resources
Minimizing latency
Maximizing throughput
Preventing starvation to ensure fairness
Dispatching can happen only when assigned
resource available
Pre-emptying might occur
46
8.11.2011
Scheduling policies
First in/first out (FIFO)
OK if all requests are of equal importance and take same
time
Fixed priority scheduling, priorities based on
Semantic importance (domain specific)
Deadline monotonic (real-time deadlines; shortest
deadline 1st)
Rate monotonic (periodic streams, shorter period 1st)
Dynamic priority scheduling
Round robin
Earliest deadline first
Static scheduling
Security tactics
Goal: resisting attacks, detecting attacks, recovering
from attacks
House defense analogy
Door lock
Motion sensor
Insurance
48
8.11.2011
Security tactics (2)

Security
Resisting
attacks
Attack
Authenticate
users
Authorize users
Maintain data
confidentiality
Maintain integrity
Limit exposure
Limit access
Detecting
attacks
Recovering
from attacks
Restoration
Intrusion
detection
Identification
See availability
System
Detects,
Resists, or
Recovers
from
attacks
Audit trail
49
8.11.2011
Resisting attacks
Authenticate users
Passwords, one-time passwords, digital certificates,
biometric id
Authorize users
Access control patterns
Maintain data confidentiality

Encryption to data and communication links
Maintain integrity
Checksums, hash results help
Limit exposure: limited services on each host

Limit access: firewalls, DMZ
50
8.11.2011
Detecting attacks
Intrusion detection system
Compares network traffic patterns to database
Misuse => pattern compared to historical patterns of
known attacks
Anomaly => pattern compared to historical baseline
of itself
Filtering
Protocol, TCP flags, payload size, addresses, port numbers
51
Must have
Sensor to detect attacks
Manager for sensor fusion
Databases for storing events for analysis
Tools for offline reporting and analysis
Control console to modify intrusion detection actions
8.11.2011
Intrusion detectors
Sensor to detect attacks
Managers for sensor fusion
Databases for storing events for later analysis
Tools for offline reporting and analysis
Control console
Analyst can modify intrusion detection actions
52
8.11.2011
Recovering from attacks

Tactics for restoring state
Recovering a consistent state from an inconsistent
one: availability tactics

Redundant copies of system adm data
Passwords, access control lists, domain name services,
user profile data: special attention
Tactics for attacker identification

For preventive or punitive purposes
Maintain audit trail
53
8.11.2011
Audit trail
Copy of each transaction applied to data in
the system + identifying information

Can be used to
Trace the actions of an attacker
Support non-repudiation
Provides evidence that a particular request was made
Support system recovery
Often attack targets

Should be maintained in trusted fashion
54
8.11.2011
Testability tactics
Goal: allow for easier testing when some increment of
software development is completed

Enhancing testability not so mature but very valuable
40% of system development
Testing a running system (not designs)

Test harness
SW that provides input to the SW being tested and
captures the output

Goal: find faults
55
8.11.2011
Testability tactics (2)

Testability
Manage
Input/Output
Completion
of an Increment
56
Record/Playback
Separate Interface
from Implementation
Specialized
Access Routines/
Interfaces
Internal
Monitoring
Built-In
Monitors
Faults
detected
8.11.2011
I/O Tactics: record/playback

Refers to
Capturing info crossing an interface
Using it as input to the test harness
Info crossing an interface at normal operation

Output from one component, input to another
Saved in repository
Allows test input for one component
Gives test output for later comparisons
57
8.11.2011
I/O Tactics: interface vs

implementation
Separating interface from implementation
Allows substitution of implementations for various
testing purposes
Stubbing implementations let system be tested without the
component being stubbed

Substituting a specialized component lets the component
being replaced to act as test harness for the remainder of
the system
Tactic also achieves modifiability
58
8.11.2011
I/O Tactics: specialize access

routes/interfaces
Having specialized testing interfaces
Captures/specifies variable values for components
Via test harness
Independently from normal execution
Specialized access routes/interfaces

Should be kept separate from required functionality
Hierarchy of test interfaces

Test cases can be applied at any architectural level
Testing functionality in place to observe responses
59
8.11.2011
Internal monitoring tactic

Built-in monitors
Component can maintain state, performance load,
capacity, security, etc accessible through interfaces

Permanent interface or temporarily introduced for testing
Record events when monitoring states activated

Additional testing cost/effort
Increased visibility
60
8.11.2011
Usability tactics
Usability concerns
How easy can a user accomplish desired task
What is the system support for the user
Tactics
Runtime: support user during system execution
Design time: support interface developer
Iterative nature of interface design
Related to modifiability tactics
Refinement of semantic coherence tactic to localize expected
changes
61
8.11.2011
Runtime tactics
User feedback as to what is the system doing
Providing user with ability to issue usability
commands
Cancel
Undo
Aggregate
Show multiple views
62
8.11.2011
Initiatives
HCI terminology
User initiative
System initiative
Mixed initiative
User initiative
Architect designs response as for any other
functionality
System initiative
System needs models: user, task, system state
63
8.11.2011
Usability tactics
Usability
Runtime tactics
user
System
initiative
request
User
initiative
64
Design time tactics
Separate
user
interface
User given
appropriate
feedback and
assistance
8.11.2011
Todays take away

There are many ways to achieve a QA tactics
Can work well or less well
Can interact with other tactics for achieving other
QAs
A Software Architecture determined by the
collection of tactics
65
8.11.2011
Lecture 3

Today:
Case studies on architectural styles
to also observe the achieved qualities
10-Nov-11
Elements of Architectural Descriptions

The architectural definition of a system selects
Components: define the locus of computation
Examples: filters, databases, objects, ADTs
Connectors: mediate interactions of components

Examples: procedure calls, pipes, event broadcast
Properties: specify info for construction & analysis
Examples: signatures, pre/post conditions, RT specifications
An architectural style defines a family of
architectures constrained by
Component/connector vocabulary
Topology rules
Semantic constraints
3
10-Nov-11
Some Architectural Styles

Data flow systems
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
10-Nov-11
Questions we ask of each style

What is the design vocabulary?
What are the allowable structural patterns?
What is the underlying computational model?
What are the essential invariants of the style?
What are some common examples of its use?
Advantages and disadvantages of using the style
Common specializations of the style
10-Nov-11
Data Flow Systems

The availability of data controls the computation
The structure of the design is dominated by the
orderly motion of data from process to process

The pattern of data flow is explicit
No other interaction between processes
Types
Batch sequential
Pipes and filters
Feedback loop
10-Nov-11
Control flow vs Data flow

Control flow
Dominant question: how the locus of control moves
throughout the execution

Data may accompany control but is not dominant
Reasoning is on the computation order
Data flow
Dominant question: how data moves through a
collection of (atomic) computations

As data moves, control is activated
Reasoning is on data availability, transformation,
latency
7
10-Nov-11
Batch Sequential Systems

Processing steps are independent programs
Each step runs to completion before next step
starts
Atomic computations
Data transmitted as a whole between steps

Typical applications
Classical data processing
Program developments
validate
sort
update
report
10-Nov-11
Pipes and Filters

Each component has
Set of inputs (read)
Set of outputs (produced)
Filter
Incrementally transforms some amount of the data at
inputs to data at outputs

Stream-to-stream transformations
Local transformation
Uses little local context in processing stream

Independent, shares no state with other filters
Does not know identity of incoming and outgoing streams
9
10-Nov-11
Pipes and Filters contd

Pipe
Move data from a filter output to a filter input
Pipes form data transmission graphs
Overall computation
Run pipes and filters (non-deterministically) until no more
computations are possible

Correctness of p&f networks output should not depend on
ordering
Specializations
Pipelines, bounded pipes, typed pipes
Batch sequential systems: degenerated pipeline
10
10-Nov-11
Pipe and filter examples

Programs written in Unix shells
Filters: Unix processes
Pipes: runtime mechanisms for implementing them
Compilers (exp of pipeline)

(phases often not incremental)
Lexical analysis, parsing, semantic analysis, code
generation
Signal processing domains
Parallel programming
Distributed programming
11
10-Nov-11
Advantages and disadvantages

Adv
Overal I/O is a composition of the behavior of independent
filters
Support reuse
Maintainability, improvement
Allow analysis (throughouput, deadlock analysis)
Support concurrency
Disadv
Often lead to a batch organization of processing
Not good at handling interactive applications
Quite complex
Not so performant
12
10-Nov-11
Call-and-Return systems
The control moves from a module to another and
back
Different from monolithic systems or pipe and
filter systems
Abstraction made possible
Types
Main program and subroutine
OO, ADT
(Hierarchical) layers
13
10-Nov-11
Main Program and Subroutines
Hierarchical decomposition
Based on definition-use relationship
Single thread of control

Supported directly by programming languages
Subsystem structure implicit

Subroutines typically aggregated to modules
Hierarchical reasoning
Correctness of a subroutine depends on the correctness of the subroutines it calls
14
10-Nov-11
15
10-Nov-11
Abstract data types and OO

If you get the data structures right, the rest of the
program much simpler
16
Object-orientation
Object: collection of data and operations
Class: description of set of objects
Subclass: class with additional properties
More restrictive than class => fewer members
Instance: object of a class

Method: procedure body implementing operation
Dynamically bound
Message: procedure call; request to execute
method
Properties: intuitive, support REUSE
17
10-Nov-11
Object architectures
Encapsulation
Restrict access to certain information
Object responsible for preserving integrity of its
representation (invariant)
Inheritance
Share one definition of shared functionality
Dynamic binding
Determine actual operation to call at runtime
Management of many objects
Provide structure on large set of definitions
Reuse and maintenance
Exploit encapsulation and locality
18
10-Nov-11
19
10-Nov-11

Advantages
Maintainability: modifiability of method bodies
Architecture anticipates (some) changes
Reuse
Disadvantages
Identity of interacting objects need to be known ->
and needs to be changed in all objects interacting

with an object whose identity was modified
Side effect problems
Managing many objects (additional structuring
needed)
20
10-Nov-11
Layered Systems
Each layer provides certain facilities
Hides part of lower layer
Provides well-defined interfaces
Serves various functions
Kernels: provide core capability, often set of
procedures
Various scoping regimes
Opaque versus translucent layers
21
10-Nov-11
22
10-Nov-11

of layered systems
Advantages
Abstraction (deals with complexity)
Modifiability
Changing one layer influences only the two adjacent layers
Reuse
Different implementations easy to substitute
Interfaces
Disadvantages
Not all systems suitable for this
Performance may require other coupling
Abstraction quite hard
23
10-Nov-11
Interpreters
Execution engine simulated in software
Data
Representation of program being interpreted
Data (program state) of program being interpreted
Internal state of interpreter
Control resides in execution cycle of
interpreter
But simulated control flow in interpreted program
resides in internal interpreter state

Syntax-driven design
24
10-Nov-11
25
10-Nov-11
Rule-based systems
Store and manipulate knowledge to interpret
information in a useful way

Especially used in artificial intelligence
Exp
Doctor diagnoses based on symptoms
Game move deduced
Components
List of rules or rule base
An inference engine
Temporary working memory
User interface
26
10-Nov-11
27
10-Nov-11
Communicating Processes
Components: independent processes
Typically implemented as separate tasks
Connectors: message passing

Point-to-point
Asynchronous and synchronous
RPC and other protocols can be layered on top
28
10-Nov-11
Event Systems
Components: objects or processes
Interface defines a set of incoming procedure calls
Interface also defines a set of outgoing events
Connectors: event-procedure bindings
Procedures are registered with events
Components communicate by announcing events at
appropriate times
When an event is announced the associated
procedures are (implicitly invoked)
Order of invocation is non-deterministic
In some treatments connectors are event-event
bindings
29
10-Nov-11

of event systems
Advantages
Support reuse: any component can be introduced in the
system simply by registering it for the events of the system

Implicit invocation => easy evolution (modifiability)
Disadvantages
No control over the overall computation
Component does not know what other components respond
Component may know who responds but does not know order
Data exchange
Can provoke performance problems
Reasoning about correctness: problematic
30
10-Nov-11
Classical Databases
Central data repository
Schemas designed specifically for application
Independent operators
Operations on database implemented
independently, one per transaction type
Interact with database by queries and updates
Control
Transaction stream drives operation
Operations selected on basis of transaction type
31
10-Nov-11
32
10-Nov-11
The Blackboard Model

Knowledge sources
World and domain knowledge partitioned into
separate, independent computations
Respond to changes in blackboard
Blackboard data structure
Entire state of problem solution
Hierarchical, nonhomogeneous
Only means by which knowledge sources interact to
yield solutions
Control
In model, knowledge sources self-activating
33
10-Nov-11
34
10-Nov-11
Some case studies
35
10-Nov-11
1. KWIC
In his paper (1972) David Parnas proposed
the following problem

The KWIC (Key Word in Context) index system
accepts an ordered set of lines; each line is an
ordered set of words, and each word is an ordered
set of characters. Any line may be circularly
shifted by repeatedly removing the first word and
appending it at the end of the line. The KWIC index
system outputs a listing of all circular shifts of all
lines in alphabetical order.
(On the Criteria to be Used in Decomposing Systems into
Modules - discusses the important design decisions that
impact how we modularize our software systems)
36
10-Nov-11
Architectural solutions for KWIC

Shared data
Abstract Data Types
Implicit invocation
Pipe-and-filter
37
10-Nov-11
KWIC design issues

Changes in the processing algorithm
Line shifting on each line after it is read, on all lines
after they are read or on demand

Changes in the data representation
Enhancement to system function
Performance
Reuse
38
10-Nov-11
Main Program/Subroutine with

shared data
Problem decomposed according to 4 basic
functions
Input, shift, alphabetize, output
Components coordinated by main program
that sequences through them

Data in shared storage
Communication: unconstrained read-write
protocol
Coordinator ensures sequential access to data
39
10-Nov-11
KWIC shared data solution
40
10-Nov-11
Shared data, pro and cons

Advantages
Data can be represented efficiently
Intuitive appeal
Disadvantages
Modifiability
Change in data format affects all components
Change in overall processing algorithm
Enhancements to system function
Reuse not easy to do
41
10-Nov-11
Abstract data types (ADT)

Similar set of five modules, with interfaces
Data is not shared by computational components
Accessed via interfaces
42
10-Nov-11
KWIC, ADT solution
43
10-Nov-11
ADT, pro and cons

Advantages
Logical decomposition into processing modules
similar to shared data
Algorithms/data can be changed in individual
modules w/o affecting others
Better reuse (module has fewer assumptions about
other modules)
Disadvantages
Enhancing the function
Modify existing modules -> bad for simplicity, integrity
Add new modules -> performance penalties
44
10-Nov-11
Implicit invocation
Shared data as the integration mechanism
More abstract data interfaces
Data accessed as a list/set
Computations invoked implicitly when data is
modified
Line added -> event to shift module
Circular shifts produced in another shared data
store -> event to alphabetizer, invoked
45
10-Nov-11
KWIC, implicit invocations
46
10-Nov-11
Implicit invocation, pro and cons

Advantages
Functional enhancements easily
Data changes possible
Reuse
Disadvantages
Difficult to ctrl processing order of implicitly invoked
modules
Data representation uses more space
47
10-Nov-11
Pipe and filter

Four filters
Input, shift, alphabetize, output
Process data and send it to the next
Distributed ctrl
Data sharing
Only the one transmitted on pipes
48
10-Nov-11
KWIC, pipes and filters
49
10-Nov-11
Pipe and filter, pros and cons

Advantages
Maintains intuitive flow of processing
Reuse supported
New functions easily added
Amenable to modifications
Disadvantages
Impossible to modify design to get interactive
system
Data is copied between filters > space used
inefficiently
50
10-Nov-11
Comparison
Shared data ADT
Impl.
invocation
Pipe and
filter
Changes in the
processing
algorithm
Changes in the
data representation
Enhancement to
system function
+
-
+
+
Performance
Reuse
10-Nov-11
51
2. Instrumentation software
Develop a reusable system architecture for
oscilloscopes
Rely on digital technology
Have quite complex software
Reuse across different oscilloscope products

Tailor a general-purpose instrument to a specific set
of users
Performance important
Rapid configuration of software within the
instrument
=> Domain-specific software architecture

52
10-Nov-11
53
10-Nov-11
Object-oriented model of
software domain
Clarified the data types used for oscilloscopes
Waveforms, signals, measurement, trigger modes,
No overall model to explain how the types fit
together
Confusion about partitioning of functionality
Should measurements be associated with types of
data being measured or represented externally?

Which objects should the user interface interact
with?
54
10-Nov-11
55
10-Nov-11
Layered model of the

oscilloscope
Well-defined grouping of functions
Wrong model for the application domain
Layer boundaries conflicted with the needs of the
interaction among functions

The model suggest user interaction only via Visualization,
but in practice this interaction affects all layers (setting

parameters, etc)
56
10-Nov-11
Pipe-and-filter model
Signal transformers used to condition external signals
Acquisition transformers derive digitized waveforms
from these signals

Display transformers convert these waveforms into
visual data
Oscilloscope functions were viewed as incremental
transformers of data
Corresponds well with the engineers view of signal
processing as a dataflow problem
Main problem:
How should the user interact?
57
10-Nov-11
58
10-Nov-11
Modified pipe-and-filter model

Each filter was associated with a control interface
Provides a collection of settings to be modified
dynamically by the user

Explains how the user can make incremental
adjustments to SW
Decouples signal-processing from user interface
Signal-processing SW and HW can be changed
without affecting the user interface as long as the

control interface remains the same
59
10-Nov-11
60
10-Nov-11
Modified pipe-and-filter model,

more
Further specialization
Pipe-and-filter lead to poor performance
Problems with internal storage and data exchange between filters
Waveforms have large internal storage => not practical for
filters to copy waveforms every time they process them
Filters may run at radically different speeds
Not good to slow faster filter just to keep the pace with slower
ones
Solution: several types of pipes (distinct colours)
Some allowed data processing w/o copying
Slow filters allowed to ignore incoming data when already
processing other data
=> the pipe/filter computations more tailorable
61
10-Nov-11
62
10-Nov-11
Instrumentation software
summary
Case study shows
Some issues for developing architectures for
industrial SW
Different styles => different effects on solution
Software must be typically adapted from pure
forms to specialized styles (domain specific)

Here the result depended on properties of pipeand-filter architecture adapted to satisfy the
needs of the product family
63
10-Nov-11
3. Mobile Robotics
The system controls a manned or partially
manned vehicle
Car, submarine, space vehicle,
Build software to control the robot

External sensors and actuators
Real-time
Input provided by sensors
Control the motion
Plan the future path
64
10-Nov-11
Mobile Robotics cont

Complicating factors
Obstacles may block the path
Imperfect sensor input
Robot might run out of power
Accuracy in movement
Manipulation with hazardous material
Unpredictable events might lead to need of rapid
response
65
10-Nov-11

Consider four (4) architectural designs
Control loop
Layered design
Implicit invocation
Blackboard
66
10-Nov-11

Design considerations
Req 1: deliberative and reactive behaviour
Coordinate robot actions with environment reactions
Req 2: uncertainty
The robot needs to act based on incomplete and unreliable
information
Req 3: account for dangers
Fault tolerance, safety, performance
Req 4: flexibility
Application development requires experimentation and
reconfiguration
67
10-Nov-11

Requirements of different kind, application
depends on complexity and predictability

Robot in another planet => fault tolerance
The four requirements guide the evaluation of the
four architectural alternatives
68
10-Nov-11
Solution 1: control loop

A mobile robot uses a closed-loop paradigm
The controller initiates robot actions and monitors
their consequences, adjusting plans
69
10-Nov-11
Solution 1 cont
The four requirements?
+ simplicity of paradigm
- simplicity a problem in unpredictable environments
Implicit assumption: continuous changes in environment require

continuous reaction
Robots face discrete events
Switch between behaviour modes - how to change between
modes?
How to decompose the software into cooperating
components?
70
10-Nov-11
Solution 1 cont
Req 2: uncertainty
- A trial-and-error process
+ simplicity makes duplication easy
Req 4: flexibility
+ the major components (supervisor, sensors, motors)
separate and replaceable
71
10-Nov-11
Solution 1 cont
Summary:
Paradigm appropriate for simple robotics
Can handle only a small number of external events
No really for complex decomposition of tasks
72
10-Nov-11
Solution 2: layered architecture

Eight (8) levels:
Level 1: Robot control routines (motors, joints, )
Levels 2&3: input from the environment
Sensor interpretation and integration
Level 4: robots model of the real world

Level 5: navigation
Levels 6&7: scheduling and planning of robot
actions
Dealing with problems in level 7
Level 8: user interface and supervisory functions
73
10-Nov-11
Solution 2 cont
+ More components to delegate tasks to
+ indicates concerns that must be addressed
Sensor integration
+ defines abstraction levels to guide the design
Robot ctrl vs navigation
- does not fit the actual data and control-flow patterns
- does not separate the data hierarchy (1-4) from the control
hierarchy (1,5-8)
74
10-Nov-11
Solution 2 cont
Req 2: uncertainty
+ abstraction layers manage this
Req 3: account for danger

+ managed by the abstraction mechanism: data and
commands are analysed from different perspectives
Fault tolerance and passive safety ok; active safety not ok
Req 4: flexibility
- interlayer dependencies an obstacle
- complex relationships between layers can become difficult
to manage
75
10-Nov-11
Solution 2 cont
Summary:
Provides a framework for organizing components
Precise about roles of layers
Problems when adding detail at implementation
level
The communication pattern in a robot will not follow the
scheme of the architecture
76
10-Nov-11
Solution 3: implicit invocation

Task-control architecture
Based on hierarchies of tasks
Task trees
Parent tasks initiate child tasks
Software designer can define temporal dependencies
between tasks
Dynamic reconfiguration of task trees at run time
Uses implicit invocation to coordinate interaction
between tasks
Tasks communicate by multicasting messages via a
message server (redirects msgs to tasks registered to

handle them)
77
10-Nov-11
Solution 3 cont
TCAs implicit invocation of msgs supports:
Exceptions: exception handling override tasks
Change processing mode
Can abort or retry tasks
Better suited for managing spontaneous events
Wiretapping: intercept messages by superimposed
tasks
Safety-checks of outgoing commands
Monitors: read information and execute actions

Fault-tolerance issues using agents to supervise the system
78
10-Nov-11
Solution 3 cont
+ Separation of action and reaction via the task trees and
exceptions, wiretapping and monitors
+ concurrency explicit: multiple actions can proceed
simultaneously and independently
- though in practice limited by the central message server
- relies on a central control point
79
10-Nov-11
Solution 3 cont
Req 2: uncertainty
- not explicitly in the model
Maybe via task trees and exceptions
Req 3: dangers
+ exception, wiretapping, monitors
+ fault tolerance by redundancy
Multiple handlers registered for same signal, one fails another
takes over
Multiple occurrences of same request: concurrently
Req 4: flexibility
+ implicit invocation allows incremental development and
replacement of components
80
Often sufficient to register new handlers in central server

10-Nov-11
Solution 3 cont
Summary:
TCA offers a comprehensive set of features for
coordinating tasks
Appropriate for complex robot projects
81
10-Nov-11
Solution 4: blackboard
Based on the following components:
82
Captain: overall supervisor

Map navigator: high-level path planner
Lookout: monitors the environment
Pilot: low-level path planner and motion controller
Perception subsystem: raw input from sensors and
its integration to an interpretation
10-Nov-11
Solution 4 cont
+ components interact via the shared repository
- control flow must be coerced to fit the database
mechanism
Components do not communicate directly
Req 2: uncertainty
+ blackboard the means for resolving conflicts and
uncertainties
All data available in the database
83
10-Nov-11
Solution 4 cont
+ communication via a central service, the database
Exception handling, wiretapping, monitors can be implemented

by adding modules that watch the database for certain signs of
problematic situations
Req 4: flexibility
+ Supports concurrency
+ Decouples senders from receivers
84
Facilitates maintenance
10-Nov-11
Solution 4 cont
Summary:
The architecture is capable of modelling the
cooperation of tasks
Coordination
Resolving uncertainty
Slightly less powerful than TCA
Not the only possibilities for robotics
85
10-Nov-11
Comparison
Control loop Layers
Task coordination
Dealing with
uncertainty
Fault tolerance
Safety
Performance
Flexibility
10-Nov-11
Impl.
invocation
Blackboard
+-
++
+-
+-
++++-
+++-
++
++
++
+
+
+
+
+
86
Todays take away

A basic collection of architectural styles is
necessary
Small case studies are useful for illustrative
purposes
Same (rather basic) ideas come back in our field
Dropbox
Cloud computing
Wikipedia
87
10-Nov-11
Lecture 4

Case studies on architectural styles, observe the
achieved qualities
Today: how to build an architecture with ADD
method
First exercise set is available on the web
2
Return answers in 1 week
15-Nov-11
SA terminology,3
4.
Applies to one system

Describes element types, how they interact, how
Describes the instances that exist in the system
Level of specificity needed to design a system
15-Nov-11
Architecture in the life cycle

Evolutionary Delivery Life Cycle
User and customer feedback
Iterate through several releases before final release
Adding of functionality with each iteration
Domain analysis,
Requirements analysis,
Risk analysis
SA design
Hardware
Architecture
design
Detailed design,
Coding,
Integration, Testing
4
15-Nov-11
Evolutionary delivery life cycle
15-Nov-11
Requirements
Architecture is shaped by requirements
Functional, quality, and business requirements
Called architectural drivers
Identifying drivers
Determine highest priority business goals (few!)
Turn these business goals into quality scenarios
Choose the ones with most impact on architecture:
these are the architectural drivers (less than 10)
15-Nov-11
Attribute-Driven Design (ADD)

method
Method to design architecture so that both
functional and quality requirements are met

Defines SA by decomposing based on the quality
attributes
Recursive decomposition process; at each stage
Tactics are chosen to satisfy some qualities
Functionality is added to instantiate the module
types provided by the tactic

Input: the set of quality scenarios for drivers
Key drivers may change during design, due to
Better understanding or changing of requirements
15-Nov-11
ADD output
First several levels of a module decomposition view of
an architecture
Not all details of the views result from applying ADD
Necessarily coarse grained
System described as
a set of containers for functionality
the interactions among the containers
Critical for achieving desired qualities

Provides framework for achieving the functionality
Difference between ADD output and an architecture
ready for implementation

Detailed design decisions postponed
Flexibility
8
15-Nov-11
Case study
Garage door opener
Responsible for raising and lowering the garage
door, via
Switch
Remote control
Home information system
It is possible to diagnose problems of opener from
the home information system (HIF)

Product line architecture! (PLA)
15-Nov-11
Sample input
ADD assumes functional requirements and
constraints as input
ADD also needs the quality requirements
Set of system-specific quality scenarios
These provide a checklist to be used for the
development of system-specific scenarios

Only the necessary detail
10
15-Nov-11
Case study: quality scenarios

Device and controls for opening and closing
the door are different for the different products

in the product line
May include controls from within the HIF
Product architecture for a specific set of controls
should be directly derivable from the PLA

Processor used in different products will differ
Product architecture for each specific processor
11
15-Nov-11
Case study: quality scenarios 2

If an obstacle (person/object) is detected by garage
door during descent, it must halt or re-open within 0.1

second
Garage door opener should be accessible for
diagnosis and administration from within the HMI
Using a product-specific diagnosis protocol
Should be possible to directly produce an architecture
that reflects this protocol
12
15-Nov-11
ADD Steps
Choose the module (initially whole system) to
decompose
Required input available for that module
Refine the module according to following steps

Choose architectural drivers
Choose architectural tactic/style that satisfies the
drivers
Instantiate modules and allocate functionality
Define interfaces of child modules
Verify and refine use cases and quality scenarios and
make them constraints for child modules
Repeat steps above for every module that needs
further decomposition
13
15-Nov-11
Choose module to decompose

Modules: system, subsystem, submodule
Case study:
Garage door opener is the system
One constraint: opener must interoperate with the
home information system (HIS)
14
15-Nov-11
Choose architectural drivers

Architectural drivers: functional and quality
requirements that shape the architecture

Among the top priority requirements for the module
To be addressed in the initial decomposition of the
system
Case study:
Real-time performance
Modifiability to support product lines
Online diagnosis supported
15
15-Nov-11
More on architectural drivers

Determining these drivers is not only in the
beginning of the process

Exp: we need to see an example of a garage door
to know we want it stopped in 0.1 sec

Less important requirements are satisfied within
the constraints of the most important

We decompose based on drivers
16
15-Nov-11
Choose architectural style

For each quality attribute there are
Identifiable tactics and styles to implement them
Each tactic is designed to realize one/more
attributes
The styles in which the tactics are embedded have
impact on other attributes
Balance between qualities needed
We need to identify child modules required to
implement the tactics
17
15-Nov-11
Choose architectural style 2

Goal of this step
Establish overall style consisting of module types
Style should satisfy drivers
Constructed by composing selected tactics
Selection guided by
Drivers
Side effects of pattern on other qualities
18
15-Nov-11
Choose architectural style: exp 1

Modifiability at design time
localize changes tactic: semantic coherence and
information hiding
Separate responsibilities dealing with user interface,
communication, sensors, diagnosis

First 3 virtual machines: they will vary for the different
products to be derived from the PLA
19
15-Nov-11
Choose architectural style: exp 2

Performance
resource demand and resource arbitration
tactics: increase computational efficiency and

choose scheduling policy
Performance-critical computations made efficient
Performance-critical computations scheduled to achieve the
timing deadline
20
15-Nov-11
Instantiate modules and allocate

functionality
Allocate functionality
Use case for parent module => understand
distribution of functionality
Add/remove child modules to fulfill required
functionality
Every use case of parent module: representable by
a sequence of responsibilities within child modules
Discover necessary info exchange
Information and producer/consumer roles
21
15-Nov-11
Instantiate modules and allocate

functionality 2
Represent architecture with views
Dynamic and deployment info required to analyze
achievement of qualities
We need additional views
Module decomposition view
Concurrency view
Deployment view
22
15-Nov-11
Concurrency view
Models dynamic aspects
Parallel activities
Synchronization
Identifies
Resource contention problems
Possible deadlock situations
Data consistency issues
Leads to uncover new responsibilities in the
modules and possibly new modules

Recorded in module decomposition view
Exp new module: resource manager
23
15-Nov-11
Concurrency view 2
Component-and-connector view
Components: instances of modules
Connectors: carriers of virtual threads
Virtual thread: execution path through system or
parts of it
Virtual versus operating system threads
Synchronizes with, starts, cancels, communicates
with
24
15-Nov-11
Concurrency view 3
Shows instances of modules in module
decomposition view for understanding mapping

between views
Synchronization point located in a certain module
This responsibility assigned at right place
Crossing of two virtual threads: sign that some
synchronization needed
25
15-Nov-11
Concurrency view 4
Use cases
Two users doing similar things at the same time
One user performing multiple activities
simultaneously
Starting up the system
Shutting down the system
26
15-Nov-11
Concurrency view 5
Concurrency might also be a point of variation
Sequential initialization for some products, parallel
for others
In this case the decomposition should support
techniques to vary the initialization method
Exchanging component
27
15-Nov-11
Deployment view
New responsibilities from need to deploy
On multiple processors or specialized hardware
Deployment view decomposes virtual threads

Virtual threads on distinct processors
Messages between them
Basis for analyzing network traffic, see possible
congestion
28
15-Nov-11
Deployment view 2
Decide if multiple instances of some modules are
needed
Reliability
Supports reasoning about using special-purpose
hardware
Architecture drivers help determining the
allocation of components to hardware
Replication vs real-time scheduling
29
15-Nov-11
Define interfaces of child

modules
Module interface
Services and properties provided and required
Different from signatures
Documents what others can use and on what they
can depend
Module decomposition view documents
Producers/consumers on information
Patterns of interaction requiring modules to provide
and use services
30
15-Nov-11
Define interfaces of child modules 2

Concurrency view documents
Interactions among threads, leading to module
interface providing or using a service

The info that a component is active
Own thread running
The info that a component synchronizes,
sequentializes, blocks calls
31
15-Nov-11
Define interfaces of child modules 3

Deployment view documents
Hardware requirements (special purpose HW)
Timing requirements
Exp: computation speed of processor
Communication requirements
Exp: information updates not more than once per second
32
15-Nov-11
Verify and refine

Decomposition into modules needs to be verified
Child modules need preparation for their own
decomposition
Done for
Functional requirements
Constraints
Quality requirements
33
15-Nov-11
Functional requirements
Child modules have responsibilities
Derived from functional requirements
decomposition
Use cases for the module
Split and refine parent use cases
traceability
Exp: use cases that initializes the whole system

Broken into initialization of subsystems
34
15-Nov-11
Case study
Initial responsibilities
Open/close door on request
Locally or remotely
Stop door within 0.1 sec when detect obstacle
Interact with HIS
Support remote diagnostics
35
15-Nov-11
Case study 2
Decomposition of responsibilities
User interface: recognize user requests and
translate them into form expected by the

raising/lowering door module
Raising/lowering door module:
control actuators to raise/lower door
Stop door when fully closed or fully open
Obstacle detection
36
15-Nov-11
Case study 3
Decomposition of responsibilities, more:
Communication VM
Manage communication with HIS
Sensor/actuator VM
Manage interaction with sensors and actuators
Scheduler
Guarantee deadline
Diagnosis
Manage interaction with HIS for diagnosis
37
15-Nov-11
Constraints
Constraints of parent module satisfied by
Decomposition satisfies the constraints
Using certain OS
Constraint satisfied by single child module
Special protocol
Constraint satisfied by multiple child modules
Web usage requires two modules (client and server)
38
15-Nov-11
Case study
Constraint: communication with HIS is maintained
Communication virtual machine will recognize if this
is unavailable
Constraint satisfied by a single child
39
15-Nov-11
Quality scenarios
Need to be refined and assigned to child
modules
Possibilities
QS completely satisfied by decomposition
QS may be satisfied by decomposition with
constraints on child modules

Layers and modifiability
Decomposition neutral wrt QS

QS assigned to child modules
QS not satisfiable by decomposition
Decomposition reconsidered or reason for this recorded
Typical trade-offs
40
15-Nov-11
Case study
Device and controls for opening and closing
the door are different for the different products

in the product line
May include controls from within the HIF
QS delegated to user interface module
Processor used in different products will differ

Product architecture for each specific processor
QS delegated to all modules
41
15-Nov-11
Case study 2
If an obstacle (person/object) is detected by
garage door during descent, it must halt or reopen within 0.1 second
QS delegated to scheduler and obstacle detection
module
Garage door opener should be accessible for
diagnosis and administration from within the

HMI
Using a product-specific diagnosis protocol
QS split between diagnosis and communication
modules
42
15-Nov-11
Step outcome
Decomposition of module into children
Each child has
Set of responsibilities
Set of use cases
Interface
Quality scenarios
Collection of constraints
Enough for next iteration of decomposition
43
15-Nov-11
Iteration progress
Vocabulary of modules and their responsibilities
Variety of use cases and quality scenarios and
understood some of their ramifications

Information needs of modules
Their interactions
Not decided yet

Communication language, algorithm for obstacle
detection, etc
44
15-Nov-11
Iteration outcome
We defined enough to allocate work teams and
give them charges

If we design a large system
We can proceed to next iteration and decide on
answers for the questions

If we design small system
45
15-Nov-11
Forming the team structure

When modules fairly stable
They can be allocated to development teams
(existing, new)
Team structure mirror module decomposition
structure
Each team creates its own internal work
practices (or adopts a system-wide set)
Bulletin boards
Web pages
Naming conventions for files
Configuration control system
Quality assurance and testing procedures set
up for each group

46
Coordinate with others

15-Nov-11
Team communication
Intra team
High bandwidth
Inter team
Low bandwidth
Assumes system designed based on separation
of concerns
As software systems, the teams should strive for
loose coupling and high cohesion
47
15-Nov-11
Modules as mini-domains
Modules encapsulate changeable details
They exhibit only the interface
Interface common, unified set of services to the users
Domain specialized knowledge or expertise
Examples
Module user interface layer of systems
UI tools independent of UI communication with other modules
Module process scheduler
Process number and algorithms: hidden
Most effective
Assign team members according to their expertise
48
15-Nov-11
Organization Architecture
The expertise determines the architecture
Database specialist
Telecom specialist
49
15-Nov-11
Creating a skeletal system

Provide underlying capability for implementing
functionality
In order advantageous for project
Classical software engineering: stubbing out

Architecture-driven: sequence becomes clear
First
Implement the SW dealing with execution and interaction of arch
comps
Scheduler, rule engine, process synchronization, CS coordination
Or install
Then: simplest functionality in each component
Then order decreasingly according to importance to project
Evolutionary Delivery Life Cycle (EDLC)
Microsoft and EDLC

Complete skeletal system is early formed
Low-fidelity working system
Rebuilt frequently (nightly)
=> features can be judged if enough or not
Possible problem
First development team to complete portion of system
defines interfaces
Penalty for more complex parts of the systems
Alleviation: negotiate interfaces in skeletal system early
51
15-Nov-11
Flight simulation example

Most sophisticated SW
Highly distributed
Rigurous time requirements
Modifiability needed
Also integrability
The ease with which separately developed elements can be
made to work together under SW requirements

Tactics
Keeping interfaces simple, small, stable
Adhering to defined protocols
Loose coupling, minimal dependencies
Components
52
15-Nov-11
Boeing simulators
53
15-Nov-11
Some history of the simulator

Very large (1.5 million LOC)
Long lifetimes (~40 years)
Stringent real-time and fidelity requirements
Simulator should behave EXACTLY like the real aircraft
Normal flight
Emergency maneuvers
Equipment failures
1987: Air Force investigates OO techniques

Existing simulators since 1960s, problems
Integration phase was increasing exponentially with size and
complexity
Cost of modifications > cost of original system
54
15-Nov-11
Roles in the simulator

Crew
Inside a motion platform, surrounded by instruments
Look at visuals and need to take actions
How to operate the aircraft
How to perform maneuvers: mid-air refuelling
How to respond to situations: attack
Fidelity important
Environment
Individuals, atmosphere, threats, weapons, other
aircraft
Instructor
Monitors, initiate training situations
55
15-Nov-11
Fidelity of models
Exp: air pressure
Model considers just the aircraft altitude
Model considers the aircraft altitude and local
weather
Model considers the aircraft altitude, local weather,
nearby aircraft
The more fidelity, the more computational
complexity
56
15-Nov-11
Todays takeout
ADD aims to create a skeleton system
Working interactions
Give a priority to implementing modules
Assign teams to modules
Main idea
Incrementtal developing, testing
SA in the centre
57
15-Nov-11
Software Architecture
Lecture 5

Case studies on architectural styles, observe the achieved qualities
The ADD method
Documenting software architecture

Today: Bass and all
Next time: Hofmeister and all
22 November 2011
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 al)
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 al)
3
22 November 2011
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
22 November 2011
Architectural structures
Module structures
Component-and-connector structures
Allocation structures
22 November 2011
SA structures
Module
Component-and-connector
Concurrency
Decomposition
Uses
Allocation
Work
Assignment
Class
Shared data
Deployment
Client-server
Process
Layered
Implementation
22 November 2011
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
22 November 2011
Component-and-connector structures
Elements:
Runtime components main units of computation
Connectors communication vehicles between
components
Major executing components and their interactions
Major shared data stores
Replicated parts, data flows, parallel system parts
Changes in system structure as it executes
22 November 2011
Allocation structures
Show the relationship between software
elements and elements in one/more external

environments
Where SW is created and executed

Processors each SW element executes on
Files for storing elements during system lifetime
Assignment of SW elements to development teams
22 November 2011
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
22 November 2011
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 design or
implementation
11
22 November 2011
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
22 November 2011
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
22 November 2011
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
22 November 2011
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
22 November 2011
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
22 November 2011
structures, 2
Concurrency
Units: components connected by logical threads
Logical thread
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
22 November 2011
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
22 November 2011
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
22 November 2011
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
22 November 2011
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
22 November 2011
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
22 November 2011
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
22 November 2011
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
22 November 2011
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
22 November 2011
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
22 November 2011
Which structures?
Among architects obligations
Understand how the various structures lead to
quality attributes
Choose the structures that will best deliver those
attributes
27
22 November 2011
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

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

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
Decomposition structure: engineered to build a
modifiable system
31
22 November 2011
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
32
22 November 2011
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
33
22 November 2011
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
34
22 November 2011
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
35
22 November 2011
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
Key means to educate people who need an
overview
36
22 November 2011
Views and SA documentations
Basic principle of documenting SA:

Documenting the architecture is a matter of
1.
2.
Documenting the relevant views

Adding documentation that applies to more than one
view
Parts in documenting
1. Choosing relevant views
2. Documenting each relevant view
3. Documenting info that applies to more than one
view
37
22 November 2011
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 uses
Highlight different elements and relationships
May be specific to the system
38
22 November 2011
Choosing relevant views 2

Produce candidate view list (matrix)
List stakeholders
List needed views
Fill in cell with amount info: none, overview only,
moderate detail, high detail
39
22 November 2011
Example of table
40
22 November 2011
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
22 November 2011
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
22 November 2011
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
43
22 November 2011
44
22 November 2011
Primary presentation
Elements that populate the view and relationships
among them
Not necessarily all of them
Should contain the info to be conveyed about
system
Exp: normal operation here, exception and error
handling in other parts

Usually graphical, sometimes tabular
45
22 November 2011
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
46
22 November 2011
Context diagram
Shows how system in the view relates to
environment in the vocabulary of view

Exp: C&C view
Show which component and connectors interact
with external components and connectors

Via which interfaces and protocols
47
22 November 2011
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
48
22 November 2011
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
49
22 November 2011
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
50
22 November 2011
Documenting behavior
Structural information (views) not enough
Exp. deadlock possibilities 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 together
51
22 November 2011
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
52
22 November 2011
Behavior notations
Statechart diagrams
Describe 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
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?
53
22 November 2011
Documenting interfaces
Interface: boundary between entities
Over boundary elements interact and communicate
Interfaces are architectural

They carry the properties externally visible to other
elements
Documenting interfaces consists of
Naming and identifying interface: signature
Document its syntax and semantics
54
22 November 2011
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
55
22 November 2011
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
56
22 November 2011
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!
57
22 November 2011
Document only once

Modules correspond to one/more elements in C&C
view
These elements are likely to have similar/identical
interfaces
A module may appear in more than one module view
Module decomposition view
Uses view
Documenting in several places: needless duplication

Refer to the earlier specified interface and only add
the info specific to the later specified view
58
22 November 2011
Template for documenting interfaces
Needed; one possibility

1. Interface identity
2. Resources provided
Resource syntax, semantics, usage restriction
3. Data type definition
4. Exception definition
5. Variability provided by interface
6. Quality attribute characteristics of interface
7. Element requirements
8. Rationale and design issues
9. Usage guide
59
22 November 2011
Documenting element interface
60
22 November 2011
Interface identity
For elements with multiple interfaces
Identify individual interfaces to distinguish them
Naming, version number
61
22 November 2011
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
Resource name, names and data types of arguments, etc
Their semantics: result of invoking the resource
Any restrictions on their use
62
22 November 2011
Resource semantics
In natural language, or Boolean algebra, or
traces, or pre/post-conditions
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
63
22 November 2011
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
64
22 November 2011
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
65
22 November 2011
Exception definition
Exceptions raised by the interface resources
Same exception may be raised by more than one
resource
List each resources exceptions
Define them in a dictionary
Common exception handling also defined here
66
22 November 2011
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
67
22 November 2011
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
68
22 November 2011
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
69
22 November 2011
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
70
22 November 2011
Usage guide
Semantics of resource:
Provided resources + element requirements
Sometimes not enough
Semantics need 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 (statechart)

Examples as sequence diagrams
71
22 November 2011
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
View catalog and view template
2. What the architecture is
Short system overview informing about purpose of system, the

way views relate to each other; list of elements and where
they appear; project glossary
3. Why the architecture is the way it is
72
Context of the system, external constraints for the architecture

shape, rationale for coarse grained large-scale decisions
22 November 2011
Documentation across views
73
22 November 2011
How the documentation is organized

to serve stakeholder
View catalog
Readers introduction to views included in the
documentation suite
Using documentation suite 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
74
22 November 2011

to serve stakeholder, 2
View catalog, 2
One entry per each view in documentation suite
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)
75
22 November 2011

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
76
22 November 2011
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
77
22 November 2011
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
78
22 November 2011
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
79
22 November 2011
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
80
22 November 2011
UML notation
Interfaces
81
22 November 2011
UML notation
Modules
82
22 November 2011
UML notation
Relations
83
22 November 2011
UML notation
Decomposition
84
22 November 2011
UML notation
Generalization
85
22 November 2011
UML notation
Layers
86
22 November 2011
UML notation
Instantiation
87
22 November 2011
UML notation
Ports
88
22 November 2011
UML notation
Deployment
89
22 November 2011
Todays take away

Systems today are complex
One can only apprehend several views of the
system
5 blind men and an elephant; modern version from
Grady Booch:
http://www.computer.org/csdl/mags/so/2010/06/mso201006
0088.html
Documentation is key
And needed in industry anyway
Structures and styles?
90
22 November 2011
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

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

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
Some Architectural Styles

Data flow systems
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
94
22-Nov-11
Lecture 6

The ADD method

Bass and all
Today: Hofmeister and all the four views
23 November 2011
The four views origin

Study on SA for large, complex INDUSTRIAL
systems
Study purpose
Understand architectural issues facing designers
Understand current practices, and best practices
Find out commonalities across domains
Find out underlying principles leading to good and
useful SA
23 November 2011
Precise study goals

For each system
Understand the problem
Understand the SA and how it addresses the
problem
Find out the methods and approaches used by
architects in designing the SA
Find out how the SA was used during development,
maintenance, evolution, other products in the same
family, successors of the product
23 November 2011
Study broad result

SA is separated into views
Not a new idea
Not a general agreement on what views are the
most useful
Separating different aspects into different views
helps in managing COMPLEXITY
Conceptual, module, execution, and code views
23 November 2011
The four views

Based on practical observations
Architects do not necessarily recognized them as
separate views
Address different engineering concerns
Each describes a different kind of structure
Structures loosely coupled between views
23 November 2011
What the four views are

Code view
Organization of source code into object code, libraries,
binaries, then in turn into versions, files and directories
Module view
Decomposition of system and partitioning of modules into
layers
Due to complexity
Execution view
Allocation of functional components to runtime entities;
communication, coordination, synchronization between them;
mapping to HW
Conceptual view
Description of system in terms of its major design elements
and relationships among them; tied closely to application
domain
7
23 November 2011
Design tasks for each view

Global analysis
Identify external influencing factors and critical requirements
that could affect architecture
Analyze the above to come up with strategies for designing
architecture
Central design task
Define elements of the view and their relationships, how they
are configured
Global evaluation: ongoing task
Which source of info at which time (from multiple input sources)
Do decisions here have impact on prior design tasks?
Evaluate central design decisions for impact on each other
Final design task

Exp: resource budgeting, interface definition
8
23 November 2011
Global analysis
Purpose
Identify external factors that influence the
architecture
Analyze the above and develop strategies for
accommodating them into architecture
Factor tables
Meant to complement risk analysis and
requirements analysis
Factors
Organizational
Technological
Product
9
23 November 2011
Organizational factors
Constrain design choices
Some apply only to developing product
(development schedule, budget)
Some apply to all products of an organization
(organizational attitudes, SW process)
Record results of analysis process
Individual developers should use them when
making decisions to address specific design
choices
Architect should monitor the efficacy and relevance
of the chosen strategies, make changes if needed
10
23 November 2011
Technological and product

factors
Technological factors
Obvious influence on architecture
Hardware, software, standards
Changes over time
Product factors
Primary influence over the architecture
Functional features of the product
Qualities
Should support future changes
11
23 November 2011
Global Analysis activities
12
23 November 2011
Analyze factors
Identify and describe factors that
Have a significant global influence
Can the factors influence be localized?
Factor important during which stages of development
New expertise and skills for this factor?
Could change during development
Are difficult to satisfy
With which there is little experience
13
23 November 2011
Analyze factors, 2
Factor flexibility: what is negotiable
With any stakeholders
Info needed when factors conflict or cannot be
fulfilled
How to determine
Possible to influence/change factor so that architecture task
becomes easier?
How can be influenced?
To what extent can be influenced?
14
23 November 2011
Analyze factors, 3
Factor changeability: what can change
In the factor itself
In the way you use it in the future
How to determine
In what way could the factor change?
How likely will it change during/after development?
How often?
Will factor be affected by changes in other factors?
15
23 November 2011
Analyze factors, 4
Analyze impact of factors
On the architecture
If one factor was to change, which will be affected
and how:
Other factor?
Components?
Modes of system operation?
Other design decisions?
16
23 November 2011
Factor tables
17
23 November 2011
Develop strategies
Identify issues and their influencing factors
Issue may arise from limitations/constraints
imposed by factors
Exp: aggressive schedule cannot include all requirements
Issue may result from need to reduce impact of
changeability of factors
Exp: reduce cost of porting to another OS
Issue may develop due to difficulty in satisfying
product factors
Exp: high throughput may overload CPU
Issue may arise from need to have a common
solution to global requirements

Exp: error handling, recovery
18
23 November 2011
Develop strategies, 2
Develop solutions and specific strategies that
address the goals:

Reduce or localize the factors influence
Reduce the impact of the factors changeability on
the design and other factors

Reduce or localize required areas of expertise or
skills
Reduce overall time and effort
19
23 November 2011
Develop strategies, 3
Identify related strategies
No strategy duplication
Standard format (issue card) to describe
Each issue, its influencing factors and their impact
General discussion of its solution
Strategies that addresses it
Meaningful names for strategies
20
23 November 2011
Issue card
21
23 November 2011
Typical categories of influencing factors

Organizational
factors
Technological
factors
Product factors
O1: Management
T1: general purpose

hardware
P1: Functional features
O2: Staff skills, interests,

strengths, weaknesses
T2: domain-specific
hardware
P2: User interface
O3: Process and

development environment
T3: software technology
P3: performance
O4: development
schedule
T4: architecture
technology
P4: dependability
O5: development budget
T5: standards
P5: failure detection,

reporting, recovery
P6: service
P7: Product cost
Typical Organizational factors
Example
Example 2
Example 3
Example 4
Example 5
Conceptual architecture view

Closest to application domain
Product = collection of decomposable,
interconnected conceptual components and

connectors
Appealing due to reuse potential, COTS
Means communication and control understood
Components: independently executing peers

Functionality
Only simple control
Connectors: communication and control aspects

29
23 November 2011
Global properties
In addition to communication, control
Exp: performance, dependability
Not all properties can be considered in the
conceptual view
Portability in module view
The considered properties should be
reconsidered in other views

Exp: performance also in execution view, make sure
its fulfilled
30
23 November 2011
Conceptual view usage

Conceptual architecture view completed:
We can reason about the system ability to fulfill
functional requirements and global properties

All use cases /scenarios used to capture desired
system behavior should be satisfied by the

conceptual view
31
23 November 2011
Design activities for conceptual view

Global Analysis
Central design task: tightly coupled tasks:
Conceptual components
Conceptual connectors
Global evaluation
Conceptual configuration
Final design task: resource budgeting

Assign resources to components and connectors
Refined in execution view
32
23 November 2011
Design tasks
Global analysis
Prior to this, consider
34
Product requirements
Use cases
System requirements and interactions
Understand interface to environment
Understand users, other interacting systems
Modes of operation for system
Functional requirements, system qualities, global
properties
23 November 2011
Global analysis for conceptual

view
Focus on factors most relevant to conceptual
view
All product factors
Closest view to domain
Technological factors: domain-specific HW,
architecture technology, domain-specific standards

Organizational factors: management, development
schedule, development budget
35
23 November 2011
Central design tasks

Define components and connector types
Define how component and connectors
interconnect
Map system functionality to components and
connectors
Functional behavior in components
Control behavior in connectors
Define instances of both and their
interconnections
36
23 November 2011
Conceptual components
Both types and instances
Have ports interaction points for component
Both incoming and outgoing messages (operations)
Each port has associated protocol

Mandates how incoming and outgoing operations
can be ordered
Concentrate the system functionality in them
37
23 November 2011
diagram
38
23 November 2011
Conceptual connectors
Both types and instances
Have roles points of interaction with other
architecture elements
Obey associated protocol
Behavior also needs to be described

The control aspects
39
23 November 2011
diagram
40
23 November 2011
Conceptual configuration
Define relations among components and
connectors
Conceptual configuration between types
Constrains how instances of the types will be
interconnected
Conceptual configuration containing instances
Defines which instances are in the product and how
they interconnect
41
23 November 2011
Final task: resource budgeting

Allocates resources to component and connector
instances
Rather late in typical design process
42
23 November 2011
Module view
Main purpose:
Get closer to the systems implementation in
software
Conceptual view
Functional relationships explicit
Module view
Functionality mapping to modules (implementation)
is explicit
Relationships among implementing elements
explicit
How the system uses SW platform (e.g. OS)
Not only a refinement of the conceptual view: also a

43
repartitioning
23 November 2011
Conceptual vs module view

Conceptual view
Functionality resides in components
Interaction via connectors
Sophisticated control functionality
Module view
Functionality + control into modules
Modules require and provide interfaces
No implementation
No configuration
Comes in the execution view
44
23 November 2011
Design tasks
Global analysis, central design, interface
design
Central design uses
Issue cards from global analysis
Components, connectors, configuration from
conceptual view
Central design produces
Modules, subsystems, layers
These will be used in interface design, plus in the central
design tasks of execution and code views
Feedback
45
23 November 2011
Design tasks
46
23 November 2011
Global analysis
Specific factors
Organizational: staff skills, process and
development environment, development budget

Technological: general-purpose hardware, software
technology, standards
Specific strategies
Related to modifiability, portability, reuse
Also related to performance, dependability, failure
detection, reporting, recovery
47
23 November 2011
Central design task

To do
Map conceptual elements to subsystems and
modules
Create layers
Assign modules to layers
Guidelines
Strategies from global analysis
Experience with prior products
General SW engineering experience
48
23 November 2011
Modules
Map conceptual elements to subsystems and
modules
Subsystem
Higher level conceptual component (contains other
components and connectors)

Can contain other subsystems and modules
Module
Corresponds to one conceptual element or many
Can be decomposed into other modules
Parent module just a container; only leaf modules
correspond to code
49
23 November 2011
diagram
50
23 November 2011
Subsystems and modules metamodel

Module
Encapsulates data and operations to provide a
service
Provided services defined by the provided
interfaces
Required services defined by the required
interfaces
Use dependency
Require and provide relations
51
23 November 2011
Defining the modules

Conceptual elements mapped to modules
Modules
Get responsibility
Decomposition
Use dependency
After initial mapping

Refine and split modules (for independent
development)
Combine modules (for efficiency)
52
23 November 2011
Defining the modules, 2

Add new (supporting) modules
No counterparts in conceptual view
Due to factors not pinned down to specific
component
Failure recovery, detection
Due to services needed by existing modules but not
provided by SW platform
Decomposition until understanding well
module responsibilities
Implementation and integration risks
53
23 November 2011
Defining the modules, 3

Container module
Contained modules more tightly coupled than
modules contained in a subsystem

Assigned as such to only one team/person to
develop
Leaf modules
Still abstract!
54
23 November 2011
Layers
Organize modules into a partially ordered
hierarchy
Module in a layer
Can use any other module in that layer
Can use modules in other layers too
Required and provided interfaces of such modules are also
required and provided by the layer
Used to constrain the use dependency

Can contain sub-layers
Additional structuring within layer
55
23 November 2011
diagram
56
23 November 2011
Layers use
Reduce complexity
Encapsulate external components
COTS SW, HW
Separate system services from user interface SW
Support reuse
Assign common services to an application services layer
Provide for design independence
Change in OS does not affect whole system
57
23 November 2011
Modules or layers first?

Start identifying layers when identifying modules
Bottom up
Layers and dependencies among them grow from module
responsibilities and their dependencies
Top down
Begin with set of layers (experience with other projects in
the domain)
When identified, modules assigned to layers
Layers are guide for defining modules
Typically: a combination
Architects have a broad layer division in mind
Application, UI, system services
58
As modules defined, they refine the layer model

Add additional layers for domain-specific functionality
Create sublayers when too complex layer
23 November 2011
Global evaluation
Multiple sources of guidance for central design task
Conceptual view design
Global analysis strategies
SA experience
General knowledge of SA and SW engineering
What info source at what time
59
23 November 2011
Global evaluation, 2
Second GE aspect
Look for feedback to tasks and decisions earlier
made in the design

Look for additional factors, issues, strategies to feed
back to the global analysis
Any decision about modules and layers will change
something in the conceptual view design
60
23 November 2011
Third aspect
Evaluate module view decisions with respect to
each other
Adjust modules and subsystems based on layer decisions
and vice versa

Define new interfaces
Revise interfaces
61
23 November 2011
Final design task: interface

design
Describe the interfaces for each of the identified
modules and layers

Detailed design
Done after central design task complete

May need to
Define new interfaces
Split/combine interfaces
Feedback to central design task
62
23 November 2011
Example interface
63
23 November 2011
Traceability
Describing the relationships of module view to
Requirements, external factors, other views
Items to be traceable:
Critical requirements
Factor tables and issue cards capture product features and
requirements affecting SA
Some traced to conceptual elements, some to modules or
layers
Impact of changes in requirements to module view
Organizational and technological factors
Elements in the conceptual view
64
24 November 2011
Module view usage

Module view: starting point to reason about
Management of module interfaces
Change impact analysis
Consistently checking of interface constraints
Confogurationmanagement
Effort estimation
Can be used for testing
65
24 November 2011
Execution view
Main purpose:
Describes system structure in terms of runtime
platform elements
OS tasks, processes, threads, address spaces
Captures
How systems functionality is assigned to the runtime
platform elements
How resulting runtime instances communicate
How physical resources are allocated to them
Location, migration, replication of runtime instances
66
23 November 2011
Execution view, 2
Driving forces
Performance, distribution requirements, runtime platform (SW,
HW)
Used for
Performance analysis, monitoring, tuning, debugging, service
maintenance
Sometimes trivial (single thread, single process)
Provides better preparation for change: This view will
likely change more often than other views because

Strong dependency on SW and HW platform => adapt to
changes/advances in technology
Tightly coupled with performance and distribution
requirements
Tuning of execution view during development
67
23 November 2011
Design tasks
Global analysis, central design, resource allocation
Central design uses
Issue cards from global analysis

Components, connectors, configuration from conceptual view
Modules, to be mapped into runtime entities
HW architecture also input here
Central design produces

Runtime entities, communication paths, execution configuration
Runtime entities input to code view
Influence system implementation (source code)
Final design task: resource allocation

Could uncover resource constraints that require some decision
changes (infrequent)
Feedback
New factors, issues, strategies feed back to global analysis
Updates in conceptual view decisions, module repartitioning
68
23 November 2011
Design tasks
69
23 November 2011
Global analysis
Specific factors
Performance requirements, communication
mechanisms
Dependability
Specific strategies
Resource sharing, scheduling policies
Sometimes these are only known later
Analysis of HW and SW platforms
70
23 November 2011
HW platform
List of HW components used in the system
Topology or interconnection of them
Determine
Which parts of HW platform could change
The likelihood of change
When the change would occur
71
23 November 2011
SW platform
Need to know the infrastructure SW in between
the HW platform and the product

OS (traditionally)
OS + network software + middleware layers +
DBMS (nowadays)
Products within a company share common SW
platform (product line products especially)
List platform elements to use in this view
72
23 November 2011
diagram
73
23 November 2011
SW platform, 2
Determine
Which parts of SW platform could change
The likelihood, time, impact of change
SW may change as result of HW change
74
23 November 2011
Runtime entities
To do
Map (conceptual components and) modules to
identified platform elements

Runtime entity allocated to a platform element
Runtime entities with no direct correspondence to
modules
Demons, other server processes
75
23 November 2011
Runtime entities, 2
Resource
Sharing
Allowed or required among runtime entities
Files, buffers, servers, etc
Replication
Distribution across hosts
Decisions recorded as runtime characteristics
of each runtime entity

Exp: host type, replication, concurrency control
used, other resource sharing policies

76
23 November 2011
Communication paths
Expected and allowed communication paths
between runtime entities

Mechanisms and resources (platform elements)
used for that communication

Communication mechanism can use platform
elements such as queues, buffers, files
Implementation of protocols for paths
Distributed among runtime entities participating in
the communication
New runtime entities can be introduced if protocol
too complex
Exp: links to special HW
77
23 November 2011
diagram
78
23 November 2011
Execution configuration
The runtime topology of the system
Instances of runtime entities and how they are
connected
Determine runtime instances and their attributes
Corresponding runtime entity and host name
Resource allocation of each instance
Info about creation and destruction
79
23 November 2011
Execution configuration, 2
Describe interconnection of runtime instances
Which runtime instances communicate
Temporary and permanent comm. paths
Execution configuration diagram
Entities and instances of them
Rarely static
Need to determine and describe
How the configuration changes over time
How are the changes controlled
Operating phase, start-up and shut-down

Some systems: configuration that changes during operation
80
23 November 2011
Global evaluation
Multiple inputs for central design task
Conceptual view design
Concurrency among conceptual components, that execution
configuration must support
Global analysis strategies

Performance, dependability
Modules and their dependencies
Constrain runtime entities and their communication
HW architecture
HW resources, constraints on SW platform
Implementation cost, avoid complex algorithms
What info source at what time

Balance these guidelines and restrictions
81
23 November 2011
Performance experiments or simulations
Analytic techniques not enough
Results of global evaluation

Adjust/refine boundaries of runtime entities
Modify their characteristics accordingly
82
23 November 2011

Consider runtime instances, budgets defined
in configuration task
Allocate them to particular HW resources
Assign specific values to the budgeted
attributes
Exp: setting process priorities
Global analysis
Identified resources to be allocated, HW, and SW
platforms => resulting resources
SW platform
Fixed or configurable number of each type of platform
elements
83
23 November 2011

2
Allocation decisions
Fairly localized
Often made at build time
Intention: use standard techniques from global
analysis
And specific strategies
Exp: RMS (rate monotonic scheduling) used to
assign priorities to processes
84
23 November 2011
Code view
Describes how SW implementing system is
organized
Source components implement individual elements in
module view
Deployment components instantiate runtime entities in
execution view
Executables, libraries, configuration files
How the above components related to each other via
intermediate components
How all of these are organized according to the
development environment of organization
Design decisions related to configuration management,
multiple releases, testing
85
23 November 2011
Primary goal of code view

Facilitate system
Construction
Integration
Installation
Testing
While respecting integrity of all other views
86
23 November 2011
Use of code view

Isolates the construction and development aspects of
87
a system in a separate view => flexibility

Code view describes how a module, its interfaces,
and dependencies are mapped to language-specific
components and dependencies
Module and execution view are languageindependent
How much of a modules functionality is implemented
in each release
How source components and intermediate libraries
are released to other teams for integration and testing
23 November 2011
Code view, 2
Sometimes straightforward
One executable, small development team
For complex systems not so

Multiple executables
Shared components
Large team
Concurrent development
Driving forces
Implementation language, development tools,
development environment, development process

88
23 November 2011
Code view, 3
Organizes code components to support
Daily concurrent development tasks
Edit, compile, build, test
Building system parts and releasing them to
different teams for installation, integration, testing

Ease of maintenance and change
Enforcement of architectural design decisions
Encapsulation, abstraction, allowed dependencies
Configuration management of different system
versions
89
23 November 2011
Design tasks
Global analysis, central design, final design task
Global analysis
Identify and review inputs to design process
Factors and strategies that influence the code view
Goal: develop strategies specifically for constructing the
system and building in flexibility
Central design task

Organize source, intermediate, and deployment components
Components relationships to module and execution views are
made explicit
Evaluate continually the decisions
Final design task
Detailed decisions referring to build procedures and
configuration management
90
23 November 2011
Design tasks
91
23 November 2011
Global analysis
Specific factors
Development platform
Development environment
Capabilities of various tools, configuration mgmt, necessary
or feasible to cross-platform development
Development process
Identify process and testing requirements
Development schedule
Analyze whether product released in stages
Analyze whether developers and testers will work
concurrently on multiple releases
92
23 November 2011
Central design task

Map elements from module and execution views
to code components
Organize them according to criteria established
during global analysis
93
23 November 2011
Source components
Identify source components
Map elements and dependencies from module
view to source components and dependencies

Organize source components using storage
structures (directories, files)
94
23 November 2011
Source components, 2
Typically source components for language-
specific interfaces and modules, or for

components that generate them
Dependencies between source components
Import: compile-time dependency
Generate: source comp generated from another
source comp (exp: preprocessing)
95
23 November 2011
Source components, 3
Module view elements mapped into language-
specific source components implementing them

Organize source components so that they can be
developed and tested by individual developers
Directory hierarchy
Database, shared repository
96
23 November 2011
Intermediate components
Identify intermediate components
Binary components, static libraries
Identify their dependencies on source
components and each other

Organize them using storage structures
(directories, files)
97
23 November 2011
Intermediate components, 2
Intermediate components specific to the
implementation language and development

environment
Organize intermediate components to facilitate
sharing
Time for edit-compile-link reduced
Static libraries
98
23 November 2011
Deployment components
Identify and map runtime entities and
dependencies in execution view to deployment

components and their dependencies
Organize deployment components
99
23 November 2011
Deployment components, 2
Deployed at runtime to instantiate runtime entities
Executables
Same as dynamic libraries, but also related to dynamic
libraries by a link dependency
Dynamic libraries
Related to binary components and static libraries by a link
dependency
Configuration descriptions
Can describe processes and resources
100
23 November 2011
Deployment components, 3
Organize deployment components
Small system: simple, one/two packages containing
files for an executable and its configuration

descriptions
Large system: can be very complex
Exp: separate file system for storage of data and for shared
memory areas
Exp: separately organize each executable and associated
components (required resources and data)
101
23 November 2011
Global evaluation
Input from
Strategies in global analysis
Design decisions in module and execution views
Development environment, execution platform
Major evaluating criteria
Preserving integrity of architectural decisions
Integrating smoothly with development environment,
external components
Other criteria
Consistency, simplicity, uniformity of design decisions
Evaluates all design decisions against these
criteria
102
23 November 2011
Final design task

Add detail to decisions made in central design
tasks
Build procedure
Design procedure for building and installing
intermediate and deployment components

Configuration mgmt
Determine design decisions related to mgmt of
versions and releases of components
103
23 November 2011
Conceptual view: engineering

concerns
System functionality mapped to conceptual
components
Coordination and data exchange handled by
connectors
Independence from SW and HW techniques
Logical flow of control
Concerns
How does system fulfill requirements?
COTS components
Incorporated domain-specific HW/SW
Functionality partitioned into product releases
104
Prior generations of product, future generations

Product lines
Impact of changes in requirements or domain
23 November 2011
Module view: engineering

concerns
Components and connectors mapped into
subsystems and modules

Conceptual solution realized with current SW
and HW technologies and platforms
Concerns
105
How is the product mapped to SW platform?

System support or services used, where?
Testing support
How to minimize dependencies between modules
How to maximize reuse of modules/subsystems
How to protect the product from changes in COTS
SW, SW platform, changes in the standards
23 November 2011
Execution view: engineering

concerns
Modules mapped into runtime platform elements, and
these mapped to HW architecture

Defines the systems runtime entities and their
attributes (memory usage, HW assignment)
Flow of control as seen from the runtime platform
Concerns
How does system meet its performance, recovery,
reconfiguration requirements
Balancing resource usage
Necessary concurrency, replication, distribution w/o adding
much complexity to control algorithms?
Minimize impact of changes in runtime platform
106
23 November 2011
Code view: engineering concerns

Runtime entities mapped to deployment components
(e.g. executables)
Modules mapped to source components
How source components produce deployment
components
Concerns
107
Reduce time and effort for product upgrades

Management of product versions and releases
Reduce build time
Needed tools for development environment
Support for integration and testing
23 November 2011
Use of the four views

Prioritize design decisions and determine
dependencies among them

Result: set of design activities and an order
based on their dependencies
Not all decisions can be made up front
Architect makes the most reasonable decisions
Iterate back to the architecture and make changes
when necessary
108
23 November 2011
Expectations from using the four

views
Tracing influencing factors and requirements
throughout architecture
Sequencing design activities
Making design trade-offs
Supporting system qualities (performance)
Supporting general qualities (buildability)
Ensuring no aspects of architecture are
overlooked
Producing useful documentation of
architecture
109
23 November 2011
Todays takeaway
Another set of views
Derived based on the software architecture of
existing (industrial) systems

How are they compared to Bass et al?
110
24 November 2011
Lecture 7

The ADD method

Bass and all
Hofmeister and all the four views
Today: Evaluating an architecture
29 November 2011
Architectural evaluation - why

Architecture tells about system properties
Effects of design decisions are predictable =>
architecture is analyzable
Architecture drives the software system =>
economic value
Good evaluation methods => low-cost risk
mitigation
Architecture evaluation good to be standard
part of every architecture-based development
method
3
29 November 2011
Architectural evaluation - when

Cost-effective: early in lifecycle
Easier to correct problems
Quality cannot be appended to a system later in lifecycle
Developing architecture
Evaluate taken/under consideration decisions
Choose among alternatives or competing architectures
Other times in lifecycle

Completed architecture: validate it before development
Legacy system under consideration, inherited system, large
software system to be aquired

Rule for when
When development teams start to make decisions based on
the architecture
When the cost of undoing such decisions > evaluation cost
4
29 November 2011
Discovery review
Very early mini-evaluation
Establishes and prioritizes problematic
requirements
Fewer stakeholders
People with decision power on the requirements
Output
Stronger set of requirements
Initial approach to satisfy the requirements
29 November 2011
Architectural evaluation - who

Evaluation team
Stakeholders
Project decision maker
Architect
Component designers
Management
Customer, sponsor (not always)
29 November 2011
Architectural evaluation why

should they believe you?
Evaluators = outsiders
Stakeholders can be
Scared
Skeptical
They are the experts, evaluators cannot teach them about their
system
What to do
Counteract the fear
Purpose is architecture improval, not blame pointing
Counteract the skepticism

Architectural approaches for dealing with/ analyzing QA do not vary
much
Fresh eyes, new perspective
29 November 2011
Results of Architectural evaluation

Concretely: a report
Primarily: information
Is the architecture suitable for the system for which
it was devised?
Which of two competing architectures is most
suitable for the system at hand?
Architecture is suitable if
The system that results from it will meet its quality
goals
The system can be built using the resources at
hand (architecture is buildable)
8
29 November 2011
Architecture suitable with respect to

A system is modifiable or not wrt a specific kind of
change
A system is secure or not wrt a specific kind of
threat
A system is reliable or not wrt a specific kind of
fault occurrence
A system performs well or not wrt specific
performance criteria
An architecture is buildable or not wrt specific
time and budget constraints
29 November 2011
Architectural evaluation - cost

Cost = staff time required of the participants
Aproximative cost for AT&T: 70 staff-days
300 full scale architecture reviews for projects
requiring minimum 700 staff-days

ATAM reviews: about 36 staff-days
For evaluation team
Other stakeholders time counts too
Time included for training the evaluation team!
10
29 November 2011
Architectural evaluation - benefits

Financial
Forced preparation for the review
Captured rationale
Early detection of problems
Validation of requirements
Improved architectures
Overall: increased quality, controlled cost,
decreased budget risk

11
29 November 2011
Architectural evaluation - techniques

Questioning techniques
Rely on thought experiments to check architecture
suitability
Hypothetical architectures too
Scenario-based
ATAM
CBAM
Checklist- or questionaire-based
Measuring techniques
Rely on quantitative measures over existing artifact
Architectural metrics
Simulations, prototypes
12
29 November 2011
ATAM
Architecture Tradeoff Analysis Method
How well an architecture satisfies particular goals?
Provides insight into how quality goals interact, how
they trade off

Has its origins in
SAAM (Software Architecture Analysis Method) from the
early 1990s
Architectural styles
Quality attribute analysis communities
13
29 November 2011
Participants in ATAM
The evaluation team
Project decision makers
Architecture stakeholders
14
29 November 2011
Summary of ATAM
Preparation (presentations)
1. Present the ATAM
2. Present business drivers
3. Present architecture
Investigation and analysis (assessing key QAs)

4. Identify architectural approaches
5. Generate quality attribute utility tree
6. Analyze architectural approaches
Testing (results to date against stakeholders)

7. Brainstorm and prioritize scenarios
8. Analyze architectural approaches
Reporting
16
9. Present the results
29 November 2011
Step 1: present ATAM

Evaluation team leader
ATAM steps in brief
Techniques to be used for elicitation and analysis
Utility tree generation
Architecture-based elicitation and analysis
Scenario brainstorming and prioritization
Outputs of evaluation
Elicited and prioritized scenarios
Questions used to understand and evaluate the architecture
Utility tree of QA
Discovered risks and non-risks
Sensitivity points and tradeoffs
17
29 November 2011
Step 2: Present business goals

Describe
The systems most important functions
Any relevant technical, managerial, economic, or
political constraints
The business goals and context as they relate to
the project
The major stakeholders
The architectural drivers (the major quality attribute
goals)
18
29 November 2011
Business Context/Drivers
Presentation
(~ 12 slides; 45 minutes)
Description of the business environment, history, market
19
differentiators, driving requirements, stakeholders, current need

and how the proposed system will meet those
needs/requirements (3-4 slides)
Description of business constraints (e.g., time to market,
customer demands, standards, cost, etc.) (1-3 slides)
Description of the technical constraints (e.g., COTS,
interoperation with other systems, required hardware or software
platform, reuse of legacy code, etc.) (1-3 slides)
Quality attributes desired (e.g., performance, availability, security,
modifiability, interoperability, integrability) and what business
needs these are derived from (2-3 slides)
Glossary (1 slide)
29 November 2011
Step 3: Present architecture

Driving architectural requirements,
measurable quantities associated with these,

standards/models/approaches for meeting
these
Important architectural information
Context diagram
Module or layer view
Component and connector view
Deployment view
20
29 November 2011
Step 3: Present architecture cont

Architectural approaches, patterns, tactics
employed, what quality attributes they

address and how they address those
attributes
Use of COTS and their integration
Most important use case scenarios
Most important change scenarios
Issues/risks wrt meeting the driving
requirements
21
29 November 2011
Architecture Presentation
(~20 slides; 60 minutes)
Driving architectural requirements (e.g., performance, availability, security, modifiability,

interoperability, integrability), the measurable quantities you associate with these requirements, and
any existing standards/models/approaches for meeting these (2-3 slides)
High Level Architectural Views (4-8 slides)
functional: functions, key system abstractions, domain elements along with their dependencies, data flow
module/layer/subsystem: the subsystems, layers, modules that describe the systems decomposition of
functionality, along with the objects, procedures, functions that populate these and the relations among them
(e.g., procedure call, method invocation, callback, containment).
process/thread: processes, threads along with the synchronization, data flow, and events that connect them
hardware: CPUs, storage, external devices/sensors along with the networks and communication devices that
connect them
Architectural approaches or styles employed, including what quality attributes they address and a
description of how the styles address those attributes (3-6 slides)
Use of COTS and how this is chosen/integrated (1-2 slides)
Trace of 1-3 of the most important use case scenarios. If possible, include the run-time resources
consumed for each scenario (1-3 slides)
Trace of 1-3 of the most important change scenarios. If possible, describe the change impact
(estimated size/difficulty of the change) in terms of the changed components, connectors, or
interfaces. (1-3 slides)
Architectural issues/risks with respect to meeting the driving architectural requirements (2-3 slides)
Glossary (1 slide)
Step 4: identify architectural

approaches
Catalog the evident patterns and approaches
Based on step 3
Serves as the basis for later analysis
23
29 November 2011
Step 5: Generate quality attribute

utility tree
Utility tree
Present the quality attribute goals in detail
Quality attribute goals are
Identified, prioritized, refined
Expressed as scenarios
Utility is an expression of the overall
goodness of the system

Quality attributes form the second level being
components of utility
24
29 November 2011
Step 5: Generate quality attribute

utility tree cont
Scenarios are prioritized
Depending on how important they are and
Depending on how difficult it will be for the
architecture to satisfy a scenario
25
29 November 2011
26
29 November 2011
Step 6: Analyze architectural

approaches
Examine the highest ranked scenarios
The goal is for the evaluation team to be
convinced that the approach is appropriate for

meeting the attribute-specific requirements
Scenario walkthroughs
Identify and record a set of sensitivity points
and tradeoff points, risks and non-risks
Sensitivity and tradeoff points are candidate risks
27
29 November 2011
Step 6 outputs
Architectural approaches relevant to each high-
priority utility tree scenario

Analysis questions associated with each
approach
Pointed to the QA associated to the scenario
The architects responses to the questions

Risks, non-risks, sensitivity points, tradeoffs
associated with the achievement of one/more QA

wrt the QA questions that probed the risk
28
29 November 2011
More on Step 6
Utility tree shows how to probe the architecture
Architect responds with the architectural approach
that answers this need

Evaluation team can use the QA-specific questions to
probe the approach more deeply
The QA-specific questions help team to
Understand the approach in detail and how it was
applied in the instance

Look for well-known weaknesses with the approach
Look for the approachs sensitivity and tradeoff points
Find interactions and tradeoffs with other approaches
29
29 November 2011
Step 7: Brainstorm and prioritize

scenarios
Utility tree shows the architects view on the quality
attributes
Here the focus is on the other stakeholders view on
the quality attributes and scenarios based on these
Which are the most meaningful and important
scenarios wrt users etc.

Scenario brainstorming works well in larger groups
The prioritized list of scenarios compared to utility
tree scenarios
31
29 November 2011
Step 7: Brainstormed scenarios

Use case scenarios
How stakeholders expect system to be used
Growth scenarios
How the architecture is expected to accommodate growth
and change
Expected modifications, changes in performance or availability,
porting to other platforms, integration with other software
Exploratory scenarios
Extreme forms of growth, how the architecture might be
stressed by changes
Dramatic new performance or availability requirements, major
changes in infrastructure or system mission

32
29 November 2011
Step 7: Prioritizing scenarios

First stakeholders merge scenarios they believe
represents the same behaviour / QA concern

Then stakeholders vote on scenarios they believe
are most important
Each stakeholder gets a number of votes equal to
30% of the number of scenarios rounded up

Then they vote in any way
Vote is public
Evaluation leader sorts the scenarios, detects the
sharp drop-off in number of votes, and draws the
line there
33
29 November 2011
Vehicle dispatching system exp

4. Dynamically replan a dispatched mission within 10
minutes. [28]
27. Split the management of a set of vehicles across
multiple control sites. [26]
10. Change vendor analysis tools after mission has
commenced without restarting system. [23]
12. Retarget a collection of diverse vehicles to handle an
emergency situation in less than 10 seconds after
commands are issued. [13]
14. Change the data distribution mechanism from CORBA
to a new emerging standard with less than six personmonths effort. [12]
34
29 November 2011
Highly ranked scenarios with QA

annotations
35
Scenario
#Votes
Quality Attributes
28
Performance
27
26
Performance,
Modifiability,
Availability
10
23
Integrability
12
13
Performance
14
12
Modifiability
29 November 2011
Step 7: Comparison
Scenario prioritization compared to utility tree
Agreement or disagreement
Each high-priority brainstormed scenario is placed in
appropriate leaf node in utility tree

Prior to this, identify the QAs the scenario addresses
When brainstormed scenario placed in utility tree:

Scenario matches and duplicates already existing leaf
node
Scenario goes onto a new leaf of existing branch
Scenario fits in no branch of the tree (QA not previously
accounted for)
36
29 November 2011
Utility tree vs Scenario Brainstorming
37
Utility trees
Scenario Brainstorming
Stakeholders
Architects, project leader
All stakeholders
Typical group size
Evaluators, 2-3 project personnel
Evaluators, 5-10 project related

personnel
Primary goals
Elicit, make concrete and prioritize Foster stakeholder communication to

the driving QA; provide focus for validate QA goals elicited via utility
the rest of the evaluation
tree
Approach
General to specific; begin with

QA, refine until scenarios emerge
Specific to general; begin with

scenarios, then identify QAs they
express
29 November 2011
Stakeholders and Architect

Architect should be present at evaluation!
Cannot identify architect: trouble
Architect sees all stakeholders together, important
step
Architect takes items to work on from evaluation
Has to present the architecture
Identify kinds of stakeholders and names!
Evaluators suggests kinds
Client provides names
38
29 November 2011
Step 8: Analyze architectural

approaches
Highest ranked scenarios from step 7 are
presented to the architect

Architect explains how relevant architectural
decisions contribute to realizing each one

Previously discussed architectural approaches
should come in here
Same activities as in Step 6
Ideally: just testing
If step 7 did not produce any high-priority scenarios
not already covered

39
29 November 2011
Step 9: Present results

Verbal report and slides
Written report
Outputs:
The architectural approaches documented
The set of scenarios and their prioritization from the
brainstorming
The utility tree
The risks discovered
The non-risks documented
The sensitivity points and tradeoff points found
40
29 November 2011
Step 9: Risk themes

Risks can be grouped together based on some
common underlying concern, systemic deficiency

Exp
Documentation given insufficient consideration
Inadequate doc
Out-of-date doc
Insufficient attention to backup capability or
provision of high availability

System cannot function when various SW/HW fails
Risk theme <-> affected business drivers

Closure and risks pointed out to management
41
29 November 2011
Outputs of the ATAM

A concise presentation of the architecture
Articulation of the business goals
Quality requirements in terms of a collection
of scenarios
Mapping of architectural decisions to quality
requirements
A set of identified sensitivity and tradeoff
points
A set of risks and non-risks
A set of risk themes
42
29 November 2011
Other outputs
Secondary outputs
Architecture representation survives evaluation
Scenarios too
Analysis can serve as statement of rationale for
architectural decisions
Made or not
Mitigation strategies
Intangible goals
Social, community sense
Better communication
Improved understanding
43
29 November 2011
Phases of the ATAM

Phase 0
Partnership and preparation
Phase 1
Evaluation, architecture-centric
Phase 2
Evaluation continued, stakeholders-centric
Phase 3
Follow-up
44
29 November 2011
Steps of evaluation phase 1

Step 1
Present the ATAM
Step 2
Present business drivers
Step 3
Present architecture
Step 4
Identify architectural approaches
Step 5
Generate quality attribute utility tree
Step 6
Analyze architectural approaches
45
29 November 2011
Steps of evaluation phase 2

Step 7
Brainstorm and prioritize scenarios
Step 8
Analyze architectural approaches
Step 9
Present results
46
29 November 2011
Other methods
CBAM
Cost-Based Analysis Method
Uses ATAM
Measuring technics
Answer specific questions about specific qualities
Need the presence of a design/implementation
artifact (the object to measure)

RMA rate monotonic analysis: quantitative
technique for ensuring that a set of fixed-priority
processes can be scheduled on a CPU
Can be performed as architecture is being evolved
ADL, formal notations and languages

47
29 November 2011
CBAM
Biggest trade-offs influence economics
Resources
Earlier: costs
Of building system, not long term
Now also: benefits

Economic models needed
Consider costs, benefits, risks, schedule
implications
Basic idea of CBAM
Architectural strategies quality attributes
benefits for stakeholders (utilities)

48
29 November 2011
CBAM Utilities
Architectural strategy
Provides specific level of utility to stakeholders
Has cost
Takes time to implement
Return On Investment (ROI)

Ratio of benefit to cost
Utility-response curves
Depicts how the utility derived from a particular response
varies as the response varies

Best-case, worst-case, current-case, desired-case
response
interpolation
Side effects
49
29 November 2011
Some formulas
Overal utility of architectural strategy across scenarios
Strategy i
Scenario j
Benefit Bi
Benefit bi,j
Weight Wj
Utility U
Return over investment Ri, cost Ci
Bi = j (bi,j Wj)
bi,j = Uexpected-Ucurrent
Ri = Bi/Ci
50
29 November 2011
Properties of successful evalution

Clear goals and requirements for architecture
Controlled scope
Cost-effectiveness
Key personnel availability
Competent evaluation team
Managed expectations
Final report
51
29 November 2011
Lecture 8

The ADD method

Bass and all
Hofmeister and all
Evaluating an architecture
Today: ADLs and short discussion of formal approaches to
architectures
1.12.2011
Linguistic character of architectural

description
Common patterns in different architectures
common kinds of elements
common inter-module connection strategies
Languages describe complex relations among
primitive elements and combinations of these

Semantic constructs
=> There is an appropriate linguistic basis in
architectural descriptions
1.12.2011
Common patterns of SW organization

SA description often
Box-and-line diagrams
boxes major components
lines communication, control, data relation
Boxes and lines may mean different things
For different described systems
For different people
Supplemented with prose, no precise meaning
Informal terms
Still useful
1.12.2011
Usage of common patterns

Informal terms
Often refer to common patterns used to organize
the system
Used among SW engineers in high-level
descriptions of designs
More precise definitions of these
(would be) Beneficial for SW developers
In the forms in which they appear
In the classes of functionality and interaction they provide
1.12.2011
Common component classes

(pure) Computation
Simple input/output relations, no retained state
Exp: Math functions, filters, transforms
Memory
Shared collection of persistent structured data
Exp: Database, file system, symbol table, hypertext
Manager
State and closely related operations
Exp: Abstract data type, servers
Controller
Governs time sequences of others events
Exp: Scheduler, synchronizer
Link
Transmits information between entities
Exp: Communication link, user interface
1.12.2011
Common interactions among components
Procedure call
Single thread of control passes among definitions
Exp: Ordinary procedure call, remote procedure call
Dataflow
Independent processes interact through streams of data
Exp: Unix pipes
Implicit invocation
Computation is invoked by the occurrence of an event; no explicit interactions among
processes
Exp: Event systems, automatic garbage collection
Message passing
Independent processes interact by explicit, discrete hand-off of data; may be synchronous or
asynchronous
Exp: TCP/IP
Shared data
Components operate concurrently (probably with provisions for atomicity) on the same data
space
Exp: Blackboard systems, multiuser databases
Instantiation
Instantiator uses capabilities of instantiated definition by providing space for state required by
instance
Exp: using abstract data types
7
1.12.2011
Critical elements of a design language

A (programming) language requires
Components
Primitive semantic elements and their values
Exp: integers, floating-point numbers, strings, records, arrays
Operators
Functions that combine components
Exp: iteration, conditional constructs, +,-,*,/
Abstraction
Rules for naming expressions of components and operators
Exp: definition of macros and procedures
Closure
Rules to determine which abstractions can be added to the
classes of primitive components and operators
Exp: procedures or user-defined types - first class entities
Specification
Association of semantics to the syntactic form
Formal, informal (in reference manual)
8
1.12.2011
The language problem for SA

SA deals with
Allocation of functionality to components
Data and communication connectivity
Quality attributes and system balance
Quite different from the (conventional)
programming language concerns

Specific forms of the various language elements are
also different
1.12.2011
Critical elements of a SA design language

Components
Module-level elements; component classes listed before
Operators
Interaction mechanisms as listed before
Patterns/ abstraction
Compositions in which code elements are connected in a
particular way; Exp: client-server relation
Closure
Conditions in which composition can serve as a subsystem in
development of larger systems
Specification
Not only of functionality, but also of quality attributes
10
1.12.2011
Implication of the critical elements

Basis for designing ADLs provided by
Identification of architectural components
Identification of architectural techniques, for
combining them into subsystems and systems
Such a language would support
Simple expressions of connections among simple
modules, plus
Subsystems
Configurations of subsystems into systems
Common paradigms for such combinations
Expression of quality attributes and functional
properties
11
1.12.2011
Requirements for ADLs

1. To provide models, notations, tools to
2.
3.
4.
5.
6.
12
describe architectural components and their

interactions
To handle large-scale, high-level designs
To support the adaptation of designs to
specific implementations
To support user-defined abstractions
To support application-specific abstractions
To support the principled selection of
architectural paradigms
1.12.2011
ADL and environment

Close relation between ADL and its
environment
ADL: precise descriptions
Environment: (re)uses the descriptions
Ideal ADL should support

Composition
Abstraction
Reusability
Configuration
Heterogeneity
Analysis
13
1.12.2011
Composition
Describe a system as composition of
independent components and connections

Aspects
Divide a complex system (hierarchically) into
smaller parts
Assemble a large system from constituent elements
Independent elements
Can be understood in isolation from the system
Separate issues of implementation-level from those
of architectural level
14
1.12.2011
Composition, 2
Another name: modularity
Closure rule: can see entities as both primitives
and composites
At different levels of abstraction
Independence rule: can reuse parts of a
composite
15
1.12.2011
Composition, 3
Need for explicit and abstract composition rules
Pipe and filter
Sequence of pipes and filters
Layered systems
Collection of abstract layers interacting according to
certain rules
Filter can internally be decomposed in
Another pipe and filter system
Instance of something else
Filter may be used in any data stream transformation
system
Pipe may be used for any data transmission
16
1.12.2011
Abstraction
Allows to describe the abstract roles of elements and
their interaction within SA at a level well understood by

designers
Clearly
Explicitly
Intuition
Suppress unneeded detail but reveal important
properties
high-level pgm languages, register usage suppressed,
17
sequential control flow abstractions revealed

Interface: suppresses implementation issues, reveals use
dependencies
1.12.2011
Abstraction, 2
Necessary to represent new architectural patterns
and new forms of interaction between them as

first class abstractions
Architectural level of design
Different form of abstraction, to reveal high-level
structure
Distinct roles of each element in the high-level
structure are clear
Example: client-server relationship
18
1.12.2011
Reusability
Reuse components, connectors, architectural styles in
different architectural descriptions

Reuse generic patterns of components and
connectors
Families of SA as open-ended sets of architectural
elements
Structural and semantic constraints
Differs with respect to reusing components from libraries
Those are completely closed / parameterized components, retain
identities, are leaves of is-composed-of system structure

Reusing generic patterns of components and connectors: further
instantiation, indefinite replication of relations, structured
collections of internal nodes
19
1.12.2011
Reusability, 2
Systems rarely conceived in isolation
Instances of a family of similar systems that share
many architectural properties

Shared properties
Structural: specific topology of component and connectors
Constraints on using certain architectural elements
20
1.12.2011
Configuration
Architectural descriptions should localize the
description of system structure

Independently of the elements being structured
Dynamic reconfiguration permissible
Evolvability
Create/remove components, interactions initiated
Allows to understand and change architectural
structure
Without examining individual components
ADL: should separate descriptions of compositions from
those of elements
Reason about composition as a whole
21
1.12.2011
Heterogeneity
Combine multiple, heterogeneous architectural
descriptions
Ability to combine different architectural styles in a
single system
Component A communicates with component B via a pipe, but
also accesses a shared database with a query

Different levels of architectural description should be allowed to
use different architectural idioms
Ability to combine components written in different
languages
Architectural description is at a higher level of abstraction than
the algorithms and data structures used for implementation

22
1.12.2011
Analysis
Possible to perform rich and varied analyses
of architectural descriptions
Each style facilitates a certain type of properties
Pipe and filter: possible to analyze throughput, investigate
deadlock and resource usage, deduce the system I/O
behavior from that of the filters
Should be possible to tailor special purpose analysis tools
to architecture types
Automated and non-automated reasoning about
architectural descriptions
23
1.12.2011
Analysis, 2
Important for architectural formalisms
Many of the interesting architectural properties are
dynamic
Exp
If connector associated with protocol, is the use of connector
correct in its context?

Timing, performance, resource usage may aid in reasoning if SA
adequate
Variety of analyses => no single semantic framework
will be enough
Should be possible to associate specifications with
24
architectures as they become relevant to particular

components, connectors, styles
1.12.2011
First-class connectors
SA treats SW systems as composition of
components
Focus on components
Description of interactions among components is
implicit, distributed, hard to identify

When interfaces explicit: import/export lists of data
and procedures
Implicit interactions: include files
=> Info organized around components, significance of
interactions, connections is ignored
25
1.12.2011
Problems with this practice

1. Inability to localize info about interactions
2. Poor abstractions
3. Lack of structure on interface definitions
4. Mixed concerns in programming language
specification
5. Poor support for components with
incompatible packaging
6. Poor support for multi-language or multiparadigm systems
7. Poor support for legacy systems
26
1.12.2011
Fresh view of software system

composition
Systems composed of identifiable
components of various distinct types

These interact in identifiable, distinct ways
Correspond to compilation units (roughly)
Connectors mediate interactions among
components
Establish rules that govern component interaction
Specify any auxiliary mechanisms required
Do not correspond to compilation units
27
1.12.2011
Connectors
Manifest as
Table entries
Instructions to a linker
Dynamic data structures
System calls
Initialization parameters
Servers with multiple independent connections
Define a set of roles that specific named
entities of the components must play
28
1.12.2011
Connectors, 2
Place of relations among components
Mediate interactions
Have protocol specifications defining their properties
Rules about types of interfaces they are able to mediate for
Assurances about properties of interactions
Rules about order in which things happen
Commitments about interaction (ordering, performance, etc)
Are of some type/subtype
Roles to be satisfied: specific, visible named entities
in the protocol of a connector
29
1.12.2011
Components
Place of computation and state
Have interfaces specifying their properties
Signatures
Functionality of resources
Global relations
Performance properties
Are of some type/subtype

Interface points: specific, visible named entities in
the interface of a component
30
1.12.2011
Primitive vs composite: components

Primitive components coded in the programming
language
Composite components define configurations in
independent notation
Constituent components and connectors identified
Match connection points of components with roles
of connectors
Check integrity of the above
31
1.12.2011
Primitive vs composite:
connectors
Of different kinds
Shared data representations

Remote procedure calls
Dataflow
Document-exchange standards
Standardized network protocols
Rich enough set to require taxonomy to show
relations among similar connector kinds
32
1.12.2011
Primitive connectors
Built-in mechanisms of programming languages
System functions of the OS
Shared data
Entries in task/routing tables
Interchange formats for static data
Initialization parameters
etc
33
1.12.2011
Summing up principles for ADL

Purpose: define roles and relationships instead of algorithms and
data structures
Must support
System configuration
Independence of entities (reusability)
Abstraction
Analysis of functional properties and QA
Has syntax and

Defines semantics for connectors and their compositions
Generalize from import/export rules to rules with symmetry,
multiplicity, abstraction, locality, naming

Defines type structures for system organizations, components,
connectors, primitive units of associations of these
Sets out appropriate rules for architectural abstractions
34
1.12.2011
Large grained structure of ADL
35
Component
Connector
Interface
Component type
Player
Implementation
Protocol
Connector type
Role
Implementation
1.12.2011
On ADL structure
Specify whether element primitive
Not further defined at architectural level, but
implemented in a programming language

Non-primitive element
Implementation: list of parts, composition
instructions, related specs => no more name

matching
36
1.12.2011
Architecture Description
Languages
The positives
ADLs provide a formal way of representing architecture
ADLs are intended to be both human and machine readable
ADLs support describing a system at a higher level than previously
possible
ADLs permit analysis of architectures completeness, consistency,
ambiguity, and performance
ADLs can support automatic generation of software systems
The negatives
There is no universal agreement on what ADLs should represent,
particularly wrt the behavior of the architecture
Representations currently in use are relatively difficult to parse and
are not supported by commercial tools
Most ADL work today has been undertaken with academic rather than
commercial goals in mind
Most ADLs tend to be very vertically optimized toward a particular
kind of analysis
37
1.12.2011
Software Architecture: ADL

Perspective
The ADL community generally agrees that Software Architecture
is a set of components and the connections among them.

components
connectors
configurations
constraints
38
1.12.2011
ADLs
Leading candidates
ACME (CMU/USC)
Rapide (Stanford)
Wright (CMU)
Unicon (CMU)
Secondary candidates
Aesop (CMU)
MetaH (Honeywell)
C2 SADL (UCI)
SADL (SRI)
Others
Lileanna
UML
Modechart
39
1.12.2011
ACME
Acme was developed jointly by Monroe, Garlan (CMU) and Wile
(USC)
Acme is a general purpose ADL originally designed to be a lowest
common denominator interchange language
Now
common interchange format for architecture design tools
foundation for developing new architectural design and analysis tools
simple architectural descriptions
Acme language and Acme Tool Developer's Library (AcmeLib)

provide a generic, extensible infrastructure for describing, representing,
generating, and analyzing software architecture descriptions
40
1.12.2011
An ADL Example (in ACME)

System simple_cs = {
Component client = {Port send-request}
Component server = {Port receive-request}
Connector rpc = {Roles {caller, callee}}
Attachments : {client.send-request to rpc.caller;
server.receive-request to rpc.callee}
}
rpc
client
send-request
41
caller
callee
server
receive-request
1.12.2011
Rapide
Developed by David Luckham, Stanford
General purpose ADL designed with an emphasis on simulation
42
yielding partially ordered sets of events (posets)

Fairly sophisticated, including data types and operations
Rapide analysis tools focus on posets
matching simulation results against patterns of
allowed/prohibited behaviors
some support for timing analysis
focus on causality
Rapide has some generation capability since Rapide
specifications are executable
Rapide has a fairly extensive toolset
1.12.2011
The Rapide Model

Concurrent, object-oriented, event-based simulation
43
language
Defines and simulates behavior of distributed object
system architectures
Produces a simulation represented by a set of events
(poset)
Events are ordered with respect to time and
causality
System requirements are expressed as constraints on
time and concurrent patterns of events
Posets enable visualization and analysis of an
execution
1.12.2011
Rapide Architectural Elements

Components
components
Architecture
connections
constraints
Components
interface
interface
Component
architecture
interface
module
44
1.12.2011
Rapide Architectural Elements, 2

Components
Interface objects
Architecture that implements an interface
Module that implements an interface
Connections
Connects sending interfaces to receiving interfaces
Components communicate through connections by calling
actions or functions in their own interface

Events generated by components trigger event pattern
connections between their interfaces
Three types of connections:
Basic connections
Pipe connections
Agent connections
45
1.12.2011
Architectural Elements (contd)

Components
provides
part
requires part
Interface
Components
action part
in actions
out actions
service part
state
Components
behavior
part
state transitions
constraint part
pattern constraints
Components
private part
46
functions
objects
types
interface with no
private part
1.12.2011
A Simple Specification in Rapide

type Producer (Max : Positive) is interface
action out Send (N: Integer);
action in Reply(N : Integer);
behavior
Start => send(0);
(?X in Integer) Reply(?X) where ?X<Max => Send(?X+1);
end Producer;
type Consumer is interface
action in Receive(N: Integer);
action out Ack(N : Integer);
behavior
(?X in Integer) Receive(?X) => Ack(?X);
end Consumer
architecture ProdCon() return SomeType is
Prod : Producer(100); Cons : Consumer;
connect
(?n in Integer) Prod.Send(?n) => Cons.Receive(?n);
Cons.Ack(?n) => Prod.Reply(?n);
end architecture ProdCon;
47
1.12.2011
Wright
Developed by David Garlan at CMU
Wright is a general purpose ADL designed with an emphasis on
analysis of communication protocols

Uses a variation of CSP to specify the behaviors of components,
connectors, and systems
CSP - Communicating Sequential Processes, process algebra
developed by C. A. R. Hoare
Focuses primarily on the basic component/connector/system
paradigm
Similar syntactically to ACME and Aesop
Wright analysis focuses on analyzing the CSP behavior
specifications.
Any CSP analysis tool or technique could be used to analyze the
behavior of a Wright specification
Wright does not currently have a generation capability
Wright has minimal native tool support (but CSP tools could be used)
A Simple Specification in Wright

System simple_cs
Component client =
port send-request = [behavioral spec]
spec = [behavioral spec]
Component server =
port receive-request= [behavioral spec]
spec = [behavioral spec]
Connector rpc =
role caller = (request!x -> result?x ->caller) ^ STOP
role callee = (invoke?x -> return!x -> callee) [] STOP
glue = (caller.request?x -> callee.invoke!x
-> callee.return?x -> callee.result!x
-> glue) [] STOP
Instances
s : server
c : client
r : rpc
Attachments :
client.send-request as rpc.caller
server.receive-request as rpc.callee
end simple_cs.
49
1.12.2011
UML as an ADL
The Positive
lowers entry barrier, mainstreams modeling, tools
Shortcomings of UML as an ADL

Weakly integrated models with inadequate
semantics for (automated) analysis

Connectors are not first class objects
Visual notation with little generation support, hidden
and ambiguous relationships between views, both
too much and too little
50
1.12.2011
Hence
There is a rich body of research to draw upon
Much has been learned about representing and
analyzing architectures
Effort is needed now to bring together the
common knowledge and put it into practice
51
1.12.2011
For More Information

ACME: http://www.cs.cmu.edu/~acme
Rapide: http://pavg.stanford.edu/rapide/
Wright:
52
http://www.cs.cmu.edu/afs/cs/project/able/www/wright/index.html
Aesop:
http://www.cs.cmu.edu/afs/cs/project/able/www/aesop/aesop_ho
me.html
Unicon:
http://www.cs.cmu.edu/afs/cs/project/vit/www/unicon/index.html
C2 SADL: http://www.ics.uci.edu/pub/arch/
SSEP: http://www.mcc.com/projects/ssepp
ADML: http://www.mcc.com/projects/ssepp/adml
1.12.2011
Formalisms
Formal models and techniques are
cornerstones of a mature engineering

discipline
Engineering disciplines used models and
techniques in different ways
Provide precise, abstract models
Provide analytical techniques based on models
Provide design notations
Provide basis for simulations
53
1.12.2011
What to formalize?
Architecture of a specific system
Allow the architect to plan a specific system
Becomes part of the specification of the system
Augments the informal characteristics of the SA
Permits specific analyses of the system
54
1.12.2011
What to formalize?
Architectural style
Describe architectural abstractions for families of
systems
Purposes:
Make common idioms, patterns and reference architectures
precise
Show precisely how different architectural representations
can be treated as specializations of some common
abstraction
55
1.12.2011
What to formalize
Theory of software architecture
Clarify the meaning of generic architectural
concepts
Architectural connection, hierarchical architectural
representation, architectural style
Provide deductive basis for analyzing systems at an
architectural level
Might provide rules for determining when an architectural
description is well formed

Compositionality
56
1.12.2011
What to formalize
Formal semantics of ADL:s
Architectural description is a language issue
Apply traditional techniques for representing
semantics of languages
57
1.12.2011
Todays takeaway
SA has a linguistic character
Programming languages are useful for
comparison
Connectors are needed in addition to
components
ADLs may grow in the future
58
1.12.2011

Software Architectures 456502.0

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Software Architectures 456502.0

Transféré par

Droits d'auteur :

Formats disponibles

Software Architectures

This course at:

@ Alpha Auditorium, during 12-16

Software Architectures, Lecture 1

Software Architectures, Lecture 1

Architecture, Addison-Wesley, 2000.

Software Architectures, Lecture 1

Software Architectures, Lecture 1

Our society runs on Software

Software Architectures, Lecture 1

What does SA address?

Software Architectures, Lecture 1

Producing software systems

implement the software quickly, cheaply

New criterion: does it have a good SA, understood

by stakeholders and developers?

Software Architectures, Lecture 1

Provides a design plan of a system

Is an abstraction that helps in managing the

Software architects limited by

architecture will result in an implementation that

Software Architectures, Lecture 1

Software Architectures, Lecture 1

the project plan

Software Architectures, Lecture 1

encapsulated into elements of the SA

Software Architectures, Lecture 1

Software Architectures, Lecture 1

architecture, it meets its requirements and resource

Software Architectures, Lecture 1

Reference/domain specific architecture

Defines element types and how they interact

Software Architectures, Lecture 1

Applies to a set of products within a company

E.g., error-reporting components would be common to

Software Architectures, Lecture 1

Applies to one system

Software Architectures, Lecture 1

Gives notation for architectural elements

As types and instances, also interconnecting instances

Mostly in research communities

Software Architectures, Lecture 1

architectures, as well as design them

Software Architectures, Lecture 1

Contents of this course

L4: Creating an architecture

L7: Analysing and evaluating an architecture

L9: Product lines, COTS, Software architects

Software Architectures, Lecture 1

The ABC cycle

This is the ABC cycle of influences: Architecture

systems future new organizational goals

Software Architectures, Lecture 1

Software Architectures, Lecture 1

The business considerations

Such qualities are non-functional

Software Architectures, Lecture 1

Functionality: the ability of the system to do the

work for which it was intended

Software Architectures, Lecture 1

Architecture and quality attributes

Software Architectures, Lecture 1

Software Architectures, Lecture 1

Software Architectures, Lecture 1