architectural analysis. introduction models help to force the architects to identify issues that...

Architectural Analysis

Introduction

• Models help to force the architects to identify issues that might missed or ignored

• To get useful information precisely from specific model helps in identifying incorrect decisions before they get propagated to implementation phase

• Identifying these aspects from model is architectural analysis

• Stakeholders need to know how to extract those details

Definition

• Architectural Analysis: It is the activity of discovering important system properties using the system’s architectural models.

• Important to know1. which questions to ask2. why to ask them3. how to ask them4. how to ensure that they can be answered

• Informal architectural models help in identifying scope and goal of architecture

• Helpful for getting customer clarification, help managerial level

• Formal or rigorous models are more advantageous• They provide detail information about

implementation level, helps in automated code generation. Helpful for developer.

• These models are not helpful in communication with non technical people

Concerns Relevant to Architectural Analysis

• Goals of analysis (why)• Scope of analysis (what)• Primary architectural concern being analyzed• Level of formality of architectural models• Type of analysis• Level of automation• System stakeholders interested in analysis

5

Analysis Goals

• Analysis of software model can have several goals• These goals may include early estimation of

system’s size, complexity, cost; satisfaction of system requirements; correctness of system as per requirements

• These goals are categorized in 4 categories:– Completeness– Consistency– Compatibility– Correctness

Completeness

• Completeness can be external or internal• External goal is with respect to system’s requirements• Whether it captures system’s key functional and non

functional requirements• Architecture centric systems are complex, dynamic in

nature• In these complex systems capturing requirements and

modeling are also complex and done using various notations of various levels of rigor and formality

• System’s engineers need to carefully select the points at which external completeness can be assessed meaningfully

• Analyzing internal completeness include checking whether all the elements have been fully captured

• Have all elements properly modeled?• Have all design decisions properly captured?• Syntactic and semantic rules of notations• Checking if Everything is captured in models is

completeness

Completeness

Consistency

• Consistency is an internal property of the system• Goal of consistency is different elements of the model do not

conflict with each other• Software system and their architectural models are complex

and multifaceted which inadvertently introduce inconsistency• Examples of inconsistency:

– Name Inconsistency– Interface Inconsistency– Behavioral Inconsistency– Interaction Inconsistency– Refinement Inconsistency

• Name inconsistency– It appears at the level of components and connectors– Components and connectors having same name or the services

exported by a component have same name– At programming level identifying name inconsistency is easier e.g.

variables with same name are not accepted, trying to use function name which is a name of inbuilt function

– At documentation level it is difficult to identify name inconsistency– Architecture is highly adaptable and dynamic. One component or

service present at one level may be not in use at next point of time and might be available after some time

– Managing this is difficult task

Name Inconsistency

• Interface Inconsistency: interface inconsistency encompass name inconsistency.

• Name inconsistency is subset of interface inconsistency

• Component’s required service may have same name as another component’s provided service but parameter list, return type are different

• Consistency in terms of interface is not present

Interface Inconsistency

• Inconsistency in terms of behavior of the system.

• The name of the required service is same as service provided by other component, data type, return type that is interface are also same but behavior is different

Behavioral Inconsistency

• Interaction inconsistency: Name, interface, behavior matches but still the components are not able to interact properly

• This may occur because of violating certain constraints like the order in which the service or component should be extracted

• Refinement inconsistency: inconsistency at multiple levels of abstraction

Interaction & refinement Inconsistency

Compatibility

• It is an external property of the system• It ensures that model is according to guidelines and

constraints of style, reference architecture and an architectural standard

• Models captured Strictly according to rules are compatible• Checking compatibility with Semiformal or informal

guideline is challenging • Checking compatibility with reference architectures is easy

as they are specified formally using ADL• Checking compatibility with styles is difficult and

challenging

Correctness

• This is external property of the system• The systems architecture is said to be correct

with respect to an external specification if the architectural design decisions fully realize those specifications

• Captures all design decisions with their exact meaning

Scope of Analysis

• A software system’s architecture can be analyzed from different perspectives and at different levels

• Scope tells what will be analyzed• Components, connectors, ports can be analyzed• Mostly architects are interested in composition,

configuration of the system• Scope can be at lower level where all small elements

will also be analyzed or at higher level where structures or compositions are being analyzed

• Component and connector level analysis:– Simplest and basic level of analysis– Components and connectors are created to provide specific services– Components: application specific functionality and connectors:

application independent functionalities– Analyze these elements provide expected services– Mostly architects are interested in composition of connectors and

components– Components and connectors are analyzed to identify basic

inconsistencies. It doesn't ensure system’s correct working– Interface can be inspected if any service is missing from expected

services

Scope of Analysis

