Analysis Definition and Purpose Architectural analysis is the
activity of discovering important system properties using the
systems architectural models. Architectural analysis helps identify
incorrect/inefficient design decisions, clarifies component
functions and objects, and aids in communication between designers
and customers.
Slide 3
Facets of Architectural Analysis 1) Goals of analysis 2) Scope
of analysis 3) Primary architectural concerns being analyzed 4)
Level of formality between models
Completeness The main goal of assessing an architectures
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.
Slide 6
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
Slide 7
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
Slide 8
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;
Slide 9
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)
Slide 10
Interaction Inconsistency Occurs when a components provided
operations are accessed in a manner that violates certain
interaction constraints. Ex. pop_back() in c++
Slide 11
Refinement Inconsistency Refinement inconsistencies stem from a
systems 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.
Slide 12
Compatibility Compatibility ensures that the model adheres to
the design guidelines imposed by an architectural style, reference
architecture, or architectural standard.
Slide 13
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.
Slide 14
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
Slide 15
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
Slide 16
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) Petrys
Honey-baked ham syndrome
Slide 17
Data Exchanged in the System or Subsystem Assess data elements
to ensure the systems 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.)
Slide 18
Architecture at Different Abstraction Levels A B C D
Slide 19
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
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.
Slide 22
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
Slide 23
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)
Slide 24
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
Slide 25
Level of Formality of Architectural Models Informal Semiformal
Formal
Slide 26
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
Slide 27
Semiformal Models Aims to be useful to both technical and
nontechnical stakeholders UML
Slide 28
Formal Models Designed for technical stakeholders These type of
models can suffer from scalability problems
Slide 29
Kata Morovat
Slide 30
Outline Type of Analysis Level of Automation System
Stakeholders Analysis Techniques
Slide 31
Type of Analysis o Static Analysis o Dynamic Analysis o
Scenario-Based Analysis
Slide 32
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)
Slide 33
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
Slide 34
Dynamic Analysis - Definition o Dynamic analysis involves the
execution or simulation the execution of a model of the software
system
Slide 35
Dynamic Analysis - Example o State- transition diagrams
Slide 36
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
Slide 37
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
Slide 38
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, Scenario- based techniques fall in this
category
Slide 39
Manual Analysis - Example o Inspection-based techniques falls
in Manual analysis category o One well-known example is
architecture trade-off analysis method
Slide 40
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
Slide 41
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
Slide 42
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 Cs 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
Slide 43
System Stakeholders o Managers Interested in architectures
completeness all requirements are satisfied Interested in
architectures correctness the requirements are realized in the
architecture and eventually will be realized in the implementation
Interested in architectures compatibility if the architecture and
implementation are close to standards Prefer to use the less formal
architecture models o Customers Interested in commissioned systems
completeness and correctness Interested in the systems
compatibility with certain standards
Slide 44
System Stakeholders Interested in overall models and systems
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
Slide 45
Analysis Techniques o Three categories of architectural
analysis techniques: Inspection and review-based Model-based
Simulation-based
Slide 46
Inspection and Review-based o Manual techniques o Architectural
models are conducted by different human stakeholders to ensure a
variety of properties, such as architecture satisfies a given
non-functional properties o Architectural models considers to
multiple architectural properties. o Useful in the case of informal
architectural descriptions o Useful in establishing soft system
properties, such as scalability or adaptability o Type of analysis
for inspections and reviews are static and scenario-based
Slide 47
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
Slide 48
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 Projects manager or
customers present the systems major business drivers, including :
The systems critical functionality Any technical, managerial,
economic, or political constraints The projects business goals and
context The major stakeholders The principal quality attribute
(NFP) goals
Slide 49
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
Slide 50
ATAM Process
Slide 51
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 architectures
adaptability with respect to systems functionality Scenarios are
prioritized based on importance to stakeholders
Slide 52
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
Slide 53
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
Slide 54
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
Slide 55
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
Slide 56
Model-Based Analysis Enabled by ADLs o ADL stands for
Architecture Description Language o ADL parsers and compilers
ensure syntactic and semantic correctness, like Rapides generation
of executable architectural simulations o Enforcement of
constraint, parsers and compilers enforce constraints implicit in
type information, non- functional attributes, components and
connectors interfaces, and semantic models o Architectural
refinement across multiple levels of detail like SADL and
Rapide
Slide 57
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
Slide 58
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
Slide 59
Reliability Metrics o Time to failure o Time to repair o Time
between failures
Slide 60
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)
Slide 61
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
Slide 62
Simulation-Based Analysis
Slide 63
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
Slide 64
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
Slide 65
XTEAM Analysis Summary o Analysis Goals consistency,
compatibility, correctness o Analysis Scope component and
connector-level, subsystem and system level, data exchange o
Analysis Concern structure, behavior, interaction, non- functional
o Architectural Models formal o Analysis Types dynamic and
Scenario-based o Automation Level automated o Stakeholders
architects, managers, developer, customers, vendors
Slide 66
Remark points o Architectural analysis is neither easy nor
cheap o The benefits typically far outweigh the drawbacks o Early
information about the systems 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 architects 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
