Smalltalk and Object Orientation: an Introduction - Free

OMT is a prescriptive method, it provides guidance on how the various models it generates should
be constructed. In the remainder of this section we will consider the guidelines given.
19.3.1 Use case analysis
The intention of the use case analysis is to identify how the system is to be used and what the system is
expected to do in response to this use. This involves identifying the external users of the system (human
or machine) and the required system functionality. The users of the system and the roles they play are
referred to as actors while the functions requested and their sequence are called use cases . The
combination of the actors an d the use cases are referred to as the use case model. Each of these will be
considered in more detail below.
19.3.1.1 Actors
An actor can be anything which interacts with the system. This means they can be human users, other
computer systems, dumb terminals, senso rs, devices to be controlled etc. However, they not only
represent the user, but also the role that the user plays at that point in time. For example, in a small
company the accountant might act as the data entry clerk at one time, the internal auditor at another and
as the payroll administrator at yet another time. Each of these roles would be represented by a different
actor, even though they would all be performed by the same person. To stress the difference between
actors and users [Jacobson et al 1992] says that they think of an actor as “a class, that is, a description of
a behavior” while a user is described as playing “several roles” which are “many actors”.
Identification of the actors in the system is not trivial and as [Jacobson et al 1992] point out “all
actors are seldom found at once”. Jacobson goes on to state that a “good starting point is often to check
why the system is to be designed?”. Having done this it should be possible to identify the main users of
the system and what they will need t o do with that system. From these users and their needs, actors can
be identified. Identification of such actors is usually relatively straight forward, but it is often much
more difficult to identify non-human actors. In general, as the rest of the use case model develops, these
actors “come out in the wash”.
The notation used (in this book at least) for actors is based on that presented by the UML in the last
chapter.
For a simple bank account system the actors may be the customer, the bank clerk and the bank
manager.
19.3.1.2 Use cases
When an actor interacts with the system it is for a specified purpose. The achievement of this purpose
involves following one or more steps. If there are multiple steps there may be a specific sequence to
these steps in order to ac hieve the desired purpose. For example, if you are attempting to obtain money
from a “hole in the wall machine” (cash dispenser/ATM) then you must first input your card, type in
your PIN, select the type of transaction your require, specify the amount of c ase required, take the card
and then take the money. If you attempt to change this sequence you will fail to obtain your money (e.g.
you type in your PIN before inputting your card!). The combination of the purpose, and the specified
sequence of steps, forms a use case.
A use case can be represented in a number of ways, the two most common are as natural language
and as state transition diagrams. Whichever approach is adopted, the same information should be
captured. The most appropriate form may depend on the availability of support tools for the state
machine notation.
The collection of all uses cases for a system defines the functionality of that system. The
identification of uses cases is based on the identification of actors. Each actor will need to d o one or
more things to the system, each of these uses will be a use case. That is, each actor must have at least
one use case (and may be involved in many use cases). Whether each use case is unique (or merely a
duplication of another use case) may only b e determined once all the uses cases are identified and
defined. To help in identifying the uses cases, the following questions can be asked [Jacobson et al
1992]:
• What are the main tasks of each actor?
155