Zachary Cleaver
Analysis Definition and Purpose
 Architectural analysis is the activity of discovering
important system properties using the system’s
architectural models.
 Architectural analysis helps identify
incorrect/inefficient design decisions, clarifies
component functions and objects, and aids in
communication between designers and customers.
Facets of Architectural Analysis
 1) Goals of analysis
 2) Scope of analysis
 3) Primary architectural concerns being analyzed
 4) Level of formality between models
Facets of Analysis: Goals
 1) Completeness
 2) Consistency
 3) Compatibility
 4) Correctness
Completeness
 The main goal of assessing an architecture’s
completeness is to ensure it adequately capture all key
functional and non-functional requirements.
 Ideally, all services will be needed by a component,
and each component will have a service that provides
for it.
Consistency
 Definition: Internal property of an
architectural model that is intended to ensure
that different elements of that model do not
contradict one another.
 Types of Inconsistencies:
 Name
 Interface
 Behavioral
 Interaction
 Refinement
Name Inconsistency
 Same-name components providing similar services. Is
the right one being used?
 Accessing a nonexistent class or method resulting in
compile-time errors
Interface Inconsistency
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;
Behavioral Inconsistency
Subtract(int x, int y) returns int;
int myVal = Subtract(427, 27)
 The method behavior treats it as a date subtraction,
subtracts 27 days from April 27, and returns 331 (March
31)
Interaction Inconsistency
 Occurs when a component’s provided operations are
accessed in a manner that violates certain interaction
constraints.
 Ex. pop_back() in c++
Refinement Inconsistency
 Refinement inconsistencies stem from a system’s
architecture being frequently captured at different
levels of abstraction (higher v. lower)
 Check that elements were not lost, key properties were
not omitted or changed, etc.
Compatibility
 Compatibility ensures that the model adheres to the
design guidelines imposed by an architectural style,
reference architecture, or architectural standard.
Correctness
 Correctness is relative.
 It is the result of architecture to some artifact, where
the artifact either fulfills the architecture or the
architecture elaborates and fulfills the artifact.
Scope of Analysis
 Component and Connector Level
 Subsystem and System Level
 Data Exchanged in (sub)system
 Architectures at Different Abstraction Levels
 Comparison of Two or More Architectures
Component and Connector Level Analysis
 Ensures the given component or connector provides
the services expected of it
 However, this does not ensure services are modeled
correctly
 Checks name consistency
Subsystem and System Level
Analysis
 Pair-wise conformance: Two interacting components are
considered at a time, and name, interface, behavior, and
interaction conformance are established.
 Compare component properties (efficiency vs. security)
 Petry’s “Honey-baked ham” syndrome
Data Exchanged in the System or Subsystem
 Assess data elements to ensure the system’s data is
properly modeled, implemented, and exchanged
among structural elements
 Structure of the data (typed vs. untyped)
 Flow of data through the system (point-to-point vs.
broadcast)
 Properties of data exchange (consistency, security, etc.)
Architecture at Different Abstraction Levels
A
C
B
D
Comparisons of Two or More Architectures
 Comparing current architecture to a model of the
desired architecture
 Comparing two architectures for properties such as
processing and storage capabilities
Architectural Concern Being
Analyzed
 Structural Characteristics
 Behavioral Characteristics
 Interaction Characteristics
 Non-functional Characteristics
Structural Characteristics
 Determines whether the architecture is well formed
 Focuses on connectivity among architecture
components and connectors, points of network
distribution, etc.
 Identify problems such as disconnected components
or subsystems, missing pathways between components
and connectors, unwanted pathways, etc.
Behavioral Characteristics
 Concerned with the behavior of individual
components and their behaviors as a whole within the
architecture
 Internal behaviors of individual components is
considered, as well as the composite behaviors of
components as they interact
Interaction Characteristics
 Helps to establish whether the architecture will
actually be able to fulfill some of its requirements
(efficiency)
 Concerned with internal behaviors of systems
(security)
Non-Functional Characteristics
 Difficult to assess since they can span multiple
components and connectors
 Their definitions can be much more informal, making
it difficult to properly understand them in the
architecture
Level of Formality of Architectural Models
 Informal
 Semiformal
 Formal
Informal Models
 Typically captured in box-and-line diagrams
 Great for showing high-level representations of a
system
 Can be dangerous to use because of a lack of
information and an ambiguous nature
Semiformal Models
 Aims to be useful to both technical and nontechnical
stakeholders
 UML
Formal Models
 Designed for technical stakeholders
 These type of models can suffer from scalability
