Analysis of Architecture

• As part of the activities in coming up with a good software architecture, we should analyze the architecture that we have designed and modeled.

Architectural analysis is the activity of discovering (and organizing/assessing) important system properties using the system’s architectural models.

my addition

Dimensions of (or things to consider for) Architectural Analysis

1. Goals of analysis

2. Scope of analysis

3. Concerns to be analyzed

4. Models and levels of formality

5. Types of analysis

6. Levels of automating the analysis

7. Stakeholders interested in analysis

8. Analysis techniques

Goals of Analysis

• 4 categories of goals for analysis of the architecture:

1. Completeness

2. Consistency

3. Compatibility

4. Correctness

5. Cohesiveness

6. CouplingI would add these 2 more

1. Architectural Completeness• Completeness with respect to external concerns:

– Checking the architecture against the requirements• Functional • Non-functional

– Difficult to do when the system is large due to massive amount of material

– Difficult to do when pieces are specified and designed incrementally (choosing the right moment for assessment)

• Completeness with respect to internal concerns:– Checking to see if all the system’s elements are captured

• Components• Connectors• Interface and protocols• Dependencies• Interactions

system configuration

e.g. agile

2. Architectural Consistency• Internal property of the architecture which states that the

architectural elements do not contradict each other

– Name inconsistencies• May be difficult to catch in incremental design and distributed

design when not everything is there and can change– Interface inconsistencies

• Watch for polymorphism and overloading versus real problem– Behavioral inconsistencies

• Watch for typing such as “difference” may represent arithmetic subtraction of two integers versus number of mismatched characters in two strings (semantic confusion)

– Interaction Inconsistencies• These can occur when the protocol is not clear such as “sequence

of interaction” between two entities especially in a stateful situation.– Refinement Inconsistencies

• This may occur when moving from high level to lower level design and loosing something, or adding something extra, or violate some constraint ---- especially if you use multiple - views

3. Architectural Compatibility

• Compatibility is an external property of the model to ensure that the architecture adheres to:– Architecture & Design Standard– Constraints of the adopted Architecture style– Constraints imposed by the reference architecture

(reference architecture is an architecture that is applicable to multiple related systems within an application with explicitly defined points of variation)

This may be more difficult than it appears because the external standards, style,and reference architecture may all be unclear or not completely defined,

4. Architectural Correctness

• Correctness is an external property of the model that addresses if the external system specification is properly realized in the architecture. (includes completeness?)

Have we “properly” evolved from the specification to the architectural model ?

This is especially difficult to analyze when

we use off-the-shelf components which are not perfect match and needs some “tailoring” work.

Cohesion and Coupling

• Two additional characteristics of the architecture that we like to be able to assess as “goals” of analyzing architecture.

– Cohesion : does the architectural components fit together cleanly with minimal overlap and little extra elements? (component level cohesion)

– Coupling: does the architectural components and connectors have excessive interactions? (component level coupling)

Scope of Analysis

• Architecture may be analyzed at different levels or from different perspectives. Scope of analysis may address:

o Component and Connector level analysiso Subsystem and System level analysiso Data exchanges in the System or Subsystemo Different levels of Abstractiono Comparison of two or more Architectures

Component and Connector Level

• Each component and each connector needs to be analyzed– Does it provide the specified service– Does it do it correctly (in the intended manner)

• The composition of components and connectors– Does the composition provide the intended

services– Does the composition work correctly

Subsystem and System Level • At the subsystem and system level, we are analyzing the

compositions of components and connectors to form a subsystem and then to form a complete system.

– Pair-wise conformance of 2 interacting components in terms of their interface, interaction and behavior is analyzed within the subsystem.

– Assessing over-all properties as subsystems are incrementally built and the over-all system continue to evolve

• Interesting situation is where off-the-shelf components are configured where there may be need for “additional” functionalities but causing potential degradation in some less acute property (e.g. to improve security, we bring in security guarding components such as extra “walls” and encryption --- which may affect overall execution performance or system maintenance)

• System scalability is a critical property as larger and larger heterogeneous subsystems are configured together

Data Exchange Level

• In most large or distributed systems, there is large amount of data processed and exchanged (e.g. web-based applications). It is important that data is properly modeled:– The structure of data

• Data typing• Data organization

– Flow of the data through the system• Point-point• Client-server• Event based broadcast• etc

– Properties of data exchanges• Performance• Security• Stateful vs stateless• etc

Different Abstraction Levels

• As we refine the architecture and the model, it is important that we ensure the compatibility of the models at different levels. That is the refined models stay consistent with the higher levels. This is especially difficult if different components and subsystems are modeled to different levels of refinement.

Component C

Component B

Component A

Component A

Component C

Component B

refinement

Comparing Architectures

• We are interested in comparing and ensuring that an “evolving” system has :

– not altered from the base architecture or the reference architecture

– Stayed within the bounds of some architectural / design standard

(looking for both “drift” and “erosion”)

• In comparing architectures, we are looking at:1. Composition of components and connectors

2. Interactions among components and connectors

3. Characteristics of data exchange

Architectural Analysis “Concerns”

• In analyzing architectures we are interested in several “key concerns”:– Structural Characteristics (static)

• Connectivity of components and connectors• Lower level components contained into higher level composite

component• Points of network distribution and concurrency paths

– Behavioral Characteristics (static)• Individual component and connector functionalities• Composite and collaborative functionalities (especially when

composed with off-the-shelf components or connectors)

– Interaction Characteristics (dynamic)• Number and type of connectors and protocols among

components and connectors• Properties such as timing, synchronicity, buffering, etc.

– Non-functional Characteristics (static & dynamic)• Properties that cut across the whole system or subsystems such

as security, performance, quality, etc.

