CHAPTER-6
Analysis
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
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
3
Architectural Analysis Goals
The four “C”s
○ Completeness
○ Consistency
○ Compatibility
○ Correctness
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?
5
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
6
Dimensions of architectural consistency
Name
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
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;
8
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
precondition q.size > 0;
postcondition ~q.size = q.size;
QueueServer
precondition q.size > 1;
postcondition ~q.size = q.size - 1; 9
Interaction
Names, interfaces, and behaviors of
interacting components may match, yet they
may still be unable to interact properly
Example: QueueClient and QueueServer
components
Refinement
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
Compatibility
Compatibility is an external property of an
architectural model
It is to check the compatibility between new
and reused components\connectors,
reference architecture and propose
architecture.
Ensures that the architectural model adheres
to guidelines and constraints of
a style
a reference architecture
an architectural standard
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 off-the-shelf 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.
Scope of Analysis
A software system’s architecture can be
analyzed from different perspectives and at
different levels. Architects may be interested
in assessing the properties of individual
components or connectors, or even their
constituent, such as interfaces or ports.
Components- and Connector-Level
Analysis
This analysis ensures that the given
component or connector provides the
services expected of it.
For example, a component’s or connector’s
interface can be inspected to make sure
that no expected services are missing.
Subsystem- and system-Level Analysis
Architects may assess the properties of connector-
component compositions at the level of the entire
system or incrementally, by focusing on particular
subsystems.
The most manageable increment is pair-wise
conformance, where only two interacting
components are considered at a time, and name,
interface, behavior, and interaction conformance are
established.
The next step up is to take a set of components
possibly interacting techniques can easily support
both these cases.
.
Data Exchanged in the System or
Subsystem
Distributed software systems large amounts of
data are processed, exchanged, and stored.
It is important that system’s data is properly
modeled, implemented, and exchanged
among the structural elements.
Architecture at Different Abstraction
Levels
This may involve the addition and refinement
of existing design.
Example: in following figure, c1, c2, c3, c4 are
components interacting through connectors,
but this can be design in more depth by
extracting each component with their internal
communication
Architectural Concern Being
Analyzed
Structural characteristics
Behavioral characteristics
Interaction characteristics
Non-functional characteristics
24
Structural Characteristics
The structural characteristics of software
architecture include concerns such as the
connectivity among an architecture’s
components and connectors
These concerns can help to determine
whether the architecture is well formed.
Behavioral Characteristics
Analyzing architecture’s behavioral
characteristics are needed if components and
their interaction do not provide expected
behaviors. it has two facets;
Considering the internal behaviors of individual
components.
Considering the architectural structure to
assess composite behaviors.
Interaction characteristics
The relevant characteristics of interactions in a
given architecture may include the numbers
and types of distinct software connectors, and
their values for different connector dimensions.
Interaction characteristics can help to establish
whether the architecture will actually be able to
fulfill some of its requirements
Level of Formality of Architectural Models
Architectural models can be classified as
follows
Informal models
○ Informal models are typically captured in boxes-and-
lines diagrams. Informal models can provide a useful
high-level picture of the system.
○ They are amenable to informal and manual analysis,
typically by a broad section of stakeholders,
including nontechnical stakeholders such as
managers and system customers.
○ For example, system managers can use them to
determine a project’s overall staffing needs.
Semi-formal models
○ Most architectural models used in practice
are semiformal.
○ A notation that strives to be useful to a large
number of system stakeholders, both
technical and nontechnical, will typically try
to strike a balance between a high degree of
precision and formality on the one hand, and
expressiveness and understandability on the
other.
○ Example: a semiformal languages such as
the UML are amenable both to manual and
automated analysis.
Formal models
○ While semiformal modeling notations
typically only have a formally defined syntax,
formal notations also have formally defined
semantics.
○ For example formal notation is wright, which
was used to specify the Pipe-connector.
Type of Analysis
Static analysis
Dynamic analysis
Scenario-driven analysis
Can be both static and dynamic
31
Static analysis
○ Static analysis involves inferring the
properties of a software system from one or
more of its models, without actually
executing those models.
○ A simple example of static analysis is
syntactic analysis: determining if the system
model adheres to the syntactic rules of the
modeling notation.
○ Static analysis can be automated (for
eg.compilation) or manual (for
eg.inspection).
Dynamic analysis
○ This analysis involves actually
executing or simulating the
execution of a model of the software
system.
○ In order to perform dynamic analysis
on an architectural model, its
semantic underpinning must be
executable or amenable to
simulation.
Scenario-driven analysis
○ It can be an instance of both static and
dynamic.
○ It is used for large and complex
software system. For such systems,
specific-use cases are identified that
represent the most important or most
frequently occurring system usage
scenarios, and the analysis is focus on
those.
Analysis Stakeholders
Architects
Developers
Managers
Customers
Vendors
35
Analysis Technique Categories
Inspection- and review-based
Model-based
Simulation-based
37
Architectural Inspections and
Reviews
Architectural models studied by human
stakeholders for specific properties
The stakeholders define analysis objective
Manual techniques
Can be expensive
Useful in the case of informal architectural
descriptions
Useful in establishing “soft” system properties
E.g., scalability or adaptability
Able to consider multiple stakeholders’ objectives
and multiple architectural properties
38
Inspections and Reviews in a
Nutshell
Analysis Goals – any
Analysis Scope – any
Analysis Concern – any, but particularly suited
for non-functional properties
Architectural Models – any, but must be geared
to stakeholder needs and analysis objectives
Analysis Types – mostly static and scenario-
based
Automation Level – manual, human intensive
Stakeholders – any, except perhaps component
vendors
39
ATM Process
ATAM in a Nutshell
Completeness
Consistency
Goals
Compatibility
Correctness`
Subsystem- and system-level
Scope
Data exchange
Concern Non-functional
Informal
Models
Semi-formal
Type Scenario-driven
Automation Level Manual
Architects
Developers
Stakeholders
Managers
Customers
41
Model-based
Analysis techniques that manipulate
architectural description to discover
architectural properties Tool-driven, hence
potentially less costly
Typically useful for establishing “hard”
architectural properties only
Unable to capture design intent and rationale
Usually focus on a single architectural aspect
E.g. syntactic correctness, deadlock
freedom, adherence to a style Scalability
may be an issue
Model-Based Analysis in
ADLs
Wright – uses CSP to analyze for deadlocks
Aesop – ensures style-specific constraints
MetaH and UniCon – support schedulability analysis
via NFPs such as component criticality and priority
ADL parsers and compilers – ensure syntactic and
semantic correctness
E.g., Rapide’s generation of executable architectural
simulations
Architectural constraint enforcement
E.g., Armani or UML’s OCL
Architectural refinement
E.g., SADL and Rapide
43
ADLs’ Analysis Foci in a Nutshell
Consistency
Goals Compatibility
Completeness (internal)
Component- and connector-level
Subsystem- and system-level
Scope Data exchange
Different abstraction levels
Architecture comparison
Structural
Behavioral
Concern
Interaction
Non-functional
Semi-formal
Models
Formal
Type Static
Partially automated
Automation Level
Automated
Architects
Developers
Stakeholders
Managers
Customers
44
Simulation-based
Requires producing an executable system
model
Simulation need not exhibit identical behavior
to system implementation Many low-level
system parameters may be unavailable
It needs to be precise and not necessarily
accurate
Some architectural models may not be
amenable to simulation Typically require
translation to a simulatable language
Simulation-Based Analysis in a
Nutshell
Analysis Goals – any
Analysis Scope – any
Analysis Concern –behavioral, interaction,
and non-functional properties
Architectural Models – formal
Analysis Types – dynamic and scenario-
based
Automation Level – fully automated; model
mapping may be manual
Stakeholders – any
46
XTEAM in a Nutshell
Consistency
Goals Compatibility
Correctness
Component- and connector-level
Scope Subsystem- and system-level
Data exchange
Structural
Behavioral
Concern
Interaction
Non-functional
Models Formal
Dynamic
Type
Scenario-based
Automation Level Automated
Architects
Developers
Stakeholders Managers
Customers
Vendors
47
