This section presents an overview of the symbols used in use case modeling; the important ones will all be discussed in detail later.

Symbol	Name	Interpretation
or	Actor	An entity (human or otherwise) external to the system, and which interacts with it
or	Use case	A service or unit of functionality
	System boundary	Indicates the division between the system being designed and the rest of the world
	Communication association	The line indicates that a particular use case is associated with a particular actor. The name is optional and often omitted. An arrow can also optionally be used; where present it does not indicate a flow of information (such as in a data flow diagram)
	Use case association	Indicates that to use cases are related in a particular way, e.g., the one use case's behaviour includes the behaviour of another use case
«name»	Stereotype	Indicates that the symbol it is attached to belongs to a particular category
	Generalisation	Indicates that the two symbols it connects are related by a generalisation-specialisation relationship. For example, one actor is a sub-type of another, or one use case is a type of another. Both the name and the stereotype are option
	Note	The designer may, and should, qualify any part of the model with a textual note if it improves the clarity of the design

An actor is any entity, human or otherwise, that is external to the system being designed. Two symbols are available in the UML specification:

Figure 3.1. Actor representations

An actor can be represented by a stick figure.

Alternatively, an actor may be represented by a class with the «actor» stereotype.

The “stick figure” symbol is the more expressive, but can lead to confusion if the actor is not in fact a human but a machine. The rectangle symbol is the standard UML symbol for a class. What this symbol says is that the entity is a class that is a member of the category “use case”. The reason why an actor is a type of class will be discussed later. Because of its greater expressive power (that is, an ability to make a more immediate impression on the viewer) it is probably best to use the stick person figure where possible.

Since use cases are technically classes, and by convention class names start with a capital letter, names of use cases should also begin with a capital letter. The UML specification does not insist on this, but it is common practice.

Two interesting philosophical issues are associated with actors. First, should the actor be a person, or the part of the computer with which they interact? For example would we ever want an actor called “Keyboard” or “Printer”? In designing a word processor, for instance, there is only one human user and they fulfil all the roles within the system. But you may wish to distinguish between, say keyboard, mouse, and printer actions. However, distinguishing between different pieces of hardware is probably inappropriate at this level, and it could be argued anyway that use case modelling is not a helpful way to begin the design of a word processor. On the other hand, a supermarket stock control system may accept input from a bar-code scanner at the checkout, when the cashier registers the prices of the customer's purchases. Is the actor here the cashier, or the bar-code scanner? Perhaps neither is appropriate, as the cashier can probably enter the identities of products manually if the bar-code scanner does not work. Do we want to distinguish between different techniques for entering item details at the highest level of analysis? Probably not. In this case we could perhaps invent a more abstract actor (called, perhaps, “point-of-sale”) that provides the key message: that something at the point-of-sale interacts with the system whenever a purchase is made. In summary, then, when a human being interacts with a computer system, it is not necessarily the case that the human is identified as the actor. It is often clearer to use a non-specific entity as the actor.

The second philosophical issue is concerned with whether an actor has to be an active participant in an interaction. For example, in a computer-based building security system, do we want “Burglar” as an actor? A burglar does not actively interact with the system; indeed they would probably rather not interact with it at all. Moreover, a burglar may interact with the system in a number of different ways, all passively. In this case, it may well be better to identify the sensor devices as actors. What about the fire alarm? Presumably “Fire Detector” is a better actor than “Fire”?

The UML gives us no guidance on these issues; although the letter of the UML specification is that actors can be any external entity, the spirit of the standard seems to be that actors are people who interact with the system in a rich, complex way. There is little concern for “trivial” actors like printers and fire detectors.

These complications notwithstanding, actors do not have to be human beings; they may be external computer systems. For example, we may be designing a system for allocating staff work timetables that draws information from a central record of employees which is part of the payroll system. In this case, “Payroll System” would be an actor.

You should bear in mind that you will never implement an actor; by definition an actor is external to your system. You will, however, implement the interfaces used by actors to interact with the system.

