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.Coupling I 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 analysis o Subsystem and System level analysis o Data exchanges in the System or Subsystem o Different levels of Abstraction o 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 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 Analysis Stakeholders Architectural Goals Architectural 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 Business Drivers: goals; major functions; constraints; etc. Quality Attributes: scalability, security, etc. Scenarios: growth, use-case, etc. Analysis Architectural Decisions Key Facets of Architecture: major decisions & major constraints Architectural Approaches: 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