chapter 8 analysis
DESCRIPTION
Chapter 8 Analysis. Zachary Cleaver. Analysis Definition and Purpose. Architectural analysis is the activity of discovering important system properties using the system’s architectural models. - PowerPoint PPT PresentationTRANSCRIPT
Chapter 8 AnalysisZachary Cleaver
Analysis Definition and PurposeArchitectural analysis is the activity of
discovering important system properties using the system’s architectural models.
Architectural analysis helps identify incorrect/inefficient design decisions, clarifies component functions and objects, and aids in communication between designers and customers.
Facets of Architectural Analysis1) Goals of analysis2) Scope of analysis3) Primary architectural concerns being
analyzed4) Level of formality between models
Facets of Analysis: Goals1) Completeness2) Consistency3) Compatibility4) Correctness
CompletenessThe main goal of assessing an architecture’s
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.
ConsistencyDefinition: 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:NameInterfaceBehavioralInteractionRefinement
Name InconsistencySame-name components providing similar
services. Is the right one being used?
Accessing a nonexistent class or method resulting in compile-time errors
Interface InconsistencyReqInt: 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;
Behavioral InconsistencySubtract(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)
Interaction InconsistencyOccurs when a component’s provided
operations are accessed in a manner that violates certain interaction constraints.
Ex. pop_back() in c++
Refinement InconsistencyRefinement inconsistencies stem from a
system’s 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.
CompatibilityCompatibility ensures that the model adheres
to the design guidelines imposed by an architectural style, reference architecture, or architectural standard.
CorrectnessCorrectness 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.
Scope of AnalysisComponent and Connector LevelSubsystem and System LevelData Exchanged in (sub)systemArchitectures at Different Abstraction LevelsComparison of Two or More Architectures
Component and Connector Level AnalysisEnsures the given component or connector
provides the services expected of itHowever, this does not ensure services are
modeled correctlyChecks name consistency
Subsystem and System Level AnalysisPair-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)
Petry’s “Honey-baked ham” syndrome
Data Exchanged in the System or Subsystem
Assess data elements to ensure the system’s data is properly modeled, implemented, and exchanged among structural elementsStructure of the data (typed vs. untyped)Flow of data through the system (point-to-point
vs. broadcast)Properties of data exchange (consistency,
security, etc.)
Architecture at Different Abstraction Levels
A
B
C
D
Comparisons of Two or More ArchitecturesComparing current architecture to a model of
the desired architectureComparing two architectures for properties
such as processing and storage capabilities
Architectural Concern Being AnalyzedStructural CharacteristicsBehavioral CharacteristicsInteraction CharacteristicsNon-functional Characteristics
Structural CharacteristicsDetermines whether the architecture is well
formedFocuses 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.
Behavioral CharacteristicsConcerned 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
Interaction CharacteristicsHelps to establish whether the architecture
will actually be able to fulfill some of its requirements (efficiency)
Concerned with internal behaviors of systems (security)
Non-Functional CharacteristicsDifficult to assess since they can span
multiple components and connectorsTheir definitions can be much more informal,
making it difficult to properly understand them in the architecture
Level of Formality of Architectural ModelsInformalSemiformalFormal
Informal ModelsTypically captured in box-and-line diagramsGreat for showing high-level representations
of a systemCan be dangerous to use because of a lack of
information and an ambiguous nature
Semiformal ModelsAims to be useful to both technical and
nontechnical stakeholdersUML
Formal ModelsDesigned for technical stakeholdersThese type of models can suffer from
scalability problems