A decision that the use case modeller has to make is whether to treat (human) actors as expressions of a person, or as expressions of a role within an organisation. Perhaps an example will help to clarify this issue. Suppose that you are designing a computer system to automate the operations of a large library. The system should maintain the library catalogue, provide information to staff and readers, check books in and out, provide guidance on re-shelving returned books, manage inter-library loans, warn users about overdue books, and manage collection of fines and subscriptions.

Most people faced with this problem begin by considering the types of people who will use the system. Two such groups come to mind immediately: library users and library staff. In a library one will often find that staff members have very general job descriptions, and will take a hand in most of the normal operations of the library. We will refer to these people as “librarians”. So far our use case model has two actors: Librarian and User, and these two actors interact with all the use cases that we could identify. In this case we are treating “Librarian” as an expression of a person. We could get a lot of information about what services the computer system should provide by reading the job description of a librarian.

The problem with this approach is that it has no high-level structure, and is therefore not very expressive. We could convey much the same information as the use case model by merely writing a list of library services. There is no scope for simplification and management of the model by generalisation (see later). Furthermore, it carries the implication that librarians are interchangeable, and any librarian can do the work of any other. Even if this is true at the time the system is designed, it may not continue to be true. For example, more junior staff members may not have authority within the system to order new books for the library. A person managing the stock of books is interacting with the system in a totally different way to the person who is, for example, signing up new library users. The fact that these to job functions may perhaps be carried out by the same physical human being is irrelevant; they are totally different roles within the system, and should be considered to be different actors.

Of course, we could now go to the opposite extreme and create a new actor for every service the system provides, but this leap from the frying pan into the fire would still result in a model with no structure that is difficult to simplify. In addition, there may be a loss of expressiveness. For example, in the library system it is quite likely that both staff and users can browse the catalogue of books. They will quite possibly do this in an identical way, and see exactly the same information. Moreover, this activity is completely separate from any other functionality the system may provide. So we may be tempted to create a new actor (perhaps called “Catalogue Browser”) to model this role within the system. But we will have lost a very important piece of information by doing this: the fact that both staff and users can browse the catalogue implies that we have to put computer terminals or workstations on both sides of the counter, so to speak.

So what is the correct approach? In short it is the one which leads to the simplest correct model which is still adequately expressive. Of course it is more important that the model is correct than that it is simple. To arrive at this point may require that your choice of actors be modified several times during the course of construction of the use case model.

In the last section we considered the distinction between actors as people and actors as roles, and clearly this is an issue that needs to be taken seriously by the requirements engineer. However, it only becomes an issue when we know enough about the way the system is to be used to have a potential set of actors to hand. We now have to consider the situation where the analyst knows nothing at all about the system to be developed, and doesn't have the first idea what the actors are. Many development jobs begin like this.

The analyst's first recourse is to the stakeholders identified through the earlier requirements engineering steps. The stakeholders should certainly be on the initial list of actors.

You may then ask what information is to be manipulated by the system, and where that information will come from. All information that is not present in the system at the instant it begins work will be coming from an actor of some sort. If there is not enough information to do this, then this is a sign that further information must be elicited from the customers.

Other potential actors include all the computer systems with which the system will interact, and any other hardware devices (including hardware such as printers, bar-code readers, and so on).

There are also various “standard actors” that all systems of any complexity are going to need, and which may not have been considered by the clients. These include the person (or rather the role) which maintains the system after it has been put into service, the person who performs software upgrades and tests, the person who carries out and checks backups (if not automatic), and so on.

When developing a software system to replace a manual procedure, or an older software system, actors may be identified by watching people go about their daily work, and by speaking to people who are experts on the business the system has to carry out.

It is probably not possible to identify actors without some consideration of the services that the system provides. In practice design work will switch between consideration of the actors and consideration of the use cases.

