صفحه 1:
Analysis of
Software Architectures
Copyright © Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy. All rights reser
صفحه 2:
What Is Architectural Analysis?
e Architectural analysis is the activity of
discovering important system properties
using the system’s architectural models.
Early, useful answers about relevant
architectural aspects
Available prior to system’s construction
e Important to know
which questions to ask
why to ask them
how to ask them
how to ensure that they can be answered
صفحه 3:
Informal Architectural Models
and Analysis
» Helps architects
get clarification
from system
customers
© Helps managers
ensure project
scope
« Not as useful to
developers
صفحه 4:
Formal Architectural Models and
Analysis
Component Userinterface ® Helps architects
Port getValues determing
Port calculate component
Computation 5
Connector Call composability
Role Caller = ° Helps developers
Role Callee = with
es implementation-
Configuration Lunartander levalidecisions
Instances :
DS : 6 © Helps with
C : Calculation locating and
تلا : ۵ selectin
CtoUIgetValues, CtoUIstoreValues, UItoC, UItoDS : Call] appropriate OTS
‘Attachments components
C.getValues as CtoUIgetValues.Caller % Helos with
DS.getValues as CtoUIgetValues .Callee lelps wii
C.storeValues as CtoUIstoreValues. Caller automated code
DS.storeValues as CtoUIstoreValues.Callee generation
UI.calculate as UItoC.Caller © Not as useful for
C.calulate as UItoC.Callee i 1 it
bi-getvatues as Utobe Caller discussions with
DS.getValues as UItoDS.Callee eeikenolders
End Lunarlander.
صفحه 5:
Ane مت یت شم نت
Concerns Relevant to
Architectural Analysis
Goals of analysis
Scope of analysis
Primary architectural concern being analyzed
Level of formality of architectural models
Type of analysis
Level of automation
System stakeholders interested in analysis
صفحه 6:
۱
Architectural Analysis Goals
© The four 5
* Completeness
* Consistency
* Compatibility
* Correctness
صفحه 7:
Architectural Analysis Goals -
Completeness
© Completeness is both an external and an internal
goal
© It is externa/ with respect to system requirements
* Challenged by the complexity of large systems’
requirements and architectures
* Challenged by the many notations used to
capture complex requirements as well as
architectures
® It is internal with respect to the architectural
intent and modeling notation
* Have all elements been fully modeled in the
notation?
Have all design decisions been properly
captured?
صفحه 8:
Ane مت یت شم نت
Architectural Analysis Goals -
Consistency
® Consistency is an internal property of an
architectural model
© Ensures that different model elements do not
contradict one another
© Dimensions of architectural consistency
* Name
* Interface
Behavior
* Interaction
* Refinement
صفحه 9:
me Consistency
© Component and connector names
© Component service names
eM
ay be non-trivial to establish at the architectural
vel
Multiple system elements/services with
identical names
Na
le
* Loose coupling via publish-subscribe or
asynchronous event broadcast
* Dynamically adaptable architectures
صفحه 10:
Interface Consistency
Encompasses name consistency
Also involves parameter lists in component services
Arich spectrum of choices at the architectural level
Example: matching provided and required interfaces
ReqInt: getSubQ(Natural first, Natural last, Boolean remove)
returns FIFOQueue;
ProvInt1: getSubQ(Index first, Index last)
returns FIFOQQueue;
ProvInt2: getSubQ(Natural first, Natural last, Boolean remove)
returns Queue;
صفحه 11:
Behavioral Consistency
Names and interfaces of interacting components may
match, but behaviors need not
Example: subtraction
subtract (Integer x, Integer y) returns Integer;
Can we be sure what the subtract operation does?
Example: QueueClient and QueueServer components
QueueClient - getFront
precondition q.size > 0;
postcondition ~q.size = q.size;
QueueServer - getFront
precondition q.size > 1;
postcondition ~q.size = q.size - 1;
صفحه 12:
a Keg
Interaction Consistency
©» Names, interfaces, and behaviors of interacting
components may match, yet they may still be
unable to interact properly
© Example: QueueClient and QueueServer
a... be
صفحه 13:
Refinement Consistency
e Architectural models are refined during the
design process
© Arelationship must be maintained between
higher and lower level models
* All elements are preserved in the lower level
model
* All design decisions are preserved in the lower-
level model
* No new design decisions violate existing design
decisions
صفحه 14:
Ane مت یت شم نت
Refinement Consistency Example
صفحه 15:
Ane مت یت شم نت
Architectural Analysis Goals -
Compatibility
© Compatibility is an external property of an
architectural model
© Ensures that the architectural model adheres to
guidelines and constraints of
* astyle
* areference architecture
* an architectural standard
صفحه 16:
Architectural Compatibility Example -
Lunar Lander
© What is the style of this architecture?
Space
صفحه 17:
Architectural Analysis Goals -
Correctness
Correctness is an external property of an architectural و
model
» Ensures that
the architectural model fully realizes a system
specification
the system's implementation fully realizes the
architecture
» Inclusion of OTS elements impacts correctness
System may include structural elements,
functionality, and non-functional properties that are
not part of the architecture
The notion of fu/fillment is key to ensuring
architectural correctness
صفحه 18:
a Keg
Scope of Architectural Analysis
© Component- and connector-level
© Subsystem- and system-level
Beware of the “honey-baked ham” syndrome
و Data exchanged in a system or subsystem
Data structure
Data flow
* Properties of data exchange
* Architectures at different abstraction levels
» Comparison of two or more architectures
Processing
* Data
Interaction
Configuration
Non-functional properties
صفحه 19:
Ane مت یت شم نت
Data Exchange Example
صفحه 20:
a Keg
مت یت شم نت
Architectures at Different Abstraction
011 ۱۵/۱2 1
613۱/۱4 2
ل سم
0312 2
02
C4
5
Levels
01
C3 >)
صفحه 21:
Ane مت یت شم نت
Architectural Concern Being
Analyzed
© Structural characteristics
© Behavioral characteristics
© Interaction characteristics
® Non-functional characteristics
صفحه 22:
۱
ل ۶ ۱۵۷۵۱
© Informal models
© Semi-formal models
© Formal models
صفحه 23:
a Keg
Type of Analysis
© Static analysis
» Dynamic analysis
© Scenario-driven analysis
* Can be both static and dynamic
صفحه 24:
a Keg
Level of Automation
» Manual
® Partially automated
° Fully automated
صفحه 25:
۱
Analysis Stakeholders
© Architects
© Developers
« 5
© Customers
° Vendors
صفحه 26:
Architectural Analysis in a
Nutchall
‘Architectural
Analysis,
|— Goats |-— Models
Completeness Informal
| — consistency | Semi-formal
Name Formal
Interface Type
|— Behavior Static
Interaction | bynamic
Refinement ‘Sconario-based
| — compativitiy Automation Level
Correctness Manual
[| scope Paricly automated
Component. and connector evel Automated
Subsystem. and system-level Stakeholders
Data exchange Architects
| — pitferent abstraction levels | Developers
‘Architecture comparison Managers
| — concerns Customers
Structural Vendors
Behavioral
Interaction
Nonfunctional
Analysis of
Software Architectures
Copyright © Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy. All rights reserv
Software Architecture
Foundations, Theory, and Practice
What Is Architectural Analysis?
Architectural analysis is the activity of
discovering important system properties
using the system’s architectural models.
Early, useful answers about relevant
architectural aspects
Available prior to system’s construction
Important to know
1. which questions to ask
2. why to ask them
3. how to ask them
4. how to ensure that they can be answered
2
Software Architecture
Foundations, Theory, and Practice
Informal Architectural Models
and Analysis
Helps architects
get clarification
from system
customers
Helps managers
ensure project
scope
Not as useful to
developers
3
Software Architecture: Foundations, Theory, and Practice ; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.
Software Architecture
Foundations, Theory, and Practice
Formal Architectural Models and
Analysis
Component UserInterface
Port getValues
Port calculate
Computation
Connector Call
Role Caller =
Role Callee =
Glue =
Configuration LunarLander
Instances
DS : DataStore
C : Calculation
UI : UserInterface
CtoUIgetValues, CtoUIstoreValues, UItoC, UItoDS : Call
Attachments
C.getValues as CtoUIgetValues.Caller
DS.getValues as CtoUIgetValues.Callee
C.storeValues as CtoUIstoreValues.Caller
DS.storeValues as CtoUIstoreValues.Callee
UI.calculate as UItoC.Caller
C.calulate as UItoC.Callee
UI.getValues as UItoDS.Caller
DS.getValues as UItoDS.Callee
End LunarLander.
Helps architects
determine
component
composability
Helps developers
with
implementationlevel decisions
Helps with
locating and
selecting
appropriate OTS
components
Helps with
automated code
generation
Not as useful for
discussions with
non-technical
stakeholders
Software Architecture: Foundations, Theory, and Practice ; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.
4
Software Architecture
Foundations, Theory, and Practice
Concerns Relevant to
Architectural Analysis
Goals of analysis
Scope of analysis
Primary architectural concern being analyzed
Level of formality of architectural models
Type of analysis
Level of automation
System stakeholders interested in analysis
5
Software Architecture
Foundations, Theory, and Practice
Architectural Analysis Goals
The four “C”s
Completeness
Consistency
Compatibility
Correctness
6
Software Architecture
Foundations, Theory, and Practice
Architectural Analysis Goals –
Completeness
Completeness is both an external and an internal
goal
It is external with respect to system requirements
Challenged by the complexity of large systems’
requirements and architectures
Challenged by the many notations used to
capture complex requirements as well as
architectures
It is internal with respect to the architectural
intent and modeling notation
Have all elements been fully modeled in the
notation?
Have all design decisions been properly
captured?
7
Software Architecture
Foundations, Theory, and Practice
Architectural Analysis Goals –
Consistency
Consistency is an internal property of an
architectural model
Ensures that different model elements do not
contradict one another
Dimensions of architectural consistency
Name
Interface
Behavior
Interaction
Refinement
8
Software Architecture
Foundations, Theory, and Practice
Name Consistency
Component and connector names
Component service names
May be non-trivial to establish at the architectural
level
Multiple system elements/services with
identical names
Loose coupling via publish-subscribe or
asynchronous event broadcast
Dynamically adaptable architectures
9
Software Architecture
Foundations, Theory, and Practice
Interface Consistency
Encompasses name consistency
Also involves parameter lists in component services
A rich spectrum of choices at the architectural level
Example: matching provided and required interfaces
ReqInt:
getSubQ(Natural first, Natural last, Boolean remove)
returns FIFOQueue;
ProvInt1: getSubQ(Index first, Index last)
returns FIFOQueue;
ProvInt2: getSubQ(Natural first, Natural last, Boolean remove)
returns Queue;
10
Software Architecture
Foundations, Theory, and Practice
Behavioral Consistency
Names and interfaces of interacting components may
match, but behaviors need not
Example: subtraction
subtract(Integer x, Integer y) returns Integer;
Can we be sure what the subtract operation does?
Example: QueueClient and QueueServer components
QueueClient – getFront
precondition q.size > 0;
postcondition ~q.size = q.size;
QueueServer – getFront
precondition q.size > 1;
postcondition ~q.size = q.size - 1;
11
Software Architecture
Foundations, Theory, and Practice
Interaction Consistency
Names, interfaces, and behaviors of interacting
components may match, yet they may still be
unable to interact properly
Example: QueueClient and QueueServer
components
12
Software Architecture: Foundations, Theory, and Practice ; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.
Software Architecture
Foundations, Theory, and Practice
Refinement Consistency
Architectural models are refined during the
design process
A relationship must be maintained between
higher and lower level models
All elements are preserved in the lower level
model
All design decisions are preserved in the lowerlevel model
No new design decisions violate existing design
decisions
13
Software Architecture
Foundations, Theory, and Practice
Refinement Consistency Example
14
Software Architecture: Foundations, Theory, and Practice ; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.
Software Architecture
Foundations, Theory, and Practice
Architectural Analysis Goals –
Compatibility
Compatibility is an external property of an
architectural model
Ensures that the architectural model adheres to
guidelines and constraints of
a style
a reference architecture
an architectural standard
15
Software Architecture
Foundations, Theory, and Practice
Architectural Compatibility Example –
Lunar Lander
What is the style of this architecture?
16
Software Architecture: Foundations, Theory, and Practice ; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.
Software Architecture
Foundations, Theory, and Practice
Architectural Analysis Goals –
Correctness
Correctness is an external property of an architectural
model
Ensures that
1. the architectural model fully realizes a system
specification
2. the system’s implementation fully realizes the
architecture
Inclusion of OTS elements impacts correctness
System may include structural elements,
functionality, and non-functional properties that are
not part of the architecture
The notion of fulfillment is key to ensuring
architectural correctness
17
Software Architecture
Foundations, Theory, and Practice
Scope of Architectural Analysis
Component- and connector-level
Subsystem- and system-level
Beware of the “honey-baked ham” syndrome
Data exchanged in a system or subsystem
Data structure
Data flow
Properties of data exchange
Architectures at different abstraction levels
Comparison of two or more architectures
Processing
Data
Interaction
Configuration
Non-functional properties
18
Software Architecture
Foundations, Theory, and Practice
Data Exchange Example
19
Software Architecture: Foundations, Theory, and Practice ; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.
Software Architecture
Foundations, Theory, and Practice
Architectures at Different Abstraction
Levels
20
Software Architecture: Foundations, Theory, and Practice ; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.
Software Architecture
Foundations, Theory, and Practice
Architectural Concern Being
Analyzed
Structural characteristics
Behavioral characteristics
Interaction characteristics
Non-functional characteristics
21
Software Architecture
Foundations, Theory, and Practice
Level of Formality
Informal models
Semi-formal models
Formal models
22
Software Architecture
Foundations, Theory, and Practice
Type of Analysis
Static analysis
Dynamic analysis
Scenario-driven analysis
Can be both static and dynamic
23
Software Architecture
Foundations, Theory, and Practice
Level of Automation
Manual
Partially automated
Fully automated
24
Software Architecture
Foundations, Theory, and Practice
Analysis Stakeholders
Architects
Developers
Managers
Customers
Vendors
25
Software Architecture
Foundations, Theory, and Practice
Architectural Analysis in a
Nutshell
26
Software Architecture: Foundations, Theory, and Practice ; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.
