6 Use cases and actvity diagrams
6.1 Use case modelling
In this section, we take a closer look at use case modelling, and show you how it can be used to model the requirements for a product that includes the development of a software application or, simply, a system. Use case models act as a discussion tool between the requirements analyst and stakeholders, and offer a common language for agreeing the functions of a proposed system. In this discussion, we shall use the Unified Modelling Language (UML) notation (diagrams) for use cases to reflect the fact that the development team are the stakeholders as well as the client and the intended users.
The use cases for a system are a record of the intended behaviour of the system that is visible to its users. This behaviour is what the system does when responding to the events that arise from its interactions with a set of actors. The people who use the software system will be one group of actors, but there may be other systems (some of which could be software based) and devices (including computers) that must interact with the intended (software) system, which are also actors.
An actor is anything outside a software system that interacts with it. For example, in a system that allows people to buy goods over the Internet, the human users will be significant actors, but so too will be the credit card system that enables users to pay for their purchases. Representing other systems as actors lets you focus upon your area of concern. In UML, all actors (human or otherwise) are represented by stick figures as illustrated in Figure 2.
The contents of the use case ovals represent some tasks or coherent units of functionality, as the UML defines it, which the system performs. The detailed description of each use case is held elsewhere. An actor, shown by a stick figure, represents the role that a human or non-human entity outside the system, often called a user, might play. The line connecting an actor figure and a use case oval indicates an association between them, which represents communication between the actor and the use case. It means that the actor may be involved in carrying out the task; it does not mean that it must be involved, as we shall explain later.
The simple notations, like those in Figure 2, for the elements of a use case diagram are intended to be intuitive, even for a lay person who is unfamiliar with the notation. It is possible to exploit this simplicity to represent the main functions of a particular business. For example, if your business was a lending library, then its main functions to be represented in a use case diagram would be the borrowing of books, videos and CDs by its members. Copies of books, films and music are the things handled or used by people; they are examples of business objects.
Use case diagrams deal with functional requirements (things that the system must do) alone, but it is often recommended that, as you develop a use case diagram and come across nonfunctional requirements (qualities that the product should have such as how responsive the system should be), you should record them by annotating the use case diagram with a descriptive note. In the UML, a note is shown as a rectangle with the top, right-hand corner folded down (see Figure 3). Dashed lines are used to attach the note to the model element(s) to which it refers.
The system boundary, denoted in the UML by a rectangle surrounding the use cases is an important conceptual line that separates the system we are interested in from the rest of the world. By drawing the boundary around the system represented in a use case diagram, you are setting the scope of your solution. Figure 3 shows a boundary for the hotel chain use cases. In simple use case diagrams, it is common to omit the system boundary as in Figure 2.
Figure 3 illustrates a common problem. From the diagram alone, it is not clear which of the two actors, Guest or Receptionist, initiates the make reservation use case. It may even be that both are needed to complete the use case successfully. The UML provides several ways to deal with this problem. The simplest, which is shown in Figure 3, is to use a note to record this observation; you would then refine (that is to say, amend, improve or extend) the model when you know more about the use case.
The work context diagrams in MRP are related to use case diagrams through business events. Inside the system boundary is the work, and the actors represent either people or autonomous cooperative adjacent systems. The actors represent the context within which the work exists. The lines joining an actor to a use case represent communication (the flow of data). In this section, we are not only interested in the context of the work, we also want to look more closely at the work itself.