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
Top Related