Ever since the early work of Ivar Jacobson [1], use cases have been used in myriad software projects way beyond what their original creator could have ever imagined. There are a number of reasons for the popularity of use cases and use case based approaches to software modeling. This article outlines briefly what use cases are, how they have been used in practice and highlights the advantages as well as the limitations in their application. This is by no means a conclusive report on use cases but. It is intended to share practical experiences and, hopefully, stimulate  further discussion.

The simplest way to understand use cases is that are a way to model how a user interacts with a system. The users are represented by an ‘actor’ (represented by the stick figure) and the interaction is documented in a ‘use case’. (represented by an ellipse). These actors and use cases are put together for a subject area of the business on a use case diagram as shown in Figure 1. The user, of course, may use the system in many different ways, and there are potentially many users involved in any interaction. Therefore, use case diagrams often contain multiple actors and use cases.

The above figure shows a simple use case diagram with explanations for the relationships between use cases and also between actors. These use case diagrams provide an excellent bird’s eye view of the system or the sub-system along with the users and interfaces of the system and, as such, have been called a ‘visual table of contents’ of the system by Fowler [2].

USE CASES IN PRACTICE

Use cases have been used in practice to model almost anything within the system and even the business. For example, use cases are used to record the suite of actions between the actor and the system in an abstract manner to merely highlight the actions but with limited detail. Alternatively, use cases have been used at the system level to document detailed interactions - even at database level – which is not the best way of applying the technique. Use cases have been documented using activity graphs to conduct business analysis and document functional requirements of the system. Use cases can also be modeled with sequence diagrams to depict business scenarios (or instances). Use cases on a use case diagram are able to provide scope of the system.

 

KEY ADVANTAGES

The immense popularity of use cases can be attributed to their many advantages. Following are some of these practical advantages:

• Use cases provide the fundamental unit of the functionality required of the system. Therefore, through use cases, the functional requirements can be easily organized.

• Use case diagrams containing the use cases and actors provide a means for identification, scoping and even measuring the overall business requirements at a functional level.

• Use case diagraming can be an excellent mechanism for project managers to rank and prioritise use cases thereby helping with the creation of the project plan

• Actors are the representation of the users as well as the stakeholders of the system. Therefore, actors provide maximum ‘buy in’ from stakeholders who may be invited to the use case workshops

• Use cases are an excellent starting point for business requirements because they start off by ‘quizzing’ the actors as to how they will use the system. Through use cases one is able to document the requirements that will be of immediate value to the ‘real’ users of the system.

• Actors can have inheritance relationships and provide clarity on the use case diagrams as the sub_actor (see Figure 1) need not be related with the use cases with which the actor itself is related. Through inheritance on the use case diagram the number of communication or association lines between the actors and the use cases is reduced.
  

Use cases provide opportunities for reuse of requirements as they enable inclusion and extension of other uses cases (see Figure 1). This feature of use cases on the use case diagrams can be used in practice by identifying and modeling reusable requirements separately and then including them in the main use cases.

For example, the common task of a user logging into an application the use case ‘User_logs_in’ can be reused by many other use cases.


LIMITATIONS & CHALLENGES

While use case advocates see the above advantages as sufficient reason to apply the technique in their practical projects, there are  some practical limitations that need to be considered:

• Use case diagrams do not have a ‘flow’. The use cases are related to each other through the <<include>> and <<extend>> relationship. These relationships themselves are not semantically strong and they can lead to more confusion and discussion than adding value to the model. In practical work, it is recommended that the relationships between use cases be minimally used.

• Use cases were meant to be object oriented. However, the way they have been used in practical business analysis work is not object oriented at all. This needs to be kept in mind in their use in practice.

• Use cases do not provide the entire suite of requirements as the focus is on interaction. However, creating another set of requirements document creates confusion and challenges in terms of maintaining the requirements. Hence aspects of requirements such as business rules, mathematical formulae, printing and even user interfaces do not fit in properly with use cases. It is suggested that for each project the use case standard be discussed and modified to suit the requirements of the project.

• Use cases are not a great way of modeling embedded systems as there can be significant system behaviour that does not have an actor available for such systems.

• Actors, as mentioned earlier, represent users of the system. However, as shown in Figure 2, actors also have their shadow inside the system. A Patient actor, for example, also has corresponding Patient class within the system that will store the details of the patient. When it comes to modeling use cases, this creates confusion [3] especially in a case tool. The suggested approach to overcome this confusion is to name the actor Patient differently to the class Patient as shown in Figure 2.

CONCLUSION

This article discusses, from a practical angle, what is understood as use cases and use case diagrams. Furthermore, the practical advantages and challenges related to use cases are also highlighted. It is left to the reader to determine if the benefits outweigh the challenges in their particular situation.
 

REFERENCES

[1]  Objectory, Jacobson’s first book on OO Software Engineering, 1991

[2]  UML Distilled, 3rd edition, Martin Fowler, Addison-Wesley

[3]  This confusion has been discussed in detail by Unhelkar, B., in Practical Object Oriented Analysis, Thomson Publishing (now Cengage), 2005