• Subsystem and system level analysis:– Components and connectors desired properties does not guarantee about

composition of them will behave as expected– Interplay of components and connectors can be complex– This analysis can be done at a whole system level or incrementally by

focusing on particular subsystem– Most manageable level is pair-wise conformance. Two interacting

components are considered at a time and name, behavior, interface conformance is done

– Then take set of components interacting probably through single connector

– And then to higher level of subsystem is analyzed – Example: Data encryption component is intended to provide data security

with data compression component with communication efficiency

Scope of Analysis

• Data exchange in a system or subsystem:– In large, distributed systems, large amount of data are

processed, exchanged and stored– Data intensive systems appear in wide range like scientific

computing ,many web based applications, e-commerce and multimedia

– In such system along with basic components, it is important to ensure that the system’s data is properly modeled, implemented and exchanged among the structural elements.

– Structure of data, flow of data through the system, properties of data exchange

Scope of Analysis

• Architectures at different levels of abstraction:– During the process of architecture creation, architects address

most critical issues first, and then introduce additional elements into the architecture

– Lastly refine the architecture to include additional details– High level architecture includes overview and lower level

architecture includes details– Abstraction is done at proper level or not is analyzed– Sometimes components are more abstract and the properties

can not be understand well, whereas sometimes abstraction is at very low level

– It has to be verified if it is done at required level or not

Scope of Analysis

• Comparison of two or more architectures:– It is important to understand the relation of

architecture with the baseline architecture– Verifying compliance of architecture with

reference architecture– This the highest scope of analysis– Complete Architecture is analyzed, whether it is

compatible with provided standards, style or reference architecture

Scope of Analysis

Architectural Concerns Being Analyzed

• Architectural techniques analyzes different features of the system

• In practice given analysis technique or suite of techniques focuses more than one architectural concern at a time

• Different features can be:– Structural characteristics– Behavioral characteristics– Interaction characteristics– Non functional characteristics

• Structural characteristics: – Concerns such as connectivity among components and connectors,

containment of lower level architectural elements with higher level elements are analyzed

– Example: missing pathway between components which want to interact, component or subsystems that are disconnected from the rest of architecture

• Behavioral characteristics:– Individual level behavior is analyzed, where every components

behavior is verified– System level behavior is analyzed, where system as a whole is

behaving properly or not is verified


• Interaction characteristics: – Interaction protocol is analyzed– Component interacting through appropriate connector or not is

verified

• Non-functional characteristics:– Forms critical dimensions of almost all software systems– Not properly understood because of their informal nature– Whether all these characteristics are modeled properly is verified


Level of Formality of Architectural Models

• Informal Models– Captured in boxes-lines, diagrams– High level picture of the system– Analyzed manually by stakeholder or non technical

people – Have to be analyzed casually

• Semiformal Models– Most architectural models are semiformal in

nature– Syntax is defined formally semantic informally– Notations need to maintain balance between high

degree of precision and formality on one hand and expressiveness and understandability on other

– UML notations– Partial imprecision makes it difficult to analyzed


• Formal Models– Formally defined syntax and semantics– Wright– Formal, automated analysis can be done– Intended for technical stakeholders– Scalability problem and painstaking


Type of Analysis

• Static Analysis: – Checking properties of model without executing it– It can check syntax of the system– It can be automated or manual– Automated: compilation– Manual: inspection

• Dynamic Analysis:– Actual execution or simulation of the system– Simulation is dynamic analysis of system where the

actual system model is constructed

• Scenario-Based Analysis:– For complex systems which are very large, specific

use cases are selected– This is a combination of static and dynamic

analysis– Analyses system statically or dynamically based on

the scenario

Type of Analysis

Level of Automation

• Different architectural analysis techniques are present at different level of automation

• Level of automation depends on several factors including formality, completeness etc

• More formal model is more capable for automated analysis

• Different level of automation are:– Manual– Partially Automated– Fully Automated

• Manual: – Human involvement is required– Expensive– Inspection based techniques

• Partially automated:– Most popular– Involves both manual and automated analysis

• Fully automated:– Done completely by s/w tools, no human involvement required– Most of the models are semiformal in nature hence this

technique individually can not work

Level of Automation

System Stakeholders

• Different stakeholders have different objectives• All stakeholders have different angles and different

purpose of work, analysis done by all is also different

• Stakeholders: – Architect– Developer– Manager– Customer– Vendor

• Architects: – Global view and considers all 4 C’s– Prefer automated analysis techniques– Rely on partial and manual techniques also

• Developers:– Limited view of architecture is considered– Modules or subsystem for which they are directly

responsible– Do not bother about completeness– Focus on consistency of their module with other

System Stakeholders

• Manager:– Interested in compatibility and completeness – They are concerned about system’s external properties

