Chapter 08c -- Analysis -- Jonathan McCraryx

Software Architectures
–

Chapter 8
3/10/2011 5:12:00 AM

–

Jonathan McCrary

8.8
–

Analysis Techniques



8.8.1
–

Inspections and Reviews

–

Page 317

o

Architectural inspections and reviews are conducted by different
stakeholders to ensure a variety of properties in an architecture.

o

Advantages



Useful in the case of informal or partial
architectural
descriptions.



They can simultaneously take into account the objectives of
multiple system stakeholders and consider multiple desired
architecture properties

o

Disadvantages



They are manual analysis techniques so they can be expensive.

o

Goals



Com
pleteness, consistency, compatibility, correctness

o

Scope



Varies: meet
s

any of the scope attributes as needed

o

Concern



Varies, but is b
est suited for establishing certain non
-
functional
properties
, especially those that require some interpretation and
consen
sus reaching by the human stakeholders

o

Models



Best suited for informal and semi
-
formal models

o

Type



Static and scenario based

o

Automation Level



Manual

and very human intensive

o

Stakeholders



Architects, developers, managers, customers

o

ATAM

–

Page 320

–

See Figure 8
-
12



Architectural Trade
-
Off Analysis Method



Is a human
-
centric process for identifying risks



Focuses specifically on the quality attributes, or non
-
functional
properties (NFPs), of modifiability, security, performance, and
reliability



Key
inputs



Business drivers



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)



Software architecture



Technical
constraints



Any other systems



Architectural approaches

o

Any set of architectural design decision
made to solve the problem at hand.



Outputs



Trade
-
off points



Sensitivity points



Non
-
risks (strengths)



Risks (weaknesses)



Fed back into the system until

properly

mitigated



Goals

=
Completeness
, c
onsistency
, c
ompatibility
, c
orrectness



Scope

=
Subsystem
-

and system
-
level
, d
ata exchange



Concern

=
Non
-
functional



Models

=
Informal
, s
emiformal



Type

=
S
cenario
-
driven



Automation Level

=
Manual




Stakeholders

=
Architects
, d
evelopers
, m
anagers
, c
ustomers



8.8.2
–

Model
-
Based Analysis

–

Page 322

o

Model
-
based architectural analysis techniques rely solely on a
system’s architectural description to discover properties of the
architecture.

o

Advantages



Much less

human intensive and le
ss costly than inspections and
reviews
.

o

Disadvantages



Can only be used to establish “hard” proper
ties of a system’s
architecture
—
those properties that can be encoded in the
architectural model
. Cannot easily account for implicit
properties.



Cannot typical
ly assess “soft” aspects such as design intent and
rationale.

o

Scalability



Architects may be able to arrive at highly precise analysis
results with a high degree of confidence in those results for
smaller systems, but would have to sacrifice that precision
and
confidence for larger systems
.

o

Goals



Consistency, compatibility, and internal completeness



Can include external completeness and correctness

o

Scope



Varies: meet
s

any of the scope attributes as needed

o

Concern



Varies: focused on structural, behavioral, or

interaction
properties

o

Models



More formality yields more meaningful results. Usually the
architectural models to which sophisticated analysis tools are
applied have formally specified syntax as well as semantics.

o

Type



Static analysis

o

Automation Level



At
least partially automated



Often fully automated, requiring no human intervention

o

Stakeholders



Usually targets technical stakeholders, such as architects and
developers

o

Model
-
Based Analysis Enabled by ADLs (Architecture Description
Languages)

–

Page 324
-
325



Wright



Uses communicating sequential processes, or CSP, to
analyze a system’s connectors and the components
attached to them for deadlocks.



Aesop



Ensures style
-
specific topological constraints and type
conformance among architectural elements.



MetaH and U
niCon



Support schedulability analysis by specifying non
-
functional properties, such as the criticality and priority of
components.



