Scenario-Based Analysis of Software Architecture

1. Scenario-Based Analysis of Software Architecture Rick Kazman, Gregory Abowd, Len Bass, and Paul Clements Presented by Cuauhtémoc Muñoz

2. Outline • Software Architecture Analysis Method Overview • Software Architecture Analysis Method Activities • WRCS: Case Study • Advantages of SAAM • Conclusion

3. SAAM Overview • Software Architecture Analysis Method (SAAM) • Scenarios • Quality attributes • Why Scenarios? • Quality attributes and roles

4. SAAM Activities • Describe the candidate architecture • Develop Scenarios • Evaluate each scenario • Reveal scenario interactions • Weight scenarios and scenarios interactions • * Dependencies

5. SAAM

6. WRCS: Case Study (1/11) • WRCS • Version control/configuration management system. • Functions: create projects, compare files, check files in and out, create releases, back up to old versions, etc.

7. WRCS Case Study (2/11) • Applying SAAM: 1. Describe candidate architecture: • Reverse engineering. • Level of abstraction above source code. • Architectural description done iteratively. Three iterations in this case.

8. WRCS Case Study (3/11)

9. WRCS Case Study (4/11) 2. Develop scenarios • Stakeholder representations (e.g. customer). • For the user role: • Compare binary file representations. • Compare binary files generated by other products. • Configure the toolbar. • Manage multiple projects • For the maintainer role: • Port to another operating system. • Modify the user interface in minor ways.

10. WRCS Case Study (5/11) • For the administrator role: • Change access permissions for a project. • Integrate WRCS functionality with a new development environment. • Port to a different network-management system.

11. WRCS Case Study (6/11) 3. Evaluate each scenario • Direct and indirect scenarios • Focus on indirect scenarios. • Estimate the cost of indirect scenarios • Minimal cost (e.g. modifications to a resource file). • Moderate cost (e.g. recompilation). • Considerable cost (e.g. restructuration of code).

12. WRCS Case Study (7/11)

13. WRCS Case Study (8/11) • 4. Reveal scenario interactions • Focus on scenarios with the most interactions.

14. WRCS Case Study (9/11)

15. WRCS Case Study (10/11) 5. Weight scenarios and scenario interactions • Prioritize scenarios based on organizational requirements and preferences of the SAAM user.

16. WRCS Case Study (11/11) • Results: • Severe limitations in achieving portability and modifiability. • SAAM exposed specific product’s limitations in a simple, straightforward, and cost effective way.

17. Advantages of SAAM (1/3) • Enhanced communication • Scenarios. • Visualizations • Improvement of traditional metrics • Coupling and cohesion • Low coupling, high cohesion. • Proper description level • Higher level of abstraction

18. Advantages of SAAM (2/3) • Mapping of scenarios onto the structure • Highlight components and connections that will be affected by the change the scenario implies. • Architectural evaluation. • Validation of scenario interaction. • Appropriate level of architectural representation. • Example: • A case in which multiple indirect scenarios affect a single module. Three possibilities:

19. Advantages of SAAM (3/3) • The scenarios are of the same class. • The scenarios are of different classes and you can further divide the module. • The scenarios are of different classes and you cannot further divide the module. • Efficient scenario generation • Like software testing.

20. Conclusion • SAAM has been applied to large-scale industrial systems such as “Global Information System” and “Air Traffic Control System.” • Future plans include the extension of this technique from maintainability and modifiability to execution-based measures such as performance and reliability.