Analysis of software architectures

Software Architecture: Foundations, Theory, and Practice
Copyright © Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy. All rights reserved.
Analysis of
Software Architectures
Software Architecture
Horia Constantin & original authors

2
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.
 Objective: Not needing to read that chapter of the
book unless you have a really specific question.
 Assumption: minimal participation from you
 Tip for not getting bored: ASK QUESTIONS
whenever something is unclear.

Architectural Analysis in a Nutshell
3

4

What Is Architectural Analysis?
 Architectural analysis is the activity of
discovering important system properties
using the system’s architectural models.
 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
5

Take home! – summary slide
 Analysis means:
Setting a goal (what do we want to analyze?)
Defining the scope (what area are we focusing on?)
Defining the concern – not sure about this one
Establishing the formality level
(optional) Analysis type/automation?(how will the
analysis be done?)
 Don’t forget about the economical analysis of
architecture!
6

What is the purpose of analysis?
 Early (before development), useful answers about
relevant architectural aspects
 discover components to be grabbed off the shelf.
 Just having the architecture is not enough…
7

8

Architectural Analysis Goals
 The four “C”s
Completeness
Consistency
Compatibility
Correctness
9

Architectural Analysis Goals –
Completeness
 Does the architecture capture all of a system's key
functional and non-functional requirements?
 Have all elements been fully modeled in the notation?
 Have all design decisions been properly captured?
10
Client Client Client
Server
Incomplete!
Client Client
Server
Complete
Client
Server

Consistency
 Ensures that different model elements do not
contradict one another
 Dimensions of architectural consistency
Name
Interface
Behavior
Interaction
Refinement
11

Consistency fun test incoming
12

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
13

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;
14

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?
15

Interaction Consistency
16
 Names, interfaces, and behaviors of interacting
components may match, yet they may still be unable
to interact properly

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 lower-level
model
No new design decisions violate existing design
decisions
17

Refinement Consistency Example
18

Consistency test?
19
A. Dequeue function in one interface only
polls the queue and the other one also
removes the element
B. Interface present in Product Architecture
is missing in the zoomed-in module
architecture
C. Invoke an operation after a close event or
before a component has been initialized
D. Included in another type
E. Client: getSubQ(Natural first, Natural
last, Boolean remove) Server:
getSubQ(Index first, Index last)
1. Name
2. Interface
3. Behavior
4. Interaction
5. Refinement

Compatibility
 Ensures that the architectural model adheres to
guidelines and constraints of
a style
a reference architecture
an architectural standard
20

Correctness
 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 – what
proposition is not respected?
21

Architectural Analysis Goals?
 The four “C”s – TEST
C _ _ _ _ _ _ _ _ _ _ _
C _ _ _ _ _ _ _ _ _ _
C _ _ _ _ _ _ _ _ _ _ _ _
C _ _ _ _ _ _ _ _ _ _
22

Scope of Architectural Analysis
 Component- and connector-level
 Subsystem- and system-level
 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
23

Data Exchange Example
24
Open question: How would you fix this?

Scope of Architectural Analysis
 Component- and connector-level
 Subsystem- and system-level
 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
25

Architectural Concern Being
Analyzed
 Structural characteristics
 Behavioral characteristics
 Interaction characteristics
 Non-functional characteristics
 Food for thought: does this classification add any value?
26

Level of Formality
 Informal models
 Semi-formal models
 Formal models
27

Informal Architectural Models
and Analysis
 Helps architects get
clarification from
system customers
 Helps managers
ensure project
scope
 Not as useful to
developers
28

Formal Architectural Models and
Analysis
 Helps architects
determine
component
composability
 Helps developers
with
implementation-
level decisions
 Helps with locating
and selecting
appropriate OTS
components
 Helps with
automated code
generation.
 Not as useful for
discussions with
non-technical
stakeholders
29
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.

Type of Analysis
 Static analysis (e.g. compilers)
 Dynamic analysis (executing the model)
 Scenario-driven analysis
Can be both static and dynamic
30

Level of Automation
 Manual
 Partially automated
 Fully automated
31

Analysis Stakeholders – different
views
32
Stakeholder Goal Scope Formality
Architect All All All
Developer Cnst, comp C&C, subsystem Semi, formal
Manager Cmplt, corr, comp ??? Informal
Customer Cmplt, corr ??? Informal
Vendor comp C&C Semi
Abbr Name
Cnst Consistency
Comp Compatibility
Cmplt Completeness
Corr Correctness

Project Management triangle
 Where is the economical
analysis?
 See Chapter 23 from
Software Architecture in
Practice (3rd Edition)
 Cost Benefit Analysis
Method – method with 9
activities
33

Take home! – summary slide
 Analysis means:
Setting a goal (what do we want to analyze?)
Defining the scope (what area are we focusing on?)
Defining the concern – not sure about this one
Establishing the formality level
(optional) Analysis type/automation?(how will the
analysis be done?)
 Don’t forget about the economical analysis of
architecture!
34

Analysis of software architectures

More Related Content

What's hot (20)

Similar to Analysis of software architectures (20)

Recently uploaded (20)

Analysis of software architectures

Editor's Notes