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