architectural analysis. introduction models help to force the architects to identify issues that...
TRANSCRIPT
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
Architectural Concerns Being Analyzed
• 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
Architectural Concerns Being Analyzed
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
Level of Formality of Architectural Models
• Formal Models– Formally defined syntax and semantics– Wright– Formal, automated analysis can be done– Intended for technical stakeholders– Scalability problem and painstaking
Level of Formality of Architectural Models
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.
Inspection and Review Based
• 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
Inspection and Review Based
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
Architectural Trade-off Analysis Method
• 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
Architectural Trade-off Analysis Method
• 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
Architectural Trade-off Analysis Method
• 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
Architectural Trade-off Analysis Method
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
Model Based Analysis
• 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.
Model Based Analysis
• 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
Model Based Analysis
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