How Much Value is There in the Use Case Diagram?
Very little, but let me be clear on why I say this.
The foremost purpose of the UML use case diagram (UCD) is to visually associate actors, both primary and secondary, with the use cases (i.e., services or processes) provided by a system. That’s all. Yes, a lesser purpose is to illustrate relationships between use cases, using the <<include>> and <<extend>> stereotypes, but use case-to-use case relationships are problematic, and usually cause more problems than they solve.
On my projects I develop a simple use case diagram following just this main purpose and nothing more. The use case diagram offers very limited business value with respect to a meaningful understanding of either the system’s actors or the system’s use cases. The use case diagram’s justification is that it provides structural value. It is analogous to the Table of Contents of a magazine. The TOC reveals the structure of the magazine, and the names of the articles and perhaps the name of the author, but the TOC entry is not the article. The TOC entry is a reference to the article where the real value resides. Analogously, the use case diagram shows the structure of our anticipated user/use case interaction, and the names of the use cases on the diagram are just references to the actual content with project value: the textual use case descriptions.
Once our projects identify our primary and secondary actors, and we attain a reasonable enumeration of the major use cases in our system, the value of the use case diagram rapidly diminishes to near-zero. Generally, we jettison our effort on the use case diagram around our 4th iteration. By then we have attained a good understanding of the user/use case interaction, and we are actively developing the use case descriptions (and user stories when needed) that we will be implementing.
Not only do many projects invest the use case diagram with more business value than it can provide, but I have observed too many abuses of the use case diagram where groups bend it to their own goals or agenda. Here is a list of the mistakes I have observed
The primary abuse is to turn the use case diagram into a functional decomposition diagram (FDD). In an FDD a function is broken down into its sub-functions along an implicit time-dimension. E.g., Function 6 is decomposed into Sub-function 6.1 which is followed in time by Sub-function 6.2, then by Sub-function 6.3, and so on. The use case diagram below shows an example of an FDD-use case diagram.
People who have an FDD background readily bring this thinking to their specification of use cases ― and especially into the use case diagram. They are making several mistakes when they do this.
Another abuse is to use the use case diagram to list every job title of every user of the system. This results in dozens and dozens of primary actors on the diagram. Invariably, the team quickly lose understanding of the primary actors because there are so many, and then enlist actor generalization to simplify the complexity they created in the first place. Actors should never be named according to job title. Actor names represent roles, and many job titles may participate under the cover of a single role name. Another reason to avoid job titles is that they can change often, but the role an individual fulfills usually changes much less frequently.
I have seen groups stop their use case identification and specification with the use case diagram. When I ask what use cases they have for their system they show me a use case diagram, and that is all they have. I see this occurring primarily with teams that are new to object-orientation or web development, and are also new to UML. Every UML book discusses the use case diagram in the very first chapters, so the reader mistakes early definition in the UML book with high business value.
The most avoidable waste of effort is arguments, often interminable, about the use of the <<include>> and <<extend>> relationships between use cases on the diagram. The IBM/Rational Unified Process (RUP) spends a great many words defining these stereotypes, and exhorting RUP implementers to choose them wisely and use them often. People fond of FDD will use the <<include>> stereotype to excess, as I showed in the example UCD above. The <<extend>> relationship is a huge source of confusion, and is largely unneeded. Most use cases that <<extend>> a base use case can be integrated directly into the exceptions/extensions section of the base use case, thereby simplifying the complexity inherent in the <<extend>> relationship. Again, the use case diagram has only structural value, and in this mutually destructive conflict between <<include>> and <<extend>> the over-structuring of the use case diagram becomes a huge waste and liability.
A corollary abuse that occurs in the flagrant overuse of <<include>> is the problem of premature optimization that is reflected in diagrams consisting of use cases decomposed into ever-smaller sub-processes until the “terminal” use cases on the diagram are equivalent to small subroutines. This produces a use case diagram that is just a manifestation of design-thinking, trying to inject the “how” into a diagram that should only capture the “what”.
The use case diagram has limited utility and value. If you produce one, I urge you to keep it simple, use it only for the structural value it can provide, and invest your energy into the actual written use case descriptions. They provide real business value to your project.