Architecture Analysis Techniques

Architecture Analysis Techniques

Ding Li

2927154806

Review

Inspections and Reviews

• Manual Techniques

• Static or Scenario-based

• In Theory, it can test everything of an architecture

• All stakeholders are involved– Not only technical people

the Architectural Trade-off Analysis Method

• First proposed by Clements in CMU

• Human-centric process to identify risks in the early stage of software design

• All stakeholders will be involved– Clients– Managers– Developers

ATAM

• Focus on non-functional properties– Modifiability – Security– Performance– Reliability

• Identify risks

• Reveal how well the system meets the requirements

Detail of ATAM

• 4 Phases– Preparation– Presentation and Analysis– Testing and Reporting– Finalization

• 9 steps

Phase 0-Preparation

• Find out the right people– Who will do the presentation– Who will be the representatives of clients

• Training Session

• Necessary Materials

• Kick-off Meeting

Phase 1-Presentation and Analysis

• Step 1:Present the ATAM

• Step 2:Present the business drivers

• Step 3:Present the architecture

• Step 4:Identify the Architectural Approaches

• Step 5: Draw the Quality Attribute Utility Tree

• Step 6:Analyze the Architectural Approach

Phase 2-Testing and Reporting

• Step 7: Brainstorming and Prioritizing Scenarios

• Step 8: Analyze the Architectural Approach

• Step 9: Present the result

Phase 3- Finalize

• Producing a final report

• Collecting Data for measurement and improvement

• Archive all artifacts

Why use the ATAM?

• Enable non-technical people to control the quality of software

• A Method for developers to sell their project

Limitation of ATAM

• Expensive

• Time consuming

• Human intensive

Model Based Analysis

• Based on the description of Architecture– ADLs

• Can be done automatically– Less expensive

Model Based Analysis

• Goals– Consistency

– Compatibility

– Internal Completeness

• Scope– Component level

– Data exchange level

• Type– Static

Model Based Analysis

• Techniques are complex– May not be possible to analyze a very large

system in a very high accuracy– Sometimes may need to sacrifice some

accuracy

• Can only analyze properties that are not formally described– Non-functional Properties are not supported

Model Based Analysis Enabled by ADLs

• Parsers and compilers– Check the syntax– Check consistency

• Exam Refinement

• Exam Constrains

type DataStore be interface action in SetValues(); out NotifyNewValues(); behavior begin SetValues => NotifyNewValues();;end DataStore;

type Calculation is interface action in SetBurnRate(); out DoSetValues(); behavior action CalcNewState(); begin SetBurnRate => CalcNewState1(); DoSetValues(a);;end Calculation;

type Player is interface action out DoSetBurnRate(); in NotifyNewValues(); behavior TurnsRemaining : var integer := 1; action UpdateStatusDisplay(); action Done();

Simulation-Based Analysis

• Create a dynamic executable model of system– It is a high level executable model– Require support from modeling language, not

all languages are executable

Simulation-Based Analysis

• Goals– Completeness– Consistency– Compatibility– Correctness

• Scope– System or subsystem level– Dataflow

Simulation-Based Analysis

• Concern– Behaviors– Interaction– Non-functional properties

• Dynamic, scenario-based

• Fully automated

XTEAM

• Is developed by George Edwards

• Create simulation codes from High-level model

• Easy to change the model and create new simulation codes

• Can simulate the latency, power consumption and reliability of a system

XTEAM Toolchain

Meta-model in XTEAM

xADL in XTEAM

FSP in XTEAM

• FSP is a behaviors ADL

• Present Finite State Machine in an algebra way

Power simulation in XTEAM

• Assign the Power consumption of each process– Assigned by Power model– Assigned by Domain Expert

• Record the power consumption of each invocation of process

• Data are analyzed by human

Summary of XTEAM

• Fully automatic simulation– Generate simulation code automatically– Human are only involved in Data analysis

• A wider range of goals and concerns and be achieved than static techniques– Could analysis some non-functional properties

Reliability Analysis

• The probability that the system runs without failure

• A failure is the occurrence of an incorrect output according to an input

• Error: mental mistake made by programmers

• Fault: manifestation of an error

Reliability Metrics

• Time to failure

• Time to repair

• Time between failures

Discrete Markov Model

• A Stochastic Process Model

• Based on a Finite State Machine

Hidden Markov Process

• Transition Probabilities between each state may not be known

• Need some training data to estimate transition probabilities

• Simulation is needed

Summary of Reliability Analysis

• Reliability analysis can be both dynamic or static

• Require Domain Knowledge

• Some times the Markov properties may not satisfied

Summary

• ATAM

• Model-based Analysis

• Simulation-based Analysis

• Reliability Analysis

Reference

• Evaluating Software Architecture: Methods and Case Studies

• Guide to the Rapide-1.0 Language Reference Manuals

• Rapide-1.0 Architecture Language Reference Manual

• OMG Object Constraint Language (OCL) Documents

• DRESDEN OCL MANUAL FOR INSTALLATION, USE AND DEVELOPMENT

• Model and Object Verification by Using Dresden OCL Birgit Demuth et.al 2009

• XTEAM USER MANUAL

• Finite State Process Algebra and LTSA

• Scenario-Driven Dynamic Analysis of Distributed Architectures George Edwards et.al 2007

• Estimating Software Component Reliability by Leveraging Architectural Models Roshanak Roshandel et.al 2006