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 use. 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).

History

Use Cases were initially developed in the late 1960s by Ivar Jacobsen. Jacobsen continues to develop use case theory and applications to the present day, hosting many presentations and research articles on his website.

Review of Use Case pages on the Web

developer.com has a practical walkthrough of Use Case Diagrams and how they are used to represent use cases.

Summary

Use cases are one of the most effective tools a designer can employ to bridge the gap between technical know-how of the developer and the domain knowledge of the user's requirements and expectations. The web has plenty of resources on Use Cases, and this page should provide a good starting point for learning about them.

CSC/ECE 517 Summer 2008/wiki2 4 uc

Use Cases

Overview

History

Review of Use Case pages on the Web

Summary

Navigation menu

Search