Use Cases
In the early 90s Jacobson emphasised use cases as a way of finding the requirements of the users and did so, I think, largely because he was concerned about the quality of existing software products and the fact that very often it was difficult to capture user requirements accurately. Use cases help to get communication going between domain reps and developers and ensure that they can get to grips satisfactorily with what the system entails. It also provides a way of planning iterative development.
Writing use cases is a way of dividing up the functionality of a system into manageable chunks.
It’s best to define the term use case by first defining a scenario:
A scenario is a sequence of steps describing just one interaction between a user and a system.
A use case is set of scenarios tied together by a common user goal.
Use Case with Three Scenarios:
Scenario 1: Purchase a number of items:
1. Customer browses through catalogue and selects items to buy. 2. Customer goes to checkout 3. Customer fill in delivery information 4. Systems presents full pricing information, including delivery 5. Customer fills in credit card information 6. System authorises purchase 7. System confirms sale immediately 8. System sends confirming email to customer
Scenario 2: As above (1 to 8) but with the following modifications: Alternative: Authorisation Failure At step 6, system fails to authorise credit purchase Allows customer to re-enter credit card information and retry
Scenario 3: As above (1 to 8) but with the following modifications: Alternative: Regular Customer 3a System displays current shipping information, pricing information, and last four digits of credit card information 3b Customer may accept or override these defaults Return to primary scenario at step 6
(The purpose of the underlining in point 1 will be discussed later.)
There is (a) a main success scenario (MSS), numbered 1 to 8, (b) one failure extension scenario (generically there are none or more of these) and (c) one alternative success scenario (generically there are none or more or these). There’s another example at http://homepage.eircom.net/~iandowney/procsl.htm
1 That’s the way most use cases are. First your write out the MSS and then you brainstorm each step of the MSS to think out ways in which things can go wrong or, less commonly, alternative ways in which things can go right.
There are many additional parts one can use when writing out use cases. For example, some people add additional information to their description of a use case, such as pre-conditions; those are things that the system will ensure are satisfied before the use case begins. There may also be sections for guarantees; those are things that are promised to be true after the use case ends. There can be guarantees that are true only in event of success or ones that are true always.
Advice as to what to include in a use case description can be found in books on the topic and by attending conferences and workshops. If you’re a professional developer, choose only the details that work for your own type of projects and discard the rest.
A use case describes the intent of the user, not the detailed mechanics of what he/she does. User interface design is NOT part of use cases. Use case design will, however, precede user interface design.
It’s best to write too little for a use case, than too much. One or two pages will usually do. This is because other developers in your team won’t read them if they’re too long-winded. If they’re a bit too short, then fellow-developers can ask you questions to fill in the details. In any case, the details can be fleshed out just before a use case is written and the resulting code will serve as proof of whether the use case has been satisfactorily understood not.
Note that the underlined portion in the use case description (see point 1 in blue text above) suggests an included use case (see <
Use case usage was publicised extensively to the developer world round about 1992 by Ivar Jacobson and others, in conferences and papers. Since then developer proficiency in requirements capture has been greatly improved.
The UML gives no advice about writing use cases. All it does is to supply a technique of representing use cases diagrammatically. These diagrams are entirely optional and they do little more than supply a sort-of graphical table of contents for the use cases that a system or sub-system contains.
Use Case Diagrams
Use case diagrams are not a useful way of describing use cases. Rather they provide a sort of graphical table of contents to support the textual or tabular description of a use case.
These consist of a number of symbols that are described on the next page.
Before I go on any further, I must stress that use cases are ABSOLUTELY NOT about putting each of the numbered steps in a scenario into an equal number of bubbles and chaining these bubbles together with connecting arrows, and sticking a stick figure before the chain.
Quite apart that drawing such a diagram is NOT a use case diagram, it’s not necessary to draw a diagram like that. The numbered steps in a scenario do that for you.
I repeat, then that use case diagrams provide a graphical overview of what’s in the textual use case descriptions. They have a limited but sometimes powerful use, just like other sorts of tables of contents. If you don’t think that use case diagrams are worth drawing then don’t draw them! There’s nothing wrong with the textual descriptions alone.
2 Use Case Diagram Symbols:
1. Symbol for an actor: a stick figure. This represents an actor, better described as role. The actor symbol should have a label underneath it with a description of the role that he/she/it plays in relation to the system: for example, bank customer, interview short-lister, accounts system. The actor is something that we are not modelling and so correspondents, perhaps, to the term external entity used in traditional modelling.
2. Symbol for the use case itself:
Ovals. These represent use cases and each should have a strong simple verbal statement placed inside it, such as open account, not effect account initialisation or some such.
3. Symbol for communication between an actor and a use case:
Straight lines. These represent communication between actor (see below) and a use case.
4. Symbol for include or extend: open-arrowed broken lines. This is used to show the include or extends relationship between use cases. Include is used where there is a chunk of functionality common among more than one use case or where it’s too unwieldy to be included in a base use case and so is spun off into a use case of its own.
Extends is similar to generalisation (see below) but is more formal/more tightly defined than generalisation. We won’t discuss extends in any more detail.
5. Symbol for generalisation:
A solid line with an open bounded arrow at the end. This represents generalisation and is drawn between two use cases or between two actors (see below). The entity at the non-arrowed end of the line is a special case of the entity at the other end.
3 Very simple, example of a use case diagram, illustrating how it can be regarded as a graphical table of contents:
Note the use of a system boundary, with system title. We model only what’s within the boundary.
4 Further Examples of Use Case Diagrams
This use diagram shows an actor (really meaning role) performing four possible use cases. Notice that each use case starts with a strong verb: open, deposit, withdraw and close. This is preferred compared to something like effect a/c opening transaction etc. Of course, one may have to show on the diagram the vocabulary used by the domain (e.g. banking, farming, fishing etc) and the domain may not necessarily use strong verbs.
Open a/c
Deposit
Withdraw
Customer Close a/c
The customer is represented with a stick figure and can either be a person or a non-human system. We do not model the stick figures. They are thus an external entity. In general the stick figure should show the role that is played, not the job title. Thus, in another possible example of a use case, a stick figure may be labelled job shortlister, and not human resources manager since we should reflect the precise role in the particular use case being played out. A human resource manager will have many roles.
Another example of a use case is shown below. Here Withdraw funds includes another use case, namely identify customer. We use includes where there’s a chunk of functionality that is repeated across several use cases and so we spin it off into a separate one. Sometimes it’s simply a chunk of functionality used only once but it’s considered clearer to un-clutter it from the base use case into a separate one.
Withdraw funds over internet is a special case of withdraw funds. The inheritance arrow points from the more specific/more usual/exceptional use case to the general. Even if internet transactions were to become the norm, we could still regard them, conceptually, as unusual. Another way of showing the relationship between these two use cases would be by converting the arrow into one identical to that pointing from withdraw funds to identify customer but applying the term <
5
Withdraw funds Web over Internet customer
Branch customer Withdraw funds
<
Identify customer
Yet another example is shown below on page 7. It’s described on page 8.
6 The find book use case above means that the position of the book on the shelf is found, something that has to be done if the book is to be disposed of , or if the book is to be re-shelved. Assistant librarians have three possible use cases to enact, whereas, library assistants, a lower rank, have only two.
7 The use case on the previous page (page 7) shows a library system. Limits exceeded is a special case of borrowing a book. In this case it’s a separate use case. A different policy decision on behalf of the developers could have made it a separate scenario just as credit card failure was just one scenario of the purchase a product use case. Limits exceeded simply means that the user currently has on loan a number of books equal to his/her borrowing quota and may borrow no more. Notice that lending a book and disposing of a book both require locating the book. This library is clearly a closed access one, since it’s a library assistant who finds the book on the shelf, not the reader. Libraries specialising in rare books tend to operate like this.
Discovering use cases:
Many use cases may exist in a particular system. The problem is discovering them all. One handy knack for doing this is to consider all the actors that interact with the system. Once you’ve considered them, you can think about all the use cases that they’re likely to be involved in.
Another technique is to consider all the events to which your system is likely to have to react. Sometimes an event requires a response from the system that doesn’t involve any actor but quite often some actor is involved in responding. That means that you’ve discovered another use case.
A third method is to do conceptual modelling (using predominately conceptual class diagrams) with the domain people at the same time as one is trying to discover use cases. The act of thinking about the system conceptually can cause use cases to be discovered.
A use case diagram for a restaurant:
Study this use case diagram and see if you can suggest any changes.
8 Business Use Cases and System Use Cases
Sometimes focussing on use cases can prevent one seeing new ways in which an organisation can be run. Perhaps there are new and different ways for actors to achieve their goals.
Considering business use cases helps to achieve a more radical change to an organisation’s practices, perhaps at the same time as re-computerisation is taking place. Rather than replace an old computer system with a new one that does more or less what the old one did, it may be worth reflecting on the whole manner in which the organisation goes about its business.
A business use case focuses more on how a business responds to the needs of its customers and to events, whereas a system use case is more about how a user interacts with a piece of software. Some developers have found themselves developing a number of business use cases and then for each business case, a number of system use cases.
End of chapter exercises:
1. Consider, in relation to an ATM, the use case withdraw cash. In addition to the MSS, what alternative scenarios are there that will need to be fleshed out in a sequence of steps? (Answer on page 10)
2. Consider the following use case diagram. Explain what it shows.
9 Hint: the difference between generalisation (indicated by a solid line with an closed white arrow at its end) and extend (indicated by a broken line with a open arrow at its end and the text
If you’re drawing your own use case diagrams, I suggest you stick to one or the other, and ignore the subtle difference between them. Each is designed to indicate a variant on normal behaviour, a deviation from the norm.
3. In what way might you regard these notes on use cases as being imbalanced, as they currently stand?
An answer to Question 1 above:
Some alternative scenarios are:
The customer’s card is not recognised and rejected. The customer enters the wrong PIN and is asked to re-enter it The customer enters the wrong PIN three times and the card is retained by the ATM. The customer enters an invalid figure for the amount of cash. The ATM attempts to connect to the bank’s main system, but it is out of action or there is a network failure, so it cannot connect. The ATM doesn’t have enough cash to meet the customer’s request. The customer’s account does not have enough funds to meet the request. The customer cancels the transaction part way through.
Each of these would have to be spelled out in a sequence of steps.
An answer to Question 3 above:
I think that the notes as they currently stand are imbalanced in that the author states that use case diagrams are really quite unimportant, and then proceeds to give many examples of them! Why does he not give more examples of showing how use cases are represented, i.e. in numbered steps of text? (“This defect will be remedied in due course. Revisit soon!” – the author.)
10