All of the forgoing was, we hope, largely common sense. Now it is time discuss a technicality. We will state the principle, and then go on to explain it.

The principle is this: the UML specifies that an actor in a use case is a class, and individuals are instances of that class.

The actors in a use case model do not represent individuals (individual humans or individual computers), but classes of individuals. For example, an actor called “Customer” models all those properties that customers have in common; it is, in effect, the class of all customers. It will be assumed by anybody who reads your model that the ways in which the Customer actor interacts with your system will apply to all customers. So if some customer or group of customers is expected to behave differently, then we need a different actor to handle this case.

This may seem trivially obvious, but the complication is that the above principle is true even if there is only one instance of an actor. For example, a company may have only one managing director, and may be constrained by law only to have one, but if the managing director interacts with the system you are designing in a specific way, then they are a class, not an individual. The problem is that although the designer understands intellectually that actors are classes, they may still have a specific individual in mind, leading to a bad model. The reason is this: suppose Joe Bloggs is a bank clerk; there can be different types of bank clerk, but it is meaningless to talk of different types of Joe Bloggs. And the ability to simplify a model by identifying where one thing is a type of another thing is a key feature of use case modeling, and indeed of all types of object-oriented design.

The system boundary demarcates the system being designed from the rest of the world. It is denoted simply by a box with the name of the system in the corner.

Figure 3.2. The system boundary

Use cases are inside the box, actors are outside. Because different symbols appear inside the box and outside, in practice it is usually unnecessary to show the system boundary explicitly. One circumstance in which it is necessary to show it is if you wish to show the use case models of two or more different systems on the same diagram. This may be necessary if you are designing a system which interacts with another in a way that is too complex for you to show the external system as simply an actor.

Some modeling software will draw the system boundary automatically.

In the design of a large, complex system, it is said that the boundary may “move” during the design operation. In fact what is happening is that decisions are being made about what functionality is the responsibility of the current design exercise, and what is not. For example, it may turn out that during the analysis of a staff payroll system, management of staff health records — which was previously the responsibility of another system — is seen to be more appropriately part of the payroll system. In effect, the system boundary has “moved” to encompass part of another system. Needless to say, such movement needs to be settled as early in the development process as possible.

In the UML, a use case can be represented in two different ways:

Figure 3.3. Representations of use cases

Use cases may be represented by a title within an ellipse.

Use cases may be represented by a class with the «use case» stereotype.

Most designers will immediately recognise the oval as a use case (the oval symbol has no other meaning in the UML) so this symbol is to be preferred where available. The other symbol reflects the fact use cases are technically classes (just as actors are), whose category is “use case”. We will discuss later what is meant by a class of use cases.

Although use cases are central to use case modeling — and indeed to many object-oriented development strategies — there is surprisingly little general agreement on what a use case is. In fact, there are people currently working on doctoral theses whose subject is what a use case is supposed to be showing. The following definition is taken from version 0.8 of the UML specification:

This rather terse definition was all the UML had to say about the nature of use cases at that point. In version 1.3, there is the following, somewhat expanded, definition:

Versions 2.2 states:

In fact, these are very general descriptions, and not particularly helpful to the practitioner; here are some more pragmatic views of the use case.

Relationships between use cases

It is possible, and usual, to show that one use case is related to another. The standard notation for this is a dashed line:

Figure 3.4. Use case association

An association between use cases is typically shown with a dotted line.

A stereotype can also, optionally, be given to the relationship. This indicates the type of relationship, of which the most important are «include» and «extend». An example of an «include» relationship is show below.

Figure 3.5. Use of stereotypes in use case relationships

In this example, “Credit Ordering Service” includes “Ordering Service”, that is, all the behaviour of “Ordering Service” will be invoked whenever “Credit Ordering Service” is invoked. This is sensible if ordering something on credit is the same as ordering something with payment, plus a bit extra.

Typography

