Chapter 08c -- Analysis -- Jonathan McCraryx

basicgratisΜηχανική

5 Νοε 2013 (πριν από 4 χρόνια και 7 μέρες)

90 εμφανίσεις

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.