3 USE CASES  20/10/97

3 Use cases

In this section we consider the uses and purpose of the most central of the UML diagrams.

Use cases

document the behaviour of the system from the users’ points of view. They help with three of the most difficult aspects of development:

• capturing requirements

• planning iterations of development which are good for users

• meaningful system testing

They were first introduced by Ivar Jacobson (early 90s), developing from scenarios.

They are independent of OO – strength or weakness??

Slide 20

(Jacobson seems to me, admittedly on limited evidence, to be the maverick or wild child of the Three: he has some superlatively good ideas, but there’s some evidence that he doesn’t always maintain a proper connection with reality. See, for example, p116 of the Revised Fourth Printing of OOSE-AUCDA. Everything I’ve read by him has been very prescriptive: he seems to say “Here is my way to do it. It’s right, absolutely right, all the time.” I think most of what he says probably is right: but read with critical faculties alert. Use cases are his main thing. Enough said.)

A simple use case diagram

(after Jacobson et al. Software Reuse fig 3.16)

Slide 21

More complex UC-diagram

(after Fowler UML Distilled Fig 3.1)

Slide 22

Note that these diagrams show, not a single use case, but all use cases for the given system: each oval represents a use case.

\overline{SEOC97  Id : notes3.tex, v1.11997/10/1509 : 08 : 45pxsExppxs  20}

3 USE CASES  20/10/97  3.1 Actors

3.1 Actors

Actors

An actor is shown in a use case diagram as a stick figure. An actor can be:

• a human user of the system in a particular rôle

• an external system, which in some rôle interacts with the system.

Or more specifically, a particular kind of user. For example, the bank has many customers, but we only show one Customer actor on the use case diagram.

The same human user or external system may interact with the system in more than one rôle: he/she/it will be (partly) represented by more than one actor. (e.g., an bank teller may happen also to be a customer of the bank).

Slide 23

Remark on actors in Rose The Rose tutorial points out that, inside Rose, “Actors are treated as stereotypes of classes” which might give you the mistaken impression that for each actor there will be a corresponding class. But in fact the connection between actors and classes is for Rose’s convenience only: Rose is presumably reusing some of its internal code for representing classes in order to represent actors. In general, there will not be a class in the system corresponding to an actor – the actors are normally outide the scope of the system itself.

“Stereotype” by the way is UML’s way of attaching extra classifications to model items; it’s one of the ways that UML is made extensible. We will not discuss them in this course: all you need to know is that if a Foo has a stereotype Bar it means it has been classified as being an instance of a particular kind, Bar of Foo at the modelling language level.

Actors tend to be comparatively easy to identify. (If they aren’t, be very suspicious: you may possibly be being pushed into embarking on the surprisingly common task of building a system which somebody wants built but which nobody really wants to use.) They can be extremely important from a political point of view, but are unlikely to be very important from a technical point of view. Technically, the use cases themselves are more important. (For example: if two use cases start off involving the same actor, but later it turns out that two different actors are actually involved, it’s most unlikely that our system will be affected. Unless, of course, this means that the system is now less valuable to its sponsor, in which case it may be cancelled.)

Even here, though, we encounter interesting questions. It’s likely to be clear who are the human users of a system. It may be much less clear which systems should be represented as actors: do we really want, as I suggested in the slide, to show every system which may interact with ours? I think we probably do, but Fowler holds a different view. Here’s his summary of the options (Fowler p46):

3 USE CASES  20/10/97  3.2 Anatomy of a use case

1. Some people feel that all interactions with remote systems need to be shown on the diagram. For example, if you need access to Reuters in order to price a deal, you should show a link between the Price Deal use case and Reuters.

2. Some feel that you should only show external-interaction use cases when it is the other system that initiates the conteact. Using this rule, you would only show the use case for the Accounting System if that system invokes some process to tell the source system to do that.

3. Some feel that you should show system actors only when they are the ones who need the use case. So if the system generates a file every night that is subsequently picked up by the Accounting System, then Accounting System is the relevant actor because it is the one that needs the file produced.

4. Some feel that thinking of a system as an actor is the wrong focus. Instead, they deem that an actor is a use who wants something from the system (for example, a particular file). In the case of our example system, the actors would be the internal auditors of the company.

Fowler favours option 3. On the whole I prefer option 1: taking option 3 seems to be treating an actor differently depending on whether it’s a human or a machine, since we certainly want to show all human users, whether they are getting benefit from the use case or (as in the case of a bank teller) helping to provide benefit to another actor. As Fowler says, this is a matter of “stylistic variation” – we will not, in this course, designate any of these options as right or wrong. (Though of course, following one blindly could lead to things that were definitely wrong. For example, blindly following option 4 could lead you to analyse in detail the workings of the Accounting system, which would probably be a waste of time; following option 1 blindly might lead to a diagram cluttered with irrelevancies; following option 2 or 3 blindly might lead to omitting major system interactions from your requirements capture process. You need to use your common sense and be flexible.)

3.2 Anatomy of a use case

What is a use case?

A use case is shown on a use case diagram as a named oval. The name describes some coherent work unit of the system which has value for an actor, e.g. Withdraw Money or Analyze Risk.

The use case includes a (textual) description of the (a?) sequence of messages exchanged between the system and any actors, and actions performed by the system, in order to realise the functionality.

It may include logic to handle unusual or alternative courses, e.g. “if the customer’s balance is too low, stop and say so” even though these may result in the actor being unsatisfied.

A use case may be associated with other UML models which show how it is realised.

