1. SoberIT Software Business and Engineering Institute HELSINKI UNIVERSITY OF TECHNOLOGY © Varvana Myllärniemi, 2008 1 T-76.5150 Software Architectures Scenarios

2. SoberIT Software Business and Engineering Institute HELSINKI UNIVERSITY OF TECHNOLOGY © Varvana Myllärniemi, 2008 2 Motivation  How to start bridging the gap from requirements to architecture?  How to concretise requirements so that they are understood by all stakeholders of the system?  How to describe quality attribute requirements?  How to evaluate architecture against the requirements?  Scenarios provide a simple yet powerful means for these and many other situations.

3. SoberIT Software Business and Engineering Institute HELSINKI UNIVERSITY OF TECHNOLOGY © Varvana Myllärniemi, 2008 3 Scenarios  A scenario is a short statement describing an interaction of one of the stakeholders with the system. (Clements et al., 2002)  Note: a stakeholder instead of a user  An architectural scenario is a crisp, concise description of a situation that the system is likely to face in its production environment, along with the definition of the response required of the system. (Rozanski and Woods, 2005)

4. SoberIT Software Business and Engineering Institute HELSINKI UNIVERSITY OF TECHNOLOGY © Varvana Myllärniemi, 2008 4 A scenario is not a use case  Although sometimes treated as synonyms, scenarios are not use cases  A scenario is an instance of a use case (Kruchten, 1995; Jacobson, 1995)  A use case describes a set of sequences of actions  A scenario is a concrete instantiation of a use case  Use cases are often treated more formally (Jacobson, 1995)  Use cases describe the system strictly from a black-box viewpoint, whereas scenarios are often linked to the internal elements of the system (Jacobson, 1995)

5. SoberIT Software Business and Engineering Institute HELSINKI UNIVERSITY OF TECHNOLOGY © Varvana Myllärniemi, 2008 5 A scenario is not a use case  However, not all scenarios are instances of use cases  Scenarios can capture many aspects that cannot be captured by use cases  Quality requirements  Important from the viewpoint of SA  If only use cases are used to capture requirements, QA requirements are easily forgotten  Scenarios initiated by the system itself  Scenarios initiated due time passing, temporal issues

6. SoberIT Software Business and Engineering Institute HELSINKI UNIVERSITY OF TECHNOLOGY © Varvana Myllärniemi, 2008 6 Uses for scenarios  Input for AD process  A driver to help designers discover architectural elements during AD (Kruchten, 1995)  Architecture assessment  Communication among stakeholders  Identifying missing requirements  Driving testing (Rozanski and Woods, 2005)

7. SoberIT Software Business and Engineering Institute HELSINKI UNIVERSITY OF TECHNOLOGY © Varvana Myllärniemi, 2008 7 Types of scenarios  Rozanski and Woods (2005):  Functional scenarios  System quality scenarios  Clements et al. (2002):  Use case scenarios  User’s interaction with a completed, running system  Can be used to capture certain quality aspects  Growth scenarios  Anticipated changes to the system  Exploratory scenarios  Push the envelope and stress the system

8. SoberIT Software Business and Engineering Institute HELSINKI UNIVERSITY OF TECHNOLOGY © Varvana Myllärniemi, 2008 8 Scenario elicitation  Sources for scenarios  Requirements  Stakeholders  Experience  Often negative situations prove fruitful scenario sources  Faults, security attacks, overload situations...  After scenarios have been identified, it is important to prioritise them  E.g. (importance to stakeholders, risk of implementation)  Scenarios should be derived only for the most critical aspects of the system  A manageable set of scenarios = max. 15 to 20

9. SoberIT Software Business and Engineering Institute HELSINKI UNIVERSITY OF TECHNOLOGY © Varvana Myllärniemi, 2008 9 Writing Scenarios

10. SoberIT Software Business and Engineering Institute HELSINKI UNIVERSITY OF TECHNOLOGY © Varvana Myllärniemi, 2008 10 Structure of a scenario description  No standard structure  A scenario can be free-format text  However, there are some recurring elements that help in elicitating and writing scenarios  Most notably stimulus and response  More structured templates have been proposed  Two of them are exemplified  Rozanski & Woods, 2005: functional scenarios and quality scenarios  Bass et al., 2003: quality attribute scenarios  Unnecessary parts can be omitted

11. SoberIT Software Business and Engineering Institute HELSINKI UNIVERSITY OF TECHNOLOGY © Varvana Myllärniemi, 2008 11 Rozanski & Woods (2005): Template of a functional scenario  Overview of the scenario  System state (before the scenario occurs)  E.g. what information is stored in the system  System environment  Any significant observation of the system environment  E.g. external systems, infrastructure, time-based constraints  External stimulus  What causes the scenario to occur  Required system response  From external observer’s point of view (Rozanski and Woods, 2005)