Language parsers and compilers are another kind of analysis
tools. Parsers analyze architects
for syntactic correctness,
while compilers establish semantic correctness.



Goals

=
Consistency, compatibility, completeness (internal)



Scope

=
Component
-

and connector
-
level, subsystem
-

and
system
-
level, data exchange, different abstraction layers,
architecture comparison



Concern

=
Structural, behavioral, interaction, non
-
formal



Models

=
Semiformal, formal



Type

=
Static



Automation Level

=
Partially automated, automated



Stakeholders

=
Architects, developers, managers, customers

o

Reliability Analysis

–

Page 326
-
327



A software system’s
r
eliability

is the probability that the system
will perform its intended functionality under specified design
limits, without failure.



A
failure

is the occurrence of an incorrect output as a result of
an input value that is received,
with
respect to the
specification.



An
error
is a mental mistake made by the designer or the
programmer.



A
fault

or a
defect

is the manifestation of that error in the
system.



Reliability can be assessed using several metrics:



Time to fail
: mean time until a system fails after
its last
restoration.



Time to repair
: mean time until a system failure is
repaired after its last failure.



Time between failures
: mean time between two system
failures



Engineers need not, and should not, wait to estimate the
reliability of a system until t
he system has been implemented
.



Reliability values obtained at the level of architecture should not
be treated as absolute values, but should instead be qualified by
the assumptions
, such as the presumed operational profile,
made about the system.



Goals

=
Consistency, compatibility, correctness



Scope

=
Component
-

and connector
-
level, subsystem
-

and
system
-
level



Concern

=
Non
-
functional



Models

=
Formal



Type

=
Static, Scenario
-
based



Automation Level

=
Partially automated



Stakeholders

=
Architects, managers, c
ustomers, vendors



8.8.3
–

Simulation
-
Based Analysis

o

Simulation requires producing a dynamic, executable model of a given
system, or of a part of the system that is of particular interest, possibly
from a source model that is otherwise not executable
.

o

Simul
ation need not produce identical results to the system’s
execution: The source model, such as an architectural model, may
elide many details of the system.

o

Goals



Completeness, consistency, compatibility, correctness

o

Scope



Usually at the s
ubsystem
-

and
system
-
level

and
data exchange
,
but can support c
omponent
-

and connector
-
level

and
different
abstraction layers

o

Concern



Behavioral, interaction, and non
-
functional properties

o

Models



Must be formal

o

Type



Dynamic and scenario
-
based analysis

o

Automation Level



Fully automated, requiring no human intervention

o

Stakeholders



Useful for all system stakeholders

o

XTEAM



eXtensible Tool
-
chain for Evaluation of Architectural Models



A model
-
driven architectural description and simulation
environment for mobile and resource
-
constrained
software systems.



XTEAM builds an architectural meta
-
model. This meta
-
model is
augmented with finites state processes, or FSP, which allow the
specification component behaviors.



When invoked by an architect, the XTEAM interpreter
framework
traverses the architectural model, building up a
discrete event simulation model in the process.



XTEAM implements simulation based analysis capabilities fro
end
-
to
-
end latency, memory utilization, component reliability,
and energy consumption.



Goals

=
Cons
istency, compatibility, correctness



Scope

=
Component
-

and connector
-
level, subsystem
-

and
system
-
level, data exchange



Concern

=
Structural, behavioral, interaction,
non
-
functional



Models

=
Formal



Type

=
Dynamic, scenario
-
based



Automation Level

=
Automated



Stakeholders

=
Architects, developers, managers, customers,
vendors

8.9
–

End Matter



A major part of what makes good architectural practice is deciding what one
wants out of the architecture.



System stakeholders should decide on the specific benefits they

want to gain
from the explicit architectural focus.



It is critical to make sure that the system possesses the key required
properties and does not have or is reasonably unlikely to have undesirable
characteristics.



Architectural analysis is neither easy

nor cheap
—
it should be planned for and
applied carefully.