Use Cases

This page provides a review of the Use Case sites on the web. After an introductory discussion of Use Cases, including their purpose, applications, and techniques for their use, links to some of the best web sites for learning about Use cases are discussed, 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 (most of the documents require a free registration by email address, however it should be well worth the cost to learn about use cases from the inventor). Wikipedia has a good writeup on Jacobson's contributions.

Alistair Cockburn is another important authority in use case theory and application; on his web site he describes the history of use cases, from before they were invented, until the present day, and hosts many resources for use cases from his site.

Another heavy hitter on use cases from the software development community is Ward Cunningham, the inventor of the wiki. Ward Cunningham has a page linked from his site that describes User Stories, which are different from use cases. Ward's main site is full of valuable information from one of the pioneers of software development.

Review of Use Case sites on the Web

developer.com has a practical walkthrough of Use Case Diagrams and how they are used to represent use cases. Wikipedia of course has many useful pages related to use cases, including Activity Diagrams, how use cases fit into the Unified Modeling Language, and the Essential Unified Process. The site http://www.agilemodeling.com/ has, in addition to plenty of information about agile methods, a page on use cases within agile processes. Among the many use case tutorials on the web, some of the more useful to this reviewer areKennesaw State University's Object Oriented Analysis and Design page, and this page at Carnegie Mellon. In addition, this page from University of Washington presents some of Alistair Cockburn's use case wisdom in a tutorial format.

Another big player in use case application and theory is Andy Pols, who maintains a resource site known as the Use Case Zone, hosting many use case papers.

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.

http://embedded.com/98/9805br.htm

http://shelley.toich.net/projects/CS201/patriot.html

http://www.cert.fr/francais/deri/adele/DOCUMENTS/ariane5.html

http://www.embedded.com/97/feat9610.htm

http://www.embedded.com/9900356?_requestid=504357

http://www.embedded.com/products/softwaretools/175800445?_requestid=504492

http://www.embedded.com/180205522?_requestid=402

http://www.embedded.com/columns/embeddedpulse/9900179?_requestid=442

http://msdn.microsoft.com/en-us/library/cc194881.aspx

http://www.usability.gov/

http://www.usability.gov/methods/usecases.html

http://www.ivarjacobson.com/