6.11 Issues with use cases
There can be a tendency to make diagrams too complex. You can reduce the complexity of your use case diagram by:
redrawing it at a higher level of abstraction;
splitting it up into smaller modules, which the UML calls packages.
In the case of the hotel chain, we might partition our model into the following three packages:
checking guests in and out of their rooms;
Each package may then be assigned to a separate developer for implementation. However, the project team must then deal with the dependencies between the three packages as they work towards a solution that incorporates all three packages.
The above example about access to the hotel system illustrates a more general modelling problem. It is often difficult to separate a problem from its solution. For example, it may seem obvious that, to gain access to the system, an authorised person would enter their name and password. However, this might not be the most appropriate method of authentication and it would be better to simply state that access to the system should be by authorised personnel only using an appropriate authorisation process. In practical terms, you should ask yourself the question, ‘Am I analysing the problem or designing a solution?’
In software development, this question can be hard to answer. You may find it easier to think of analysis as a way of investigating a problem and opening up choices, whereas design is a way of taking decisions and narrowing down the number of choices to arrive at a solution.
It is easy to forget that a use case diagram is part of the structural view of a system. It defines what tasks are to be supported, not the order in which they might occur. Although you record a workflow in the steps of each scenario of a use case, there will have been some initial analysis of the best or preferred way to achieve the goal of that use case. We shall look at how you can explore different scenarios in the next section, where we consider how the UML allows you to represent a workflow as it unfolds over time.
Use case modelling has led to most disagreement among experts and practitioners when they discuss the definition and the use of the UML. Space does not permit a great deal of elaboration of the arguments, but it is worth considering the kinds of problem that developers can have with use case modelling.
Having decided to model a system in one or more use case models, the most important thing to consider is their intended audience. You need use cases that can be read and understood by the domain experts as well as the team of developers. The domain experts usually come from the customer's area. If you cannot demonstrate the benefits of your proposed system to them, there is little chance of it being acceptable to the customer. All technical projects of any kind are vulnerable to this risk. Your only defence comes from your skills, experience and professional ability.
In the same way, your use case models must be useful to the rest of your team. For example, those who will be testing the new (software) system must be able to generate their tests from your use cases and the subsequent design artefacts.
In terms of the content of each use case diagram, you should avoid the use of the «include» and «extend» stereotypes for an audience that is less familiar with the UML than your team members. The simple notation for actors and their associations with use cases has been a factor in their favour.
A common problem with use case modelling is deciding the size and scope of each use case. There is no consensus on this issue because of the wide variety of contexts and viewpoints. However, we recommend that a use case should be smaller than a business process. In the hotel chain, for example, the handling of reservations would be treated as a separate business process to checking in and out. That is to say, make reservation is only one of the tasks in the process of handling reservations.
An associated issue is deciding whether or not you have identified appropriate use cases. You should always review your model and ask yourself, ‘Do the actors that have been associated with a use case actually gain value from the use case?’ If the answer is ‘no’, omit the use case! A useful technique for identifying appropriate use cases is to determine the life history of the objects in the system. For example, in the eTMA system, the central object is an assignment. In broad outline, its life history goes something like this. The student creates the assignment and then submits it to the university. Then a tutor downloads the assignment, marks and comments on it and sends it back to the university. Finally, the student retrieves (downloads) the marked assignment and reads the tutor's comments. This leads to use cases that we might name as: submit TMA, download TMA, mark TMA, return TMA, and retrieve TMA.
The main problem with use cases, in general, is the risk of straying into a top-down, functional decomposition and away from the object-oriented viewpoint that is embedded within the UML. It is easy to decompose each use case into smaller use cases in your search for reuse through the «include» stereotype. Indeed, if you are making your project plans according to the use cases that you identify, the urge to find a use case of a size that you can easily estimate is understandable. A good project manager will make some assessment of this risk and review it upon each iteration of the life cycle.
It is worth reiterating that, in the process described in MRP, the purpose of use cases is to help with the understanding of the work that the product is to become a part of. There is always the danger that the use case diagram becomes a model of the product (a solution) rather than a model of the work (the problem), with the result that the product simply automates the current work and no attempt is made to identify the best product to help with the work.
No single technique can guarantee that you will collect and identify all the users' requirements. So, if you spend too much time modelling use cases, you can become distracted by the process of modelling and lose track of the main aim, which is to capture the functional requirements for a new system. Consequently, you should use more than one technique to produce a requirements specification.
You can find out more about use cases in Cockburn (2001) and about UML in Fowler (2003):
Cockburn, A. (2001) Writing Effective Use Cases, Harlow, UK, Addison-Wesley.
Fowler, M. (2003) UML Distilled: A brief guide to the standard object modelling language (3rd edn), Reading, MA, Addison-Wesley.