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.
Why do I draw UML Activity Diagrams?
I almost always draw
flowcharts or
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
Typically used to model
Business process workflow
Flow within a use case
Business rules logic
Functional processes
UI screen flows
Activity diagrams are a technique to describe
procedural logic,
business process, and
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 is 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 as shown below.
What are use case scenarios?1) Start at the beginning of the flowchart and follow the connecting lines until you encounter a decision
2) At the decision you will have to choose one branch, one logical path, to continue the scenario. If you choose the path to the right, the scenario ends
3) Rather than repeat scenario steps already documented, start at the point where the paths diverge.
4) Continue on until you encounter a decision, then choose one of the branches
5) At this point you return to tthe loop .
You have already identified both paths out of the loop decision block so you can stop.
6) Start with the branch not yet taken from the last decision,
7) When you reach the previously defined decision 8 ) All of the scenarios combined
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.
