Smalltalk and Object Orientation: an Introduction - Free

• Will the actor have to read/write/change any of the system information?
• Will the actor have to inform the system about outside changes?
• Does the actor wish to be informed about unexpected changes?
Early in the analysis process it is often enough just to identify the possible uses cases and not to worry
about their details. Once a reasonable set of uses are identified, it may be possible to analyze the
systems requirements in greater detail in order to flesh out the uses cases. Use case identification tends
to be iterative and should not be treated as a single step process for all but the simplest of systems.
Having identified the uses cases, we can identify the steps performed within each use case. In many
cases this can help to identify omissions and over generalizations in any problem statement or domain
understanding, that we may have.
For the simple bank account system mentioned above, a typical use case might be:
Check account is started by Customer when they want to find out their current balance.
This is accomplished by:
1. typing in their account number followed by the PIN
2. requesting the current balance of their account (this may be on screen or on a
print out)
3. receiving the balance
4. acknowledging receipt of the balance
5. logging off the system
Notice that the first element of the use case is a statement of its purpose. This is then followed by the
sequence of steps performed by the use case. The steps described above are referred to as the basic
course of the use cases. That is, the normal way in which the use case will execute. In general uses
cases only possess a single basic course. However, they may possess one or more alternative courses.
These alternatives deal with exceptional situations or errors. For example, what if the customer does not
have a current account, what happens if they do not accept receipt of their balance?
19.3.1.3 Use case models
The identification of the actors and the uses cases together help to specify the limits of the system. That
is, anything that is an actor is outside the system, whereas anything that is a use case is within the
system boundaries. This means that it is possible to draw a line around the uses cases indicating the
boundary of the system. This is very useful in helping to identify the bounds of the software project as a
whole in terms which both a developer and a user c an understand. This can help to clarify
misunderstandings between users and developers over what is the system’s responsibility and what is
not. A partial use case model for the simple account system is presented in Figure 19.1.
Account System
Deposit cash
Clerk
Customer
Withdraw
cash
Check balance
Customer
report
Manager
Pay bill
Figure 19.1: Use case model
19.3.1.4 Interface descriptions
Having defined the actors in the system and the uses they make of the system, the next step is often to
specify the i nterfaces between the actors and the system. For human users of the system, these
interfaces may well be graphical user interfaces (GUI’s) and may be drawn using a drawing tool or
mocked up using some form of interface simulation software. These interfaces can be very useful in
156