Stereotypes in the UML are enclosed in guillemets: « and ». Often, if the typist or application is unable to represent these symbols, << and >> (two less-than or greater-than signs) are used instead. However, now that Unicode display is available on most operating systems, the guillemets are to be preferred. The Unicode code points for « is u+00AB, and » is u+00BB. Your operating system will no doubt have an easier input method available to you than entering Unicode code points directly.

In the UML, «extend» is similar to «include», with the distinction that with «extend» the behaviour of the extending use case will not always be invoked.

A note on terminology and semantics

The UML uses the term «extend» here because Jacobson used this term in his earlier work on use case modeling. Unfortunately, many authors use the term “extend” to mean a generalisation relationship — in other words, that one thing is a type of another thing. This is particularly relevant in Java programming, where the word “extend” has this (generalisation) sense, and not the sense defined in the UML. To further complicate matters, the «include» relationship does denote a kind of generalisation: a “credit ordering service” is a type of “ordering service”. These complications have little impact on use case modeling or on programming in practice, but they do cause confusion among students (and others), and it is good to be aware of them.

A use case diagram on its own may well be a useful method for describing the large-scale structure of a system; however, it is of very limited use as the input to a more detailed design operation. In practice it is necessary to describe use cases in a more detailed fashion if the model is to be interpreted properly.

Such a description is not only an aid to communication, it is an aid to validation. Validation is the process of ensuring that a specification is correct, in contrast to verification, which is the process of ensuring the product meets its specification (see Chapter 9, Software Testing). If the analyst cannot describe a use case in a way that makes sense to someone else, then one of two things has happened:

Either case needs to be corrected.

How do we describe use cases? Two approaches are in widespread use.

The concept of generalisation

Generalisation is one of the most important concepts in use case modeling, and indeed in object orientation in general. When stated as a principle it appears trivially obvious, but it has profound implications. The principle is this:

Generalisation

Entity A is a generalisation of entities B, C... if the behaviour, attributes and associations of B, C... are found in A, and no properties of A are absent from B, C...

We say that entities B, C, and so on, inherit the properties of A. This can also be stated as: A is a generalisation of B and C if B and C are types of A (we could also say sub-types or sub-classes); A is a generalisation of B and C if B and C extend the functionality of A, while retaining all of A's functionality

Here is trivial example: Dog and Cat are types of Mammal, because all dogs and cats share the basic properties of mammals (e.g., having fur, being warm-blooded, having four limbs). We may say that Mammal is a generalisation of Dog and Cat; alternatively we could say Dog and Cat are specialisations of Mammal, or types of Mammal, or sub-classes of Mammal. Note that when we say that Mammal is a generalisation of Dog and Cat we are not saying anything about whether there are other types of Mammal; there may be, but we haven not specified any.

Another example: A business wishes to automate some of its sales procedures. Preliminary interviews reveal that there are a number of staff roles in the Sales department. A salesperson can place orders on behalf of customers and check the status of these orders. A technical salesperson has the same duties, but additionally is able to provide customers with detailed technical advice (which we would not expect an ordinary salesperson to be able to do). A sales supervisor is a salesperson, with the additional responsibility of creating new customer accounts and checking their credit-worthiness. It is reasonable to assume that Salesperson is a Generalisation of Technical Salesperson and Sales Supervisor, because the technical salesperson and sales supervisor have all the properties of a salesperson, and some extra.

We can construct an outline use case model to show these relationships. We will assume for the sake of simplicity that the use cases are “Place Order”, “Check Order”, “Create Account”, “Check Credit”, and “Technical Advice”. Without generalisation, we obtain the following model:

Figure 3.6.  A use case example, without generalisation

While this is logically correct in that it accurately captures the information given in the text, the number of associations in the diagram makes it difficult to read. It provides no more insight into the system than does the textual description.

In the UML, the symbol for a generalisation is an arrow:

Figure 3.7. Use case generalisation

The arrowhead points to the more general entity. If we take account of the generalisation relationships present in the “Sales” example, we reach a model like this:

