(Editor’s Note: Welcome to our new series — Useful UML Modeling. The goal of this multi-part series is to get back to basics and help make modeling more practical and useful for you. The Unified Modeling Language (UML) has been around formally for more than a decade. The UML superstructure specification is more than 700 pages long and quite complex. Many texts have been written to try to explain what it all means. And yet many modelers still struggle with the UML, often falling into the same pitfalls as their colleagues. Often this is due to misunderstanding, misuse, or over-simplification of the basic elements of the UML. These articles will approach this topic from a pragmatic, practical (instead of theoretical) point of view.For you who never had the opportunity to learn about UML modeling, we will help you build a solid foundation. For those who have done some modeling, but have been too busy to build a deeper understanding, these brief articles should fit well in your busy schedule. And you modeling experts, the basics are the foundation your expertise is built upon. These articles can refresh those foundational concepts for you. And everyone can learn from other’s real world experiences so you don’t make an embarrassing error on a critical project. )
The Goldilocks Conundrum
Use cases are by far the most commonly used element of the UML. This is also the area where modelers have the most difficulties. Use cases appear to be so simple and easy to use. Remember, as Jim Horning said: “Nothing is as simple as we hope it will be.”
The Basics
A use case represents a series of interactions between your system and an actor, which yields a valuable result to the actor. An actor is a role that a person, system, or other entity plays when interacting with the system. Figure 1 shows these elements in a use case diagram.
Figure 1: Use case diagram.The Problem
Just as Goldilocks could not find suitable sleeping arrangements, modelers often have problems with the abstraction level of a use case. In other words, is it too big? Too small? Once upon a time, at a job interview, the interviewer told me one of his people had created a use case model where every use case was equivalent to an operation on a class. Too small! She was thinking bottom-up, from an implementation point-of-view. Recall that a use case is a series of interactions, not one step. Use cases (a.k.a. system use cases) capture the functionality that the system will provide to the actor. This functionality is specified in the multiple flows of the use case, each of which has multiple steps. On the other hand, when people approach modeling top-down from a business point of view, they may create a use case such as sales (in the retail domain). Too big! Yes, your business may process sales, but that is what your business does, not what your system does. These larger use cases are often referred to as business use cases. System use cases are developed to specify what the system does to support the business use cases.An example of a simple business use case model is shown in Figure 2. You can see these business use cases are quite large. Their scope is that of whole business functions. These use cases are why external people (i.e. business actors) come to your business (i.e. for what your business does, not what your systems do). A Retail Customer wants Customer Service. The Credit Company does Billing. These business use cases typically take a very long time to complete (e.g. Shipping products, especially during the holiday season).
Figure 2: Business use case diagram.Bottom Line
By comparison, a system use case diagram, shown in Figure 3, depicts its support of part of this business (i.e. processing a sale). Here you see system use cases are smaller in scope than the business use cases. They are shorter in duration (e.g. Assemble Order). In addition, the diagram includes workers inside your business that perform the use cases. Also, a number of the system use cases are typically needed to fulfill a single business use case. Finally, what is not in the system use case diagram? Not everything that the business does will be automated by the system use cases. For example, the actual physical shipping is part of the business function, but is not a system use case (not all operational business activities are automated).
Figure 3: System use case diagram.In summary, there are key characteristics that distinguish business use cases from system use cases.
Keeping these characteristics in mind will help you define use cases that are “just right.”