problems
Kata Morovat
Outline
Type of Analysis
Level of Automation
System Stakeholders
Analysis Techniques
Type of Analysis
o Static Analysis
o Dynamic Analysis
o Scenario-Based Analysis
Static Analysis - Definition
o Infer the properties of a software system from of its
models without executing those models
o Static analysis can be automated (compilation) or
manual ( inspection)
Static Analysis - Example
o A simple example is syntactic analysis. Determining if
the system model adheres to the syntactic rules of the
modeling notation (architectural description language
or programming language)
o All architectural modeling notations are agreeable to
static analysis
o Formal notations, includes:
• Axiomatic notations, use logical declaration
• Algebraic notations, use collection of equivalence relations
• Temporal logic notations, use order of execution and timing
Dynamic Analysis - Definition
o Dynamic analysis involves the execution or simulation
the execution of a model of the software system
Dynamic Analysis - Example
o State- transition diagrams
Scenario-Based Analysis Definition
o For large and complex software system, declaring all
properties for entire system over the entire space is
infeasible
o Use case which represent the most important or most
frequently occurring system scenarios, or a
methodology to identify, clarify, and organize system
requirements
o Use case diagram is a graphic depiction of the
interactions among the elements of a system
Level of Automation
o Depends on the completeness of the architectural
model and property being defined
o A model with a greater numbers of the architectural
design decisions for the given system will be more
amenable to automated analysis than a model with
informal notation
Level of Automation – Manual
Analysis
o Manual analysis requires human involvement.
o This can be used when multiple clashing properties
must be ensured in tandem
o Many manual analysis techniques are used for
specifying a detail process
o The manual analysis results are typically qualitative,
frequently are also qualified by a particular context in
which a system may show a given property, Scenariobased techniques fall in this category
Manual Analysis - Example
o Inspection-based techniques falls in Manual analysis
category
o One well-known example is architecture trade-off
analysis method
Level of Automation – Partially
Automated
o Architecture analyses can be automated by involving
software tools and human intervention
o Architectural analysis techniques can be describes as
covering a spectrum of automation, with manually and
fully automated analysis
Level of Automation – Fully
Automated
o Architectural
analysis
can
be
considered
fully
automatable
o It means it is possible to complete them without
human involvement
System Stakeholders
o Stakeholders in a software project will have different
objectives
o Architects
• Take a global view of the architecture
• Interested in establishing all four C’s in the architecture
• Rely on all types of architectural models at all levels of scope
o Developers
• Take a limited view of architecture – modules or subsystem
• Interested in establishing the consistency of their modules and
other parts of the system
• Interested in using formal model
System Stakeholders
o Managers
• Interested in architecture’s completeness – all requirements are
satisfied
• Interested in architecture’s correctness –the requirements are
realized in the architecture and eventually will be realized in the
implementation
• Interested in architecture’s compatibility if the architecture and
implementation are close to standards
• Prefer to use the less formal architecture models
o Customers
• Interested in commissioned system’s completeness and correctness
• Interested in the system’s compatibility with certain standards
System Stakeholders
• Interested in overall models and system’s key properties
• Interested
in scenario-driven assessment of the
structure, behavior and dynamic characteristic of the
system
o Vendors
• Interested in combining of components and connectors
• Interested in compatibility with certain standards
• Analysis of the individual elements and their properties
Analysis Techniques
o Three categories of architectural analysis techniques:
• Inspection and review-based
• Model-based
• Simulation-based
Inspection and Review-based
o Manual techniques
o Architectural models are conducted by different human
o
o
o
o
stakeholders to ensure a variety of properties, such as
architecture satisfies a given non-functional properties
Architectural models considers to multiple architectural
properties.
Useful in the case of informal architectural descriptions
Useful in establishing “soft” system properties, such as
scalability or adaptability
Type of analysis for inspections and reviews are static and
scenario-based
Inspection and Reviews Analysis
Summary
o Analysis Goals – any
o Analysis Scope – any
o Analysis Concern – any, but particularly suited for
non-functional properties
o Architectural Models – any, but must be covered
stakeholder needs and analysis objectives
o Analysis Types – mostly static and scenario-based
o Automation Level – manual, human intensive
o Stakeholders – any, except perhaps component vendors
Example - ATAM
o Stands for Architectural Trade-Off Analysis Method.
o A human-centric process for identifying risk early in a
software design
o Two key inputs into the ATAM process : Business drivers
and System software architecture.
o Project’s manager or customers present the system’s major
business drivers, including :
• The system’s critical functionality
• Any technical, managerial, economic, or political constraints
• The project’s business goals and context
• The major stakeholders
• The principal quality attribute (NFP) goals
o Focuses specifically on four quality attributes (NFPs)
• Modifiability
• Security
• Performance
• Reliability
o Reveals how well an architecture satisfies quality goals
and how those goals trade-off
ATAM Process
ATAM Scenarios
o Use-case scenarios
• Describe how the system is envisioned by the stakeholders to be
used
o Growth scenarios
• Describe planned and envisioned modifications to the architecture
o Exploratory scenarios
• Try to establish the limits of architecture’s adaptability with
respect to
•
system’s functionality
• Scenarios are prioritized based on importance to stakeholders
ATAM Analysis : Key Steps
o Objective
is to establish relationship between
architectural approaches and quality attributes
o For each architectural approach a set of analysis
questions are formulated
• Targeted at the approach and quality attributes in question
o System architects and ATAM evaluation team work
together to answer these questions and identify
•
•
•
•
Risks  these are distilled into risk themes
Non-Risks
Sensitivity points
Trade-off points
o Based on answers, further analysis may be performed
ATAM Analysis Summary
o Analysis
Goals - completeness, consistency,
compatibility, correctness
o Analysis Scope – system, system-level and data
exchange
o Analysis Concern – non-functional
o Architectural Models – informal, semi-formal
o Analysis Types – scenario-driven
o Automation Level – manual
o Stakeholders – architects, developers, managers,
customers
Model-Based Analysis
o Analysis techniques that manipulate architectural
description to discover architectural properties
o Tool-driven, hence potentially less costly
o Typically useful for establishing “hard” architectural
properties
o Usually focus on a single architectural aspect, such as
syntactic correctness
o Scalability may be an issue
o Techniques typically used in tandem to provide more
complete answers
Model-Based Analysis Summary
o Analysis
Goals
–
consistency,
compatibility,
correctness
o Analysis Scope – any
o Analysis Concern – structural, behavioral, interaction,
and possibly non-functional properties
o Architectural Models – semi-formal and formal
o Analysis Types – static
o Automation Level – partially and fully automated
o Stakeholders – mostly architects and developers
Model-Based Analysis Enabled by
ADLs
o ADL stands for Architecture Description Language
o ADL parsers and compilers – ensure syntactic and
semantic correctness, like Rapide’s generation of
executable architectural simulations
o Enforcement of constraint , parsers and compilers
enforce constraints implicit in type information, nonfunctional attributes, components and connectors
interfaces, and semantic models
o Architectural refinement across multiple levels of
detail like SADL and Rapide
ADLs Analysis Summary
o Analysis
Goals – consistency, compatibility,
completeness
o Analysis Scope – component and connector-level,
subsystem and system level, data exchange, different
abstraction level, architecture comparison
o Analysis Concern – structural, behavioral, interaction,
non-functional properties
o Architectural Models – semi-formal and formal
o Analysis Types – static
o Automation Level – partially and fully automated
o Stakeholders – architects, managers, developers,
customers
Architectural Reliability Analysis
o Reliability is the probability that the system will perform its
intended functionality under specified design limits,
without failure
o A failure is the occurrence of an incorrect output as a result
of an input value that is received, with respect to the
specification
o An error is a mental mistake made by the designer or
programmer
o A fault or a defect is the manifestation of that error in the
system
• An abnormal condition that may cause a reduction in, or loss of, the
capability of a component to perform a required function
• A requirements, design, or implementation flaw or deviation from a
desired or intended state
Reliability Metrics
o Time to failure
o Time to repair
o Time between failures
Architecture Level of Assessing
Reliability
o Challenged by unknowns
• Failure and recovery history
o Challenged by uncertainties
• Multiple development scenarios
• Varying granularity of architectural models
• Different information sources about system usage
o Architectural reliability values must be qualified by
assumptions made to deal with the above uncertainties
o Reliability modeling techniques are needed that deal
effectively with uncertainties like Hidden Markov Models
(HMMs)
Aspects of Reliability Analysis
Summary
o Analysis
Goals
–
consistency,
compatibility,
correctness
o Analysis Scope – component and connector-level,
subsystem and system level
o Analysis Concern – non-functional properties
o Architectural Models – formal
o Analysis Types – static and Scenario-based
o Automation Level – partially automated
o Stakeholders – architects, managers, customers,
vendors
Simulation-Based Analysis
Simulation-Based Analysis
Summary
o Analysis Goals – any
o Analysis Scope – any
o Analysis Concern –behavioral, interaction, and non-
functional properties
o Architectural Models – formal
o Analysis Types – dynamic and scenario-based
o Automation Level – fully automated; model mapping
may be manual
o Stakeholders – any
Example XTEAM
o eXtensible Tool-chain for Evaluation of Architectural
Models
o Targeted at mobile and resource-constrained systems
o Combines two general purpose ADLs
• xADL and FSP
• To capture important features of mobile system
o Implements simulation-based analysis capabilities for
•
One-to-one latency, memory utilization, reliability, energy consumption
XTEAM Analysis Summary
o Analysis Goals – consistency, compatibility, correctness
o Analysis Scope – component and connector-level,
o
o
o
o
o
subsystem and system level, data exchange
Analysis Concern – structure, behavior, interaction, nonfunctional
Architectural Models – formal
Analysis Types – dynamic and Scenario-based
Automation Level – automated
Stakeholders – architects, managers, developer, customers,
vendors
Remark points
o Architectural analysis is neither easy nor cheap
o The benefits typically far outweigh the drawbacks
o Early information about the system’s key characteristics is
vital
o Multiple analysis techniques often should be used in
concert
o “How much analysis?”
• This is the key aspect of an architect’s job
• Too many will expend resources unnecessarily
• Too few will carry the risk of propagating defects into the
final system
• Wrong analyses will have both drawbacks
Thank you