Architecture Analysis Techniques Ding Li 2927154806 1

Review 2

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

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 4

ATAM Focus on non-functional properties Identify risks Modifiability Security Performance Reliability Identify risks Reveal how well the system meets the requirements System level Completeness, Capability, Correctness 5 5

Detail of ATAM 4 Phases 9 steps Preparation Presentation and Analysis Testing and Reporting Finalization 9 steps 6

Phase 0-Preparation Find out the right people Training Session Who will do the presentation Who will be the representatives of clients Training Session Necessary Materials Kick-off Meeting 7

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 Step 3: Should include constrains, systems to interact and styles and patterns Step 4: the evaluate team will ask the Architects to explicitly name any identifiable approaches Step 6: understand the details and how it was applied in system, well-known weakness, trade- offs, compare with other approach for each scenarios in Step 5. 8 8

Phase 2-Testing and Reporting Step 7: Brainstorming and Prioritizing Scenarios Step 8: Analyze the Architectural Approach Step 9: Present the result Step 7 more stakeholders are involved 9 9

Phase 3- Finalize Producing a final report Collecting Data for measurement and improvement Archive all artifacts 10

Why use the ATAM? Enable non-technical people to control the quality of software A Method for developers to sell their project Does the project worth the money? Persuade the clients to go on give you money For example, my mother wants to develop a students information system 11 11

Limitation of ATAM Expensive Time consuming Human intensive 12

Model Based Analysis Based on the description of Architecture ADLs Can be done automatically Less expensive 13

Model Based Analysis Goals Scope Type Static Consistency Compatibility Internal Completeness Scope Component level Data exchange level Type Static 14

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 For example, in our homework, we may need to enumerate all paths in the Graph, 15 15

Model Based Analysis Enabled by ADLs type DataStore be interface action in SetValues(); out NotifyNewValues(); behavior begin SetValues => NotifyNewValues();; end DataStore; type Calculation is interface action in SetBurnRate(); out DoSetValues(); action CalcNewState(); SetBurnRate => CalcNewState1(); DoSetValues(a);; end Calculation; type Player is interface action out DoSetBurnRate(); in NotifyNewValues(); TurnsRemaining : var integer := 1; action UpdateStatusDisplay(); action Done(); Parsers and compilers Check the syntax Check consistency Exam Refinement Exam Constrains 16

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 17

Simulation-Based Analysis Goals Completeness Consistency Compatibility Correctness Scope System or subsystem level Dataflow 18

Simulation-Based Analysis Concern Behaviors Interaction Non-functional properties Dynamic, scenario-based Fully automated 19

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 20

XTEAM Toolchain 21

Meta-model in XTEAM 22

xADL in XTEAM 23

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

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 26

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 An abnormal condition that may cause a reduction in, or loss of, the capability of a component to perform a required function A requirements, design, or implementation flaw or deviation from a desired or intended state 27 27

Reliability Metrics Time to failure Time to repair Time between failures 28

Discrete Markov Model A Stochastic Process Model Based on a Finite State Machine 29

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

Summary of Reliability Analysis Reliability analysis can be both dynamic or static Require Domain Knowledge Some times the Markov properties may not satisfied 31

Summary ATAM Model-based Analysis Simulation-based Analysis Reliability Analysis 32

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 33