Use Case View  «Prev  Next»
Lesson 11Use case scenarios
ObjectiveIdentify Scenarios in Relation to Use Cases.

Identify Scenarios in Relation to Use Cases

Use cases identify a primary goal of the system. When an actor attempts to accomplish a goal using the system, there are usually decisions or rules that could change the outcome. There may also be exception conditions that affect the accomplishment of the goal.

Scenarios explained and how they are used a number of ways

The word "scenario" is used a number of ways.
In the context of UML use cases, scenarios have a very specific meaning. Be careful not to confuse the more general usage with the explicit definition used here.
Draw UML Activity Diagram

Why do I draw Activity Diagrams?

I almost always draw
  1. flowcharts or
  2. activity diagrams
rather than rely on text alone. Remember that visual models are almost always easier to test and interpret than textual models.
As someone once said, "When in doubt, draw a picture." An Activity Diagram is a type of diagram in the Unified Modeling Language.
Activity diagrams represent the business and operational workflows of a system. An Activity Diagram shows the overall flow of control.
In UML 1.x, an Activity diagram is a variation of the UML State diagram where the "states" represent operations, and the transitions represent the activities that happen when the operation is complete.
The UML 2.0 Activity diagram, while similar looking to the UML 1.x Activity diagram, now has semantics based on Petri nets.
In UML 2.0, the Interaction Overview diagram is based on the Activity diagram.

Activity Diagram

Activity diagrams show flow of control and data flow
  1. Typically used to model
  2. Business process workflow
  3. Flow within a use case
  4. Business rules logic
  5. Functional processes
  6. UI screen flows
Activity diagrams are a technique to describe
  1. procedural logic,
  2. business process, and
  3. work flow.
In many ways, they play a role similar to flowcharts, but the principal difference between them and flowchart notation is that they support parallel behavior.
Activity diagrams have seen some of the biggest changes over the versions of the UML, so they have been significantly extended and altered again for UML 2. In UML 1, activity diagrams were seen as special cases of state diagrams. This caused a lot of problems for people modeling work flows, which activity diagrams are well suited for. In UML 2, that tie was removed.

Finding test cases

This definition for a scenario should remind you of another concept, test cases. Finding test cases is one of the key benefits of the use case approach to modeling. We have just finished the first of many models, and already we have a complete set of tests for our system. These tests will be refined as we continue modeling, but the framework is established. So how do we find these scenarios? Use pictures. It's difficult sometimes to read a narrative and follow every possible path.
One very simple and practical tool to use to find the scenarios visually is a flowchart:

1) Use Case Scenario 1 2) Use Case Scenario 2 3) Use Case Scenario 3 4) Use Case Scenario 4 5) Use Case Scenario 5 6) Use Case Scenario 6 7) Use Case Scenario 7 8) Use Case Scenario 8

UML Distilled

Use Case Scenarios

A modern e-commerce system brings together content and functionality on several levels. In order to understand the overall flow of information in the system and how the various system modules must interact, it is essential for the engineer to analyze the different patterns of usage the system is expected to support. A use case analysis will identify the different users of the system (customer, installer, maintainer, content provider, administrator) as well as the functions to be provided for each user. An initial prototype should include a skeletal implementation or simulation of the interfaces and functionality for each user role. Following the construction of the prototype, a requirements review can be conducted with prospective members of each user group to determine whether the current understanding of the requirements (as embodied in the prototype) is complete and correct. At the earliest stages in development of an e-commerce site, it is useful to build a prototype of the system's front end (Web site and server side logic) as a tool for reaching consensus on the system's modes of operation, inputs, and outputs.

Object-oriented analysis

Object-oriented analysis and the Unified Modeling Language provide useful tools for use case analysis and requirements modeling. However, the resulting model diagrams cannot be discussed directly with a customer or user (unless he or she is skilled in UML). It is more useful to construct a prototype that illustrates an initial version of each user function in a familiar interface such as a web page. Once such a prototype has been constructed, the engineers can demonstrate the system for the customer, explaining the functionality for each user role. Feedback from this kind of prototype demonstration can be revealing. Often the initial requirements from the customer are vague or ambiguous and a prototype review can uncover potential misunderstandings. For example, an initial requirement might be specified as "provide a product search capability for the user" without being specific about the search criteria. If the prototype omits certain search criteria (e.g., particular product characteristics that are important to the customer), the customer will notice in the review, and the requirements document can be updated to reflect the more specific requirement.

Use Case Scenario Described

Identify Scenarios Course Project Exercise

Click the Exercise link below to identify scenarios in the course project.
Usecase Scenario - Exercise