12. SoberIT Software Business and Engineering Institute HELSINKI UNIVERSITY OF TECHNOLOGY © Varvana Myllärniemi, 2008 12 Rozanski & Woods (2005): Example functional scenario Incremental statistics update Overview: How the system deals with a change to some of the existing base data. System state: Summary statistics already exist for the sales quarter that the incremental statistics refer to. The system’s databases have enough space to cope with the processing required for this update. System environment: The deployment environment is working normally, without problems. External stimulus: An update to a subset of the sales transactions for the previous quarter arrives via the Bulk Data Load external interface. Required system response: The incoming data should automatically trigger background statistical processing to update the summary statistics for the affected quarter to reflect the updated sales transaction data. The old summary statistics should stay available until the new ones are ready.

13. SoberIT Software Business and Engineering Institute HELSINKI UNIVERSITY OF TECHNOLOGY © Varvana Myllärniemi, 2008 13 Rozanski & Woods (2005): Template of a system quality scenario  Overview  System environment  Any significant observation of the system environment  May also include observation about the system state  Environment changes  Environment changes that cause the scenario to occur  Required system behaviour  How system should behave in response to the change in the environment (Rozanski and Woods, 2005)

14. SoberIT Software Business and Engineering Institute HELSINKI UNIVERSITY OF TECHNOLOGY © Varvana Myllärniemi, 2008 14 Rozanski & Woods (2005): Example system quality scenario Failure in summary database instance Overview: How the system behaves when the database it is trying to write to fails. System environment: The deployment environment is working correctly. Environment changes: While writing summary statistics to the database, the system receives an exception indicating that the write failed (e.g., the database is full). Required system behaviour: The system should immediately stop processing the statistics set it is working on and leave any work in progress behind. The system should log a fatal message to the operational console monitoring system and shut down.

15. SoberIT Software Business and Engineering Institute HELSINKI UNIVERSITY OF TECHNOLOGY © Varvana Myllärniemi, 2008 15 Bass et al., 2003: Template of quality attribute scenarios  Source of stimulus  Stimulus  Environment  Artifact  Response  Response measure Artifact StimulusResponse EnvironmentSourceMeasure

16. SoberIT Software Business and Engineering Institute HELSINKI UNIVERSITY OF TECHNOLOGY © Varvana Myllärniemi, 2008 16 Example performance scenario  Users initiate 1000 transactions per minute stochastically under normal operation and these transactions are processed within an average latency of two seconds. Artifact System Stimulus Initiate 1000 transactions stochastically Response Transactions are processed Environment Under normal operation Source Users Measure With average latency of two seconds

17. SoberIT Software Business and Engineering Institute HELSINKI UNIVERSITY OF TECHNOLOGY © Varvana Myllärniemi, 2008 17 Scenarios and system boundary  What is the right ”black box” for scenarios?  Some of the example scenarios go quite deep in technical elements  Main difference to traditional use cases that describe the system from user’s point of view  The right level of granularity depends on the system boundary and system scope  If designing software architecture, hardware can also be treated to be outside of system boundary > Online Catalog and Ordering System Product Database Customer Database Warehouse Management System Accounts System > CC Validation System > Distribution System

18. SoberIT Software Business and Engineering Institute HELSINKI UNIVERSITY OF TECHNOLOGY © Varvana Myllärniemi, 2008 18 Checklist for writing your scenarios  Define at least stimulus and system response  Keep the scenarios crisp and to the point  Not too many / prioritise  Use distinct scenarios  Use any template that seems suitable  Omit irrelevant parts  Try to avoid describing solutions as scenarios  Relate ”black box” to the system boundary

19. SoberIT Software Business and Engineering Institute HELSINKI UNIVERSITY OF TECHNOLOGY © Varvana Myllärniemi, 2008 19 Summary  Scenarios provide a simple yet efficient technique for many kind of tasks during the AD process  Scenarios are especially beneficial for describing quality attribute requirements  Next week, we will go through particular quality attributes and their scenarios in more detail

20. SoberIT Software Business and Engineering Institute HELSINKI UNIVERSITY OF TECHNOLOGY © Varvana Myllärniemi, 2008 20 References Bass, Len; Clements, Paul and Kazman, Rick. Software Architecture in Practice. Addison-Wesley, 2003, 2nd ed. Clements, Paul; Kazman, Rick and Klein, Mark. Evaluating Software Architectures. Addison-Wesley, 2002. Jacobson, Ivar. The Use Case Construct in Object-Oriented Software Engineering. Chapter 12 in Scenario-Based Design---Envisioning Work and Technology in System Development, editor G. Ghastek. New York: John Wiley & Sons, 1995. Kruchten, Philip. The 4+1 View Model of Architecture. IEEE Software (Nov), 1995. Rozanski, Nick and Woods, Eoin. Software Systems Architecture: Working with Stakeholders Using Viewpoints and Perspectives. Addison-Wesley, 2005.