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.
Enter the password to open this PDF file:
File name:
-
File size:
-
Title:
-
Author:
-
Subject:
-
Keywords:
-
Creation Date:
-
Modification Date:
-
Creator:
-
PDF Producer:
-
PDF Version:
-
Page Count:
-
Preparing document for printing…
0%
Σχόλια 0
Συνδεθείτε για να κοινοποιήσετε σχόλιο