One of the most fundamental problems in software engineering is determining the requirements of a system. The notion of use-cases, introduced by Jacobson is an excellent approach. It complements the activity modelling approach developed by Lunn described earlier in the course, and has wider application.
The use-case approach requires the analyst to determine all the potential actors involved in a system. Actors are external to the system and make use of it. An actor is typically a person, but may be a third-party organisation or another computer system. One person may in fact be multiple actors, say a shop assistant may be a customer of the same shop at another time. We model actors, not individuals.
An actor makes use of a system in different ways. Each of these ways is known as a use-case. A use-case may involve a number of actors, just as an individual actor may make use of several use-cases. We draw little stick men to represent actors and ovals to represent use-cases. In a banking system where a customer can withdraw money, we would draw:
Of course, to withdraw money, a customer must have put money in, so there is at least one more use-case.
Now it might be that the system which is being implemented in the bank needs to involve a cashier for depositing, but that to withdraw money the customer has to use the cash machine. The cashier is then an actor.
And so we build our model of the ways the system is used. We might add two more use-cases of the bank system.
Examining this, we see that there is probably a need for another actor. (I never borrowed money without having to grovel to the bank manager, and the bank manager always looked carefully at my pitiful balance before grudgingly saying yes).
Use cases may in fact use other use-cases. The withdraw cash use-case would make use of the account balance use-case before issuing the money.
A use-case is a very abstract view of what the system provides to the various actors who use it. It is not intended to give a detailed, blow-by-blow account of how the services are provided. Therein lies the beauty of the approach. By keeping out detail, it is possible to reason at a higher level. Later the use-cases can be opened out using object-interaction diagrams to begin to define their precise operation.
So what about our object oriented fairy tales? Where are our use-cases for those? We might model it in this way.
So what about Red Riding Hood and the Wolf and all that? What the example points out is that use-cases are very abstract. They do not define the architecture of the system (the objects and how they interact). They merely list what the system does. Almost all fairy stories would fit into the above use-case.
The first stage of any project should be an analysis of the use of the system being devised. The requirements stage in object modelling, as described in this course, involves constructing use-case models of the system. The next stage is to open up the architectural issues by elaborating the use-cases as scenarios, described earlier.
Here is a simple use-case model for a computer:
Programmers are distinguished from ordinary users of the computer by the fact that they compile and edit programs as well as running them (for testing) and printing files. Edit and compile use-cases make use of the run-program use case (editors and compilers being just programs to be run).
Use-cases are simple to describe to potential users of the system,
and therefore should be used in the dialogue as part of requirements
analysis.