1 / 33

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.

kesler
Download Presentation

Architecture Analysis Techniques

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  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 => 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();

  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

More Related