• Customer:– They are interested in systems Completeness and

correctness– System’s overall working

• Vendors:– Vendors sell individual components and connectors rather

than the whole system– They are usually interested in compatibility of the system

System Stakeholders

Analysis Techniques

• Large number of techniques are available• These techniques are divided into three

categories– Inspection and review based– Model based– Simulation based

Inspection and Review Based

• These are usually code analysis techniques• Reviews and inspection is conducted by different

stakeholders to ensure different properties of the system• Different views are inspected for specific properties• In architecture review board, all stakeholders defines the

objective of analysis• Stakeholder in review board decides goal and scope of

analysis along with other dimensions • These are manual analysis and hence expensive• Useful in informal or semiformal models

• Goal: It can have any of 4 goals, 4 C’s• Scope: nothing specific. Stakeholders may be

interested in component and connector level or system level. Scope can be data exchange or level of abstraction

• Concerns: well suited for non functional type of properties where manual interpretation is required. structural, behavioral and interaction concerns are difficult to analyze manually.


• Level of formality: Informal models can be best analyzed. Highly formal models are not useful to non technical stakeholders. But they can be analyzed by technical stakeholders

• Type of analysis: Static and scenario based• Automation level: Manual obviously• Stakeholders: All stakeholders participate in

inspection and review except vendors


Architectural Trade-off Analysis Method

• It was designed to identify risk in software design at early phase of the development cycle

• ATAM mainly focuses on quality attributes or non functional properties

• Gathering of software architects, other stakeholders and evaluation team is required

• The ATAM gets its name because it not only reveals how well an architecture satisfies particular quality goals, but it also provides insight into how those quality goals interact with each other—how they trade off against each other.

• The whole process take 3-4 days

Business Drivers

Quality Attributes

Scenarios

S/W Architecture

Arch Approaches

Arch Decisions

Trade-Off

Sensitivity Points

Non-Risk

RiskRisk Themes

Analysis


• Two major inputs are business drivers and system’s software architecture

• Project decision makers (mostly manager and customer) presents business drivers

• Business drivers includes:– System’s critical functionality– Any technical, managerial, economical or political constraints– The projects business goals and context– The major stakeholders– The principal quality attribute (NFP) goals that impact and

shape the architecture


• The quality attributes identify and categorize business drivers into representative scenario– Use case scenario: describes how system is seen– Growth scenario: describes how the modification or

changes are described– Exploratory scenario: establish limits of adaptability

• These scenarios are prioritized in terms of importance by the system’s stakeholders

• Another thread involves software project’s architecture


• Projects architecture includes:– Technical constraints = hardware platform, O.S.,

middleware, programming languages– Architectural approach: refers to any other set of

architectural design decisions made to solve the problem at hand. Typically styles and pattern

• Based on the answers the category will be decided like risk, no risk, sensitivity point or trade-off


Model Based Analysis

• Solely rely on system’s architectural description and manipulate that description to discover properties of architecture

• techniques involve analysis tools which are guided by the architects

• Much less human intensive hence less costly• Only hard properties can be analyzed which can be

encoded in a model• Properties which has to be understood from

available information can not be analyzed

• Model based techniques can not handle soft aspects like rationale or intent of architecture

• Focus on single specific facet of the system’s architecture

• It is not scalable• Goal: Consistency, compatibility and internal

completeness. It does not include external completeness and correctness

• Does not provide all the needed answers to an architect and couple with techniques from two other categories


• Scope: Span can be component and connector level to whole system level

• Concerns: structural, behavioral and interaction properties. Analyzing behavioral and interaction properties it takes help of simulation based technique

• Type of Models: Formal models are best analyzed. Informal models are not specifically of any use.


• Type of Analysis: static analysis. Works on architectural description

• Automation level: partially automated is minimum requirement. Fully automated is best suited

• Stakeholders: technical stakeholders namely architects and developers


Simulation Based Analysis

• It requires dynamic executable model of a given system or of a part of a system

• Simulation need not produce similar results as of execution

• Results of simulation are ranges rather than a particular value

• Goal: goal can be any of 4 C’s. but with limited confidence

• Scope: usually entire system or a particular subsystem. Lover level analysis is possible but usually not preferable

• Concerns: behavioral and interaction concerns are best analyzed

• Level of formality: formal models are expected• Type of Analysis: dynamic or scenario based• Level of automation: fully automated• Stakeholders: all type of stakeholders can take

participation, but technical expertise are needed of setting up the analysis

Simulation Based Analysis

architectural analysis. introduction models help to force the architects to identify issues that...

Documents

systems architectural

informal architectural

complex systems

rigorous models

internal completeness

external completeness

systems requirementswhether

systems key functional