eLens:Lightweight Fine-Grain Energy Estimation Tool in Android

1
Architecture Analysis Techniques
Ding Li 2927154806
2
Review
3
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

4
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

5
ATAM

• Focus on non-functional properties
• Modifiability
• Security
• Performance
• Reliability
• Identify risks
• Reveal how well the system meets the requirements

6
Detail of ATAM

• 4 Phases
• Preparation
• Presentation and Analysis
• Testing and Reporting
• Finalization
• 9 steps

7
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

8
Phase 1-Presentation and Analysis

• Step 1Present the ATAM
• Step 2Present the business drivers
• Step 3Present the architecture
• Step 4Identify the Architectural Approaches
• Step 5 Draw the Quality Attribute Utility Tree
• Step 6Analyze the Architectural Approach

9
Phase 2-Testing and Reporting

• Step 7 Brainstorming and Prioritizing Scenarios
• Step 8 Analyze the Architectural Approach
• Step 9 Present the result

10
Phase 3- Finalize

• Producing a final report
• Collecting Data for measurement and improvement
• Archive all artifacts

11
Why use the ATAM?

• Enable non-technical people to control the
  quality of software
• A Method for developers to sell their project

12
Limitation of ATAM

• Expensive
• Time consuming
• Human intensive

13
Model Based Analysis

• Based on the description of Architecture
• ADLs
• Can be done automatically
• Less expensive

14
Model Based Analysis

• Goals
• Consistency
• Compatibility
• Internal Completeness
• Scope
• Component level
• Data exchange level
• Type
• Static

15
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

16
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 gt
NotifyNewValues() end DataStore type
Calculation is interface action in
SetBurnRate() out DoSetValues()
behavior action CalcNewState() begin
SetBurnRate gt CalcNewState1()
DoSetValues(a) end Calculation type Player is
interface action out DoSetBurnRate()
in NotifyNewValues() behavior
TurnsRemaining var integer 1
action UpdateStatusDisplay() action
Done()
17
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

18
Simulation-Based Analysis

• Goals
• Completeness
• Consistency
• Compatibility
• Correctness
• Scope
• System or subsystem level
• Dataflow

19
Simulation-Based Analysis

• Concern
• Behaviors
• Interaction
• Non-functional properties
• Dynamic, scenario-based
• Fully automated

20
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

21
XTEAM Toolchain
22
Meta-model in XTEAM
23
xADL in XTEAM
24
FSP in XTEAM

• FSP is a behaviors ADL
• Present Finite State Machine in an algebra way

25
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

26
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

27
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

28
Reliability Metrics

• Time to failure
• Time to repair
• Time between failures

29
Discrete Markov Model

• A Stochastic Process Model
• Based on a Finite State Machine

30
Hidden Markov Process

• Transition Probabilities between each state may
  not be known
• Need some training data to estimate transition
  probabilities
• Simulation is needed

31
Summary of Reliability Analysis

• Reliability analysis can be both dynamic or
  static
• Require Domain Knowledge
• Some times the Markov properties may not
  satisfied

32
Summary

• ATAM
• Model-based Analysis
• Simulation-based Analysis
• Reliability Analysis

33
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