Use Case Diagram
Use case diagrams, which realise a behavioural aspect of the model. The behavioural view has an emphasis on functionality, rather than the control and logical timing of the system. The use case diagram represents the highest level of abstraction of a view that is available in the UML and it is used, primarily, to model requirements and contexts of a system. Use case diagrams are arguably the easiest diagram to get wrong in the UML.
There are a number of reasons for this:
- The diagrams themselves look very simple, so simple in fact that they are often viewed as being a waste of time.
- It is very easy to go into too much detail on a use case model and to accidentally start analysis or design, rather than very high-level requirements and context modelling.
- Use case diagrams are very easy to confuse with data flow diagrams as they are often perceived as being similar. This is because the symbols look the same since both use cases (in use case diagrams) and processes (in a data flow diagram) are represented by ellipses. In addition, both use cases and processes can be decomposed into lower-level elements.
- Information on the practical use of use cases is surprisingly sparse, bearing in mind that many approaches that are advocated using theUMLare use case driven. In addition, much of the literature concerning use case diagrams is either incorrect or has major parts of the diagrams missing!
An actor represents the role of somebody or something that somehow interacts with the system.
The system boundary is used when describing the context of a system. Many texts and tools ignore the use of the system boundary or say that it is optional without really explaining why. Think of the system boundary as the context of the system and its use becomes quite clear and very useful.
There are three basic types of ‘Relationship’ which are ‘Extends’, ‘Includes’ and ‘Association’. An ‘Association’ crosses a ‘System boundary’ and, wherever this happens, it means that an interface must exist. The ‘Extends’ relationship allows atypical characteristics of a use case to be defined via an ‘Extension point’ that will actually define these conditions explicitly.
Figure 5.66. Graphic representation of elements of a use case diagram
One of the problems that many people have with using use case diagrams is how to tie them into the rest of the system model. It is not uncommon to be presented with a beautiful set of use case diagrams and then to be presented with a wonderful system model with no relationships whatsoever between the two!
Examples and modelling
Use case diagrams have two main uses: modelling contexts and modelling requirements. Although these two types of use should be related, they are distinctly different. For a full description of using use case diagrams, see Chapter 7. This section will concentrate purely on the mechanics and practical use of use case diagrams. In addition, there are two types of context that can be modelled with regard to systems engineering: the system context and the business context. The first two example models show a business context and a system context for the ongoing chess game example.
Figure 5.68 shows the business context for the chess game. The business context shows the business requirements of the organisation and identifies actors (see the discussion on stakeholders in Chapter 7) that are associated with the business requirements. The business requirements that have been identified are as follows:
- ‘make money’, which is a business requirement that will be present on almost all business contexts in the world. This may seem obvious, but when asking for funding for a project the response from management is, invariably, ‘make a business case and then we’ll look at it’. By identifying the business requirements of your organisation, it is possible to start justifying expenditure for future projects.
- ‘ensure quality’ is a nonfunctional requirement that will impact on everything that the organisation does. This is particularly true when organisations are trying to obtain, or have already obtained, some form of standard accreditation.
- ‘make games’ is basically what the organisation does, which has two subtypes: ‘make chess’ and ‘make draughts’.
- ‘make chess’ is the main business requirement that the system used so far in this book has been concerned with. We can now see, however, how the requirement ‘make chess’ will help the organisation ‘make money’, which is very important. • ‘make draughts’ is shown simply to indicate that the company may make more than one type of game.
The actors that have been identified for the system must each have some sort of association with at least one use case. If an actor exists that does not have an association with a use case, there is something seriously wrong with the model.
Figure 5.69 shows the system context, rather than the business context. It is important that these two contexts can be related in order to justify why a particular project should exist.
Figure 5.69 shows the system context for the chess game. The use cases that have been identified are, at this level, very simple and very high level. The use case ‘play chess’ represents the main use of the chess system that is being developed. The second use case, ‘teach chess’, shows the secondary function of the chess system, which is to teach a ‘Learner’ how to play chess. One argument that is often levelled at use case diagrams is that they are too simple and fail to add anything to a project. However, no matter how simple, a good use case diagram can contribute to a project in several ways:
- They can be traced back to a business context to help justify a project. Quite often it is the case that a simple one-sentence description is required to sum up a whole project and a good system context will show exactly that.
- They can give a very simple overview of exactly what the project is intended to achieve and for whom.
- They can form the basis of lower-level, decomposed use case diagrams that add more detail.
It is also worth remembering that just because a use case diagram looks simple, it does not mean that it took somebody two minutes to create and did not involve much effort. This is only true when it comes to realising the model using a CASE tool, but even the most simple of diagrams may take many hours, days or even months of work.
Remember that what is being visualised here is the result of requirements capture, rather than the actual work itself.
Figure 5.70 shows how a single requirement may be taken and modelled in more detail, by decomposing the requirement into lower-level requirements. It shows the ‘teach chess’ requirement that has been decomposed into three lower-level requirements: ‘read set up’, ‘indicate move’ and ‘show thinking’. Each of these requirements is a component requirement of the higher-level requirement that is indicated by the special type of association ‘«includes»’, which shows an aggregation-style relationship.
The second special type of association is also shown here and is represented by the stereotype ‘«extends»’. The ‘«extends»’ relationship implies that the associated use case somehow changes the functionality of what goes on inside the higher-level use case. In the example here, the extending use case is ‘indicate error’, that extends the functionality of ‘indicate move’ in the event that something untoward happens and forces ‘indicate move’ to behave in a different way.
Figure 5.71 shows what a use case diagram should not look like, which is a mistake that is very easy to make.
The model in Figure 5.71 shows how a model should not be created as it defies the objectives of use case diagrams. There are several points to consider here:
- The definition of a use case is that it must yield some observable result to an actor. In the example shown here, the decomposed use cases do not yield any observable result to the actors – they are modelled at too low a level.
- Remember that the aim of modelling requirements is to state a user’s needs at a high level and not to constrain the user with proposed solutions. The example shown here has done exactly that and has started down the design road – which is inappropriate at this level.
- The diagram is turning into a dataflow diagram by starting at the highest level and decomposing until the problem is solved. Use cases are not the same as dataflow diagrams, despite appearances, and should not be used as such.