Figure 3.8. Use case example, with generalisation

This model does not have to show that “Technical Salesperson” and “Sales Supervisor” can check orders and place orders, because this is implied by their being sub-classes (specialisations) of “Salesperson”. Not only is this model easier to read, it gives a more immediate insight into the system being analysed.

You will not always be able to simplify a use case model using generalisation, but you should be on the alert for the opportunity to.

In the example above, “Salesperson” was an actor in its own right, as well as being a generalisation of other actors. That is, we would have identified “Salesperson” as an actor with or without generalisation. Sometimes, however, it is appropriate to “invent” actors simply to stand as generalisations of other actors, with the purpose of simplifying the model. These actors are referred to as “abstract”, because they abstract, or simplify, a system. An abstract actor is a special case of an abstract class. We shall have more to say about abstract classes in the next unit.

A simple example

This is an example of a complete, simple use case diagram. It is based on the “Sales” example presented earlier. We will start with a description of the business, then present the use case diagram and the textual specification of the individual use cases. Note that a use case model is incomplete without this specification, either in plain text or something else.

A use case example

A retail business wishes to automate some of its sales procedures. The retailer buys items in bulk from various manufacturers and re-sells them to the public at a profit. Preliminary interviews reveal that there are number of staff roles in the Sales department. A salesperson can place orders on behalf of customers and check the status of these orders. A technical salesperson has the same duties, but additionally is able to provide customers with detailed technical advice (which we would not expect an ordinary salesperson to be able to do). A sales supervisor is a salesperson, with the additional responsibility of creating new customer accounts and checking their credit-worthiness. A dispatcher is responsible for collecting the goods ordered from the warehouse and packing them for dispatch to the customer. To assist in this operation, the computer system should be able to produce a list of unpacked orders as well as delete the orders from the list that the dispatcher has packed. All staff are able to find general details of the products stocked, including stock levels and locations in the warehouse. A re-ordering clerk is responsible for finding out which products are out of stock in the warehouse, and placing orders for these products from the manufacturers. If these products are required to satisfy an outstanding order, they are considered to be “priority” products, and are ordered first. The system should be able to advise the re-order clerk of which products are “priority” products. A stock clerk is responsible for placing items that arrive from manufacturers in their correct places in the warehouse. To do this the clerk needs to be able to find the correct warehouse location for each product from the computer system. Currently, the same person in the business plays the roles of stock clerks and re-order clerk.

Figure 3.9, “A full example”, shows the associated use case diagram.

Figure 3.9. A full example

Brief use case specifications

• Check Stock: Allows a user to check the levels of stock of any item held in the warehouse, and where that item is shelved. A particularly important scenario is that of obtaining a list a stock items for which the stock level is zero, that is, of which there is no stock in the warehouse.

• Place Order: A salesperson places an order on behalf of a client. This has the effect of making information about the order available to Dispatch Service. The order remains on the system until it has been packed and dispatched.

• Dispatch Service: Allows a list of outstanding orders to be obtained, and updated when orders are packed. An order is not available to this service if it cannot be satisfied because there is not enough stock in the warehouse.

• Priority Reordering: Obtains a list of items that need to be re-ordered urgently, as the business cannot satisfy its own orders without them. This use case makes use of Check Stock (to determine if an item is out of stock) and Check Order (to determine what stock is required to satisfy all current orders)

• Check Order: Obtains details about any outstanding orders, including what stock items are required to satisfy the order. This use case is used by salespeople to advise customers, and by the Priority Reorder use case to determine which items of stock must be replaced quickly.

• Check Credit: Used to find out whether it is safe to extend credit facilities to a client. This use case refers to external credit reference agencies (not shown).

• Create Account: Used to register a new customer. If a customer asks for credit facilities, this use case includes Check Credit. Otherwise it doesn't have to.

• Technical Advice: Provides technical specifications for selected products. Used by technical sales staff to provide advice to customers.