Describing Information Systems: UML Use Cases
Required Resources:
Outline:
The UML: Unified Modeling Language
The complexity problems presented by software design and systems have been attacked using a wide range of technologies and techniques. One of these ways is through the development of a range of "formal languages" (sets of terms, symbols and rules for combining these) that allow activities and processes in organizations and businesses to be modeled abstractly.
UML takes a number of these formal languages languages, and has used object-oriented principles to unify them into a consistent set of terms, symbols and rules. Certain sub-sets of this language are used for specific purposes. One of these sub-sets, called use-case diagrams, will be important in this course, and is widely used in gathering requirements for systems, standards and other technical projects.
Use case diagrams describe the general functionality of a system and the users of that system.
These components are important for this course:
or
![]()
Actor: someone or something outside of the system that interacts with the system. A user. Use case: a function or a service that is provided by system. In the final version of a use case diagram, an individual use case should be large enough so that it would be of value to an actor, but small enough so that it does not immediately or obviously decompose into more specific functions or use cases.
"Communicates" association: shows the actor makes use of a certain function or use case. It has an arrow pointing from an actor to a particular use case if that actor initiates that particular function.System: gives a name to and shows the limits of a particular set of functions or use cases. UML case diagrams need to be accompanied by descriptions. Together, the diagrams and descriptions constitute a use-case document. These descriptions should provide, at a minimum:
- A list of the actors and their roles. If it is has an impact on the flow or is not a pre-condition, you can also provide information about the user's situation (e.g. is a novice user, is working remotely with the system etc.)
- Pre-conditions: list any circumstances particular to the system that need to be satisfied in order for the use case or service to take place (e.g. user is logged on to the system,
- Basic flow: At a minimum, each use case should convey a primary scenario, or a typical course of events. The main basic course of events is often conveyed as a set of numbered steps.
- Post-conditions: list any circumstances particular to the system that are changed as a result of the use case or service taking place.
Note: Writing UML use cases is not an exact science. Nearly every text on use cases or every set of use-case examples will differ slightly in its uses of terms, the rules followed, etc. As a result, the elements provided above have been worded as precisely as possible to guide you in the creation of use case diagrams and accompanying textual descriptions. Moreover, the required resources were selected because they are reasonably consistent in the way they define use-case components and rules.
Example: Automatic Teller Machine
Actors:
- Account holder: has an account allowing ATM access
- Security employee: has access to administrative functions of the ATM system
Preconditions:
- Account holder is able to access system using PIN and bank card
- Account holder and security employee are not using the system at the same time
Basic Flow:
- Account holder accesses system
- Account holder deposits cheque
- Account holder receives receipt and is able to see account balance
- Account holder withdraws a cash amount that is less than accessible balance
Post-conditions:
- Bank machine contains deposits for retrieval
(For additional examples, see: Example Use Cases for PARTS. http://www.cs.virginia.edu/~horton/cs494/examples/parts/usecases-ex1.html)
Activity: A simple use case document
Create a basic use case, utilizing some of the components defined above, for a transaction that occurs in your everyday life (buying a cup of coffee, using a parking garage/meter, etc.). Use MSWord (and the "drawing" toolbar) to create a UML use case diagram such as the two examples provided above.
Submit to colin.furness@utoronto.ca.