Simple Blog Use Cases

How do system designers illustrate the intended use of the system in question? One of the common standards is to draw UML use case diagrams. The core constituents of use case diagrams are actors and use cases. The actors are can be anything that is external to the system, but are often human users of the system. The use cases themselves are high-level goals that need to be realized by the system in order to keep the actors satisfied.

The key thing to remember with use cases is that they are purposefully a high-level concept in system modeling. They are there to explain, visually, what the system is to do. Since use cases generally shouldn't delve into much detail about what the system is supposed to do, these diagrams are often useful for showing to non-system designers.

Within UML use case diagrams, use case elements can have relationships with other use case elements. These relationships are of the extend or include variety. Illustrated below is an intentionally simplistic, incomplete blog system use case diagram.



In this example, we have to actors; Blogger and Reader. A lot can be inferred from the actor names alone. One probably doesn't even need to look at the diagram to realize that a Blogger publishes content and that a Reader reads content. Consequently, each actor has a single base use case. The chief use case for a Blogger using the system is to Publish while the chief use case of the Reader is to Read data from the system. The chosen names fit nicely with what is expected from model readers.

We do, however, show a few other use cases that are related to the above mentioned cases. The Edit use case is included by the Publish use case. The reason this relationship is an include relationship is because publishing can't happen without editing content. Here, we have explicitly taken the editing out of the Publish use case. The Publish use case is extended by the Upload use case. The reason this relationship is an extend relationship is because the system doesn't need to support uploading capabilities for all publishing functionality. However, it is shown explicitly here that it is required functionality. Finally, the Read use case is extended by the Subscribe use case because subscribing is reading from the system but isn't a requirement.

This example probably doesn't show even half of the potential use cases of interest for even a simple blog system. But I think that this is a good this. At least I think less is more when it comes to the individual use case diagrams. All use cases may be captured in the model but I would suggest breaking the use cases into several diagrams. Especially when extend and include relationships are involved. I find that when too many of these relationships are placed in a single diagram, it defeats the purpose of high-level system functionality illustration with simple notation.