1. DR. HIMANSHU HORA
SRMS College of Engg. & Tech., Bareilly (UP)
INDIA

2. CONTENTS
 What is SAAM
 How to perform SAAM
 What is a scenario
 SAAM Activities

3. SOFTWARE ARCHITECTURE
ANALYSIS METHOD
 SAAM
 Develop scenarios
 Describe architectures
 Classify scenarios
 Direct, indirect
 Evaluate indirect scenarios changes
 Scenario interaction
 Overall evaluation

4. STEPS TO PERFORM SAAM
 Structured process for evaluating software
architectures.
 Before an architecture is finalized
 How can this be done
 Prepare description of candidate architectures
 Evaluate impact of various scenarios
 Identify issues with one architecture under study

5. SCENARIO
 Definition
 Brief description
 Of a single interaction
 Of a stakeholder
 With the system
 Stakeholder examples
 User performing a desired operation
 Maintainer making a system change

6. SAAM ACTIVITIES
Scenario
Development
Architecture
Description
Scenario
Classification
Scenario
Evaluation
Interaction
Assessment
Overall Evaluation

7. SCENARIO DEVELOPMENT
 Illustrate kinds of activities needed
 During system usage and modification
 Tasks relevant to all stakeholders
 Process
 Prepare agenda, record all discussion
 Brainstorm “proto scenarios”
 Remove unimportant ones
 Keep “revealing” scenarios, merge others

8. ARCHITECTURE
DESCRIPTION
 Document candidate architectures
 Use well understood notation, etc.
 Cover all important aspects
 Identify architectural styles
 What level of presentation
 Suitable for audience
 Sufficient to address scenarios

9. SCENARIO CLASSIFICATION
 Direct
 Scenarios that the candidate architecture can
handle without change
 Indirect
 Scenarios that are not directly supported
 Require change to system
 Change in component function
 Addition of components
 Addition of connections between components

10. SCENARIO EVALUATION
 Identify needed changes for each scenario
 Specific list of changes
 Cost estimate
 Weight difficulty of changes
 Not just the number of changes
 Create a table of evaluation results
 Scenario
 Anticipated changes to support requirements

11. INTERACTION ASSESSMENT
 When multiple scenarios require changes to a single
component
 Scenarios are said to interact
 May expose poor allocation of responsibility
 If unrelated scenarios affect same component
 Ok if related scenarios interact

12. OVERALL EVALUATION
 To compare architectures
 Assign weights to scenarios
 Tabulate with cost estimates
 Evaluation is subjective
 Depends on all stakeholders

13. THANK YOU
DR. HIMANSHU HORA
SRMS College of Engg. & Tech., Bareilly (UP)
INDIA