(Secretly, a use case is a winning strategy for a certain game, but that’s another story...)

Slide 24

Textual part of a use case

Slide 25

If an actor takes part in a use case, either sending or receiving a signal or some data, the actor is connected with the use case by a line, which represents a Communicates relationship between the actor and the use case. You may see (e.g. in Jacobson) these lines shown with an arrow on one or both ends, showing the sender at the origin of the arrow and the receiver at the other – if the use case involves several interactions in different directions we’ll have an arrow at both ends. Fowler uses lines without arrows, as prescribed by UML 1.1, and that’s what we’ll do here. Rose defaults to having a single arrowhead, but you can (and I recommend that you do) fix this by:

1. double clicking on the arrow to get its specification box

2. choosing the tab Role B Details

3. checking the Navigability box

Alternatively (I just found out), you can achieve the same aim more simply by selecting the arrow and then choosing Navigable from the short-cut menu, on the right mouse button. (I don’t know how to make this be the default navigability for all Communicates associations in use case diagrams – I imagine you can, if only by defining a custom toolbar. If anyone finds out how, please let me know!)

Notice that the way in which the use case is described will vary through the development process. To begin with it’s important that we identify what the system should achieve in each use case, not how it should achieve it. Later we’ll choose an implementation. This may well involve changing the actors; probably not the one who wants the use case, but the ones who take part in a “helping” capacity. As an extreme example, you might start off assuming that to satisfy the bank’s Customer who wants a Withdraw Money use case, you need to involve the actor Bank Teller, but later you might decide to implement this using an automatic teller machine, in which case the Withdraw Money use case will be changed to involve an ATM actor.

Later we’ll see how to match up use cases with other UML diagrams, in order to demonstrate how the design realizes the use case.

3 USE CASES  20/10/97 3.3 Use cases for requirements capture

Even in the definition of a use case, we need to be careful, for Jacobson/Griss/Johnson in Software Reuse (p66) say:

A use case is a sequence of transactions performed by a system, which yields an observable result of value for a particular actor.

This is what UML (and others, e.g. Rumbaugh’s OMT) calls a scenario: it describes a single path through the system with no alternative courses.

3.3 Use cases for requirements capture

Requirements capture

Use cases can help with requirements capture by providing a structured way to go about it:

1. identify the actors

2. for each actor, find out

• what they need from the system

• any other interactions they expect to have with the system

• which use cases have what priority for them

There may be aspects of system behaviour that don’t show easily show up as use cases for actors.

Slide 26

We only connect an actor with a use case when the actor participates in a use case, not, more generally, when an actor is in any way concerned about the existence of a use case. So there may very well be cases when a work unit is essential, but not particularly valuable to any of the actors which participate in it. The classic example is when a utility company sends quarterly bills to each of its customers. The company as a whole gets benefit from it; but the only obvious actor in the use case is the customer, and possibly the company’s mailing office, which doesn’t itself particularly benefit from sending out the bill. I recommend that you do show such work units as use cases when you discover them, even though this involves relaxing the requirement that every use case is of benefit to one of the actors involved – but do be careful, in these cases, to ensure that the use case does represent a real requirement.

3.4 Example

3.4.1 A system for CS4 administration

The current situation Towards the end of each academic year, the Syllabus Committee determines which courses will be available to CS4 students in the following year.

At the end of each academic year, the Head of Department allocates duties to members of teaching staff and others; in particular, one person is assigned to lecture each of the courses which are supposed to be available in the following year. (We’ll call these people lecturers for simplicity.)

3 USE CASES  20/10/97  3.4 Example

Each lecturer updates the CS4 Course Handbook entry for his or her course. The CS4 co-ordinator updates other parts of the handbook, and checks the course entries produced by the lecturers.

Somebody in the Undergraduate Teaching Office (from now on we’ll call any such person “the UTO”) produces the paper version of the course handbook; the CS4 co-ordinator produces the HTML version by running latex2html on the latex source.

The CS3 Co-ordinator is supposed to give a list of the students entering CS4 from CS3 both to the CS4 co-ordinator, and to the UTO. The CS4 co-ordinator tells the UTO about any students entering CS4 other than from CS3, for example, non-graduating students. The UTO keeps the master list of all CS4 students, and updates the mailing list cs4.

CS4 students provisionally register for courses by filling in paper forms and handing them in to the Undergraduate Teaching Office. The UTO checks that every student who registers is listed as a CS4 student, and that every CS4 student is registered for a reasonable number for courses.

The UTO then produces for lecturers lists of the students taking their courses. These arrive not sooner than week 3, in particular, too late to be useful for letting lecturers know how many copies of things to make...

The investigation The Department has asked you to investigate the possibility of developing a system to automate parts of this process, because they hope it may be possible to:

• decrease the burden of routine work on all staff, especially the poor overworked CS4 co-ordinator

• allow students to register for courses on-line

• make it easy to obtain (from the UTO) up-to-date, reliable information;

• improve the traceability of such information;

• make information such as the course handbook and lists of students taking courses available sooner.

Draw a simple use case diagram for such a system.

Hint: not all the information you’ve been given will be relevant at this point.

One possible solution

Slide 27

New references

I’ve made heavy use of Fowler’s UML Distilled again here. Also:

Jacobson, I. et al. Object Oriented Software Engineering: a Use Case Driven Approach Addison Wesley 1994.

Jacobson, I., Griss, M., and Jonsson, P. Software Reuse: Architecture, Process and Organization for Business Success Addison Wesley 1997.