Analysis of Architecture
• As part of the activities in coming up
with a good software architecture, we
should analyze the architecture that we
have designed and modeled.
my addition
Architectural analysis is the activity of
discovering (and organizing/assessing)
important system properties using the
system’s architectural models.
Dimensions of (or things to consider for)
Architectural Analysis
1.
2.
3.
4.
5.
6.
7.
8.
Goals of analysis
Scope of analysis
Concerns to be analyzed
Models and levels of formality
Types of analysis
Levels of automating the analysis
Stakeholders interested in analysis
Analysis techniques
Goals of Analysis
•
4 categories of goals for analysis of the
architecture:
1.
2.
3.
4.
Completeness
Consistency
Compatibility
Correctness
5. Cohesiveness
6. Coupling
I would add these 2 more
1. Architectural Completeness
• Completeness with respect to external concerns:
– Checking the architecture against the requirements
• Functional
• Non-functional
– Difficult to do when the system is large due to massive amount of
material
– Difficult to do when pieces are specified and designed incrementally
(choosing the right moment for assessment)
e.g. agile
• Completeness with respect to internal concerns:
– Checking to see if all the system’s elements are captured
•
•
•
•
•
Components
Connectors
Interface and protocols
Dependencies
Interactions
system configuration
2. Architectural Consistency
• Internal property of the architecture which states that the
architectural elements do not contradict each other
– Name inconsistencies
• May be difficult to catch in incremental design and distributed
design when not everything is there and can change
– Interface inconsistencies
• Watch for polymorphism and overloading versus real problem
– Behavioral inconsistencies
• Watch for typing such as “difference” may represent arithmetic
subtraction of two integers versus number of mismatched
characters in two strings (semantic confusion)
– Interaction Inconsistencies
• These can occur when the protocol is not clear such as “sequence
of interaction” between two entities especially in a stateful situation.
– Refinement Inconsistencies
• This may occur when moving from high level to lower level design
and loosing something, or adding something extra, or violate some
constraint ---- especially if you use multiple - views
3. Architectural Compatibility
• Compatibility is an external property of the
model to ensure that the architecture adheres
to:
– Architecture & Design Standard
– Constraints of the adopted Architecture style
– Constraints imposed by the reference architecture
(reference architecture is an architecture that is
applicable to multiple related systems within an
application with explicitly defined points of
variation)
This may be more difficult than it appears because the external standards, style,
and reference architecture may all be unclear or not completely defined,
4. Architectural Correctness
• Correctness is an external property of the
model that addresses if the external system
specification is properly realized in the
architecture. (includes completeness?)
Have we “properly” evolved from the specification
to the architectural model ?
This is especially difficult to analyze when
we use off-the-shelf components which are not
perfect match and needs some “tailoring” work.
Cohesion and Coupling
• Two additional characteristics of the
architecture that we like to be able to assess
as “goals” of analyzing architecture.
– Cohesion : does the architectural components fit
together cleanly with minimal overlap and little
extra elements? (component level cohesion)
– Coupling: does the architectural components and
connectors have excessive interactions?
(component level coupling)
Scope of Analysis
• Architecture may be analyzed at different
levels or from different perspectives. Scope
of analysis may address:
o
o
o
o
o
Component and Connector level analysis
Subsystem and System level analysis
Data exchanges in the System or Subsystem
Different levels of Abstraction
Comparison of two or more Architectures
Component and Connector Level
• Each component and each connector needs
to be analyzed
– Does it provide the specified service
– Does it do it correctly (in the intended manner)
• The composition of components and
connectors
– Does the composition provide the intended
services
– Does the composition work correctly
Subsystem and System Level
• At the subsystem and system level, we are analyzing the
compositions of components and connectors to form a
subsystem and then to form a complete system.
– Pair-wise conformance of 2 interacting components in terms of
their interface, interaction and behavior is analyzed within the
subsystem.
– Assessing over-all properties as subsystems are incrementally
built and the over-all system continue to evolve
• Interesting situation is where off-the-shelf components are
configured where there may be need for “additional” functionalities
but causing potential degradation in some less acute property (e.g.
to improve security, we bring in security guarding components
such as extra “walls” and encryption --- which may affect overall
execution performance or system maintenance)
• System scalability is a critical property as larger and larger
heterogeneous subsystems are configured together
Data Exchange Level
• In most large or distributed systems, there is large
amount of data processed and exchanged (e.g. webbased applications). It is important that data is properly
modeled:
– The structure of data
• Data typing
• Data organization
– Flow of the data through the system
•
•
•
•
Point-point
Client-server
Event based broadcast
etc
– Properties of data exchanges
•
•
•
•
Performance
Security
Stateful vs stateless
etc
Different Abstraction Levels
• As we refine the architecture and the model, it is
important that we ensure the compatibility of the models
at different levels. That is the refined models stay
consistent with the higher levels. This is especially
difficult if different components and subsystems are
modeled to different levels of refinement.
Component A
Component
A
refinement
Component
C
Component C
Component
B
Component B
Comparing Architectures
•
We are interested in comparing and ensuring
that an “evolving” system has :
–
–
•
not altered from the base architecture or the
reference architecture
Stayed within the bounds of some architectural /
design standard
(looking for both “drift” and “erosion”)
In comparing architectures, we are looking at:
1. Composition of components and connectors
2. Interactions among components and connectors
3. Characteristics of data exchange
Architectural Analysis “Concerns”
• In analyzing architectures we are interested in several
“key concerns”:
– Structural Characteristics (static)
• Connectivity of components and connectors
• Lower level components contained into higher level composite
component
• Points of network distribution and concurrency paths
– Behavioral Characteristics (static)
• Individual component and connector functionalities
• Composite and collaborative functionalities (especially when
composed with off-the-shelf components or connectors)
– Interaction Characteristics (dynamic)
• Number and type of connectors and protocols among
components and connectors
• Properties such as timing, synchronicity, buffering, etc.
– Non-functional Characteristics (static & dynamic)
• Properties that cut across the whole system or subsystems such
as security, performance, quality, etc.
Levels of Formality & Analysis
• The level of formality in analysis requires certain level of
formality in the architectural models which we use in the
analysis:
– Informal (box-line) models allow only high level analysis but by a
broad sector of stakeholders. Often times the analysis is performed
manually with little automation.
– Semi-formal models, such as UML, allows a deeper level of analysis
by those trained to understand that semi-formal model. The amount
of training required is not formidable, thus allowing more
stakeholders to participate in the analysis. Also allows partial
automation of the analysis activity
– Formal models , such as Wright or Acme, requires understanding of
the formal syntax and semantics used in the model; thus it restricts
the number of stakeholders who can participate in the analysis, but
does allow better automation and deeper analysis.
Types of Analysis
• Static Analysis
– Analyzing the architectural model without executing any part of
the model
– Concerns analyzed are mostly structural, with little other kinds
of concerns analyzed
–
• Dynamic Analysis
– Involves executing or simulating the execution of the
architectural model
– Major concerns analyzed are behavior and interaction
properties, with some non-functional properties
• Scenario-Based or Work-flow Based Analysis
– Very good for some specific non-functional concern that cuts
across the whole system.
Levels of Automation
• A more detailed and formal architectural model is more
amenable to automation
• A more well “defined” and “quantifiable” property is
the more it may be assessed automatically
• 3 Levels of Automation:
– Manual ---- mostly qualitative & may not be easily duplicated
– Partially automated --- using some tools to look for evaluating
syntactical conformance or for counting the numbers or for
evaluating some property
– Fully automated --- only in well-definable areas such as
syntactical conformance; most likely not achievable
Stakeholders and Architectural Analysis
Stakeholders
Architectural
Goals
Architectural
Concerns
Level of Formality /
Types of Analysis
Architect
-completeness
-consistency
-compatibility
-correctness
-structural
-behavioral
-interaction
-non-functional
-all levels (informal,
semi-formal &
formal) of arch.
models
-all types (static,
dynamic & scenario)
of analysis
Developers
-consistency
-compatibility
- completeness
- correctness
-behavioral
-interaction
- semi formal &
formal model
-internal static &
dynamic
Managers
-completeness
-correctness
-non-functional
-structural/behavior
-informal
-some scenarios
Customers
-completeness
-correctness
-all concerns at high
level
-informal level
-mostly scenario
Vendors
-compatibility
-structural
(composibility)
-informal & formal
-static & scenario
Some Analysis Techniques
(A) Analysis via Reviews and Inspections
(B) Model Based Analysis
(C) Simulation Based Analysis
(A) Reviews and Inspections of Architecture
• Reviews and inspections are human based activities
that require:
– 1) preparation for inspection and of architectural material
• Think through material discussed earlier such as :
–
–
–
–
–
–
–
–
Set goals for analysis of the architecture
Set the scope of the analysis
Decide on the concerns
etc.
2) preparation of participants (stakeholders)
3) review/analysis of the architectural material
4) analysis of the review results and recommend actions
5) follow-up and closeout
Reviews and Inspections of Architecture
• Depending on the context, reviews and
inspections may have the broadest spectrum:
– Goals: completeness, consistency, correctness, and
compatibility
– Scope: spans components, connectors and the
complete system; also includes data-exchange and
compatibility to reference architecture and
compliance to standards , etc.
– Concerns of reviews may include: structural,
behavioral, interaction and non-functional
– Types of model used for analysis are: mostly semiformal; many stakeholders may not understand or
appreciate the formal models
– Types of analysis for reviews: best for static
analysis and scenario-based
– Automation: Reviews and Inspections are manual
– Stakeholders: all stakeholders may participate
Architectural Trade-Off Analysis Method
(ATAM) method may be used for Review/Inspection
Business
Drivers: goals;
major functions;
constraints; etc.
Quality Attributes:
scalability, security,
etc.
Key Facets of
Architecture:
major decisions &
major constraints
Architectural
Approaches:
styles, patterns,
further refinements
Scenarios: growth,
use-case, etc.
Architectural
Decisions
Trade-offs
Sensitivity
points
Risk “themes”
Non-risks
Iterate until the
“risks” are mitigated
Risks
Analysis
(B) Model Based Analysis of Architecture
• Relies on the system’s architectural descriptions in the
model and the manipulation of that model to discover
properties of the architecture:
– Goals for model-based analysis: consistency, internal
completeness, correctness
– Scope of the model-based analysis: spans components,
connectors and the complete system; also includes dataexchange and compatibility to standards, etc.
– Concerns of analysis include: mostly structural; some
behavioral, interaction, and non-functional
– Types of Model used for analysis are: mostly semi-formal to
formal; the more formal models tend to be more useful
– Types of Analysis with model-based: best for static analysis of
connectivity, conformance, interface, definition-usage, etc.
– Automation: typically partially automated
– Stakeholders: targeted at technical stakeholders
e.g. Model-Based Reliability Analysis
• Reliability definition:
Reliability is the probability that the system will perform its
intended functionalities without failures
for a specified amount of time.
• There are many reliability models that will allows us to
measure and “predict”:
– Mean time between failures
– Time to next failure
– Time to repair
• There are lots of reliability models, almost all “formal”
and some based on negative exponential and/or Poisson
model :
P(Z=a) = [ ( e–δ δa) /a! ] where δ is the expected value of Z
( C ) Simulation Based Analysis
• This is basically software simulation of the
architecture model and may be used for:
– Any of the goals: completeness, consistency, compatibility
and correctness analysis
– Scope of the analysis may be: the entire system, a specific
subsystem, data-exchange, comparing architectural behavior
or against standard
– The Concerns that can be simulated include: behavior,
interaction, non-functional properties
– The simulation Model most likely need to be “formal”
– The Type of Analysis made with simulation is dynamic and
scenario based
– These are mostly Automated and computer execution based.
– Stakeholders: all stakeholders may be interested