heavy

overlap

Levels of Formality & Analysis

• The level of formality in analysis requires certain level of formality in the architectural models which we use in the analysis:

– Informal (box-line) models allow only high level analysis but by a broad sector of stakeholders. Often times the analysis is performed manually with little automation.

– Semi-formal models, such as UML, allows a deeper level of analysis by those trained to understand that semi-formal model. The amount of training required is not formidable, thus allowing more stakeholders to participate in the analysis. Also allows partial automation of the analysis activity

– Formal models , such as Wright or Acme, requires understanding of the formal syntax and semantics used in the model; thus it restricts the number of stakeholders who can participate in the analysis, but does allow better automation and deeper analysis.

Types of Analysis

• Static Analysis– Analyzing the architectural model without executing any part of

the model– Concerns analyzed are mostly structural, with little other kinds

of concerns analyzed –

• Dynamic Analysis– Involves executing or simulating the execution of the

architectural model– Major concerns analyzed are behavior and interaction

properties, with some non-functional properties

• Scenario-Based or Work-flow Based Analysis– Very good for some specific non-functional concern that cuts

across the whole system.

Levels of Automation

• A more detailed and formal architectural model is more amenable to automation

• A more well “defined” and “quantifiable” property is the more it may be assessed automatically

• 3 Levels of Automation:– Manual ---- mostly qualitative & may not be easily duplicated – Partially automated --- using some tools to look for evaluating

syntactical conformance or for counting the numbers or for evaluating some property

– Fully automated --- only in well-definable areas such as syntactical conformance; most likely not achievable

Stakeholders and Architectural AnalysisStakeholders Architectural

GoalsArchitectural Concerns

Level of Formality / Types of Analysis

Architect -completeness

-consistency

-compatibility

-correctness

-structural

-behavioral

-interaction

-non-functional

-all levels (informal, semi-formal & formal) of arch. models

-all types (static, dynamic & scenario) of analysis

Developers -consistency

-compatibility

- completeness

- correctness

-behavioral

-interaction

- semi formal & formal model

-internal static & dynamic

Managers -completeness

-correctness

-non-functional

-structural/behavior

-informal

-some scenarios

Customers -completeness

-correctness

-all concerns at high level

-informal level

-mostly scenario

Vendors -compatibility -structural (composibility)

-interaction

-informal & formal

-static & scenario

Some Analysis Techniques

(A) Analysis via Reviews and Inspections

(B) Model Based Analysis

(C) Simulation Based Analysis

(A) Reviews and Inspections of Architecture

• Reviews and inspections are human based activities that require:

– 1) preparation for inspection and of architectural material • Think through material discussed earlier such as :

– Set goals for analysis of the architecture– Set the scope of the analysis– Decide on the concerns– etc.

– 2) preparation of participants (stakeholders)– 3) review/analysis of the architectural material– 4) analysis of the review results and recommend actions– 5) follow-up and closeout

Reviews and Inspections of Architecture• Depending on the context, reviews and

inspections may have the broadest spectrum:– Goals: completeness, consistency, correctness, and

compatibility – Scope: spans components, connectors and the

complete system; also includes data-exchange and compatibility to reference architecture and compliance to standards , etc.

– Concerns of reviews may include: structural, behavioral, interaction and non-functional

– Types of model used for analysis are: mostly semi-formal; many stakeholders may not understand or appreciate the formal models

– Types of analysis for reviews: best for static analysis and scenario-based

– Automation: Reviews and Inspections are manual– Stakeholders: all stakeholders may participate

Architectural Trade-Off Analysis Method(ATAM) method may be used for Review/Inspection

BusinessDrivers: goals; major functions;constraints; etc.

Quality Attributes:scalability, security,

etc.

Scenarios: growth,use-case, etc.

AnalysisArchitecturalDecisions

Key Facets ofArchitecture:

major decisions &major constraints

ArchitecturalApproaches:

styles, patterns,further refinements

Trade-offs

Sensitivity points

Non-risks

Risks

Risk “themes”

Iterate until the “risks” are mitigated

(B) Model Based Analysis of Architecture

• Relies on the system’s architectural descriptions in the model and the manipulation of that model to discover properties of the architecture:– Goals for model-based analysis: consistency, internal

completeness, correctness – Scope of the model-based analysis: spans components,

connectors and the complete system; also includes data-exchange and compatibility to standards, etc.

– Concerns of analysis include: mostly structural; some behavioral, interaction, and non-functional

– Types of Model used for analysis are: mostly semi-formal to formal; the more formal models tend to be more useful

– Types of Analysis with model-based: best for static analysis of connectivity, conformance, interface, definition-usage, etc.

– Automation: typically partially automated– Stakeholders: targeted at technical stakeholders

e.g. Model-Based Reliability Analysis• Reliability definition: Reliability is the probability that the system will perform its

intended functionalities without failures for a specified amount of time.

• There are many reliability models that will allows us to measure and “predict”:

– Mean time between failures– Time to next failure– Time to repair

• There are lots of reliability models, almost all “formal” and some based on negative exponential and/or Poisson model :

P(Z=a) = [ ( e–δ δa) /a! ] where δ is the expected value of Z

( C ) Simulation Based Analysis

• This is basically software simulation of the architecture model and may be used for:

– Any of the goals: completeness, consistency, compatibility and correctness analysis

– Scope of the analysis may be: the entire system, a specific subsystem, data-exchange, comparing architectural behavior or against standard

– The Concerns that can be simulated include: behavior, interaction, non-functional properties

– The simulation Model most likely need to be “formal”– The Type of Analysis made with simulation is dynamic and

scenario based– These are mostly Automated and computer execution based.– Stakeholders: all stakeholders may be interested