Revision as of 23:54, 25 June 2008

Use Cases

This page provides a review of the Use Case sites on the web. We provide an introductory discussion of Use Cases, including their purpose, applications, and techniques for their construction. In addition, we provide links to some of the best web sites for learning about Use cases, including the sites with the most instructive examples, and those teaching advanced concepts that might not be apparent from a quick search of the web.

Overview

Use Cases are a modeling aid used in software design to describe a sequence of events in a way that both the end users of a system, and the system designers and developers, can each understand completely. Use cases typically describe an event initiated by either a human user or another application, however the event and response are usually external, to maintain separation of responsibility between the designer and the user. The users should not have to be concerned about thread synchronization, for example, and the users should not need to care how the feature will be implemented. By communicating in a common language, end users may indicate what they require from the system, and designers may understand how those externaly visible requirements from the users translate into derived requirements internal to the system, in modules and subsystems not necessarily visible to the users. Most Use Cases simply describe a flow of events from input, or request, to output, or response. A typical use case for purchasing a ticket could be described by a user as follows:

1. Customer requests ticket
2. Agent determines if space is available and informs customer
3. Customer purchases ticket, or declines price offered
4. Agent accepts payment and delivers ticket, or terminates
5. Customer terminates

Even an example as simple as the one shown above can help designers understand the implications, in terms of the system design, so that the system will satisfy the requirements. For example, there are multiple potential exception processing points in this use case; the Agent could determine there is no ticket available, or the price offered may be more than the Customer wants to pay. The Customer may decide not to purchase a ticket for any reason. Both the Customer and Agent will have to be designed to handle these exception cases. After satisfactorily working through the use case with the user, the designer will understand the user expects to be able to refuse to purchase the ticket, and the designer can then flow that requirement into the system internals.

Just as use cases help to identify Actors, Roles, and resources, they also help expose internal state and corner cases that designers may miss without this valuable input from the users. In addition, a well developed set of use cases can help designers make the system more robust, by enforcing restrictions on what users are allowed to do at certain points (for example, not allowing a subsequent missile launch, until the user presses a button on the firing panel indicating the previous launch was successful).

@@ Line 10: / Line 10: @@
 *# Customer terminates
-Even an example as simple as the one shown above can help designers understand the implications, in terms of the system design, so that the system will satisfy the requirements.  For example, there are multiple potential exception processing points in this use case; the Agent could determine there is no ticket available, or the price offered may be more than the Customer wants to pay.  The Customer may decide not to purchase a ticket for any reason.  Both the Customer and Agent will have to be designed to handle these exception cases.
+Even an example as simple as the one shown above can help designers understand the implications, in terms of the system design, so that the system will satisfy the requirements.  For example, there are multiple potential exception processing points in this use case; the Agent could determine there is no ticket available, or the price offered may be more than the Customer wants to pay.  The Customer may decide not to purchase a ticket for any reason.  Both the Customer and Agent will have to be designed to handle these exception cases.  After satisfactorily working through the use case with the user, the designer will understand the user expects to be able to refuse to purchase the ticket, and the designer can then flow that requirement into the system internals.
 Just as use cases help to identify Actors, Roles, and resources, they also help expose internal state and corner cases that designers may miss without this valuable input from the users.  In addition, a well developed set of use cases can help designers make the system more robust, by enforcing restrictions on what users are allowed to do at certain points (for example, not allowing a subsequent missile launch, until the user presses a button on the firing panel indicating the previous launch was successful).

CSC/ECE 517 Summer 2008/wiki2 4 uc: Difference between revisions

Revision as of 23:54, 25 June 2008

Use Cases

Overview

History

Benefits of Applying Use Cases

Expose Actors, Resources, and Roles

Anticipate Corner Cases

Applying Use Cases

Place of Use Cases in the Development Process

Techniques and Methods Adjunct With Use Cases

How to Apply Use Cases

Example Use Case

Summary

Navigation menu

Search