Eric Veenendaal

UML - The Use Case Diagram

Published: January 20, 2013

The UML standard is vast and complex, and the different real world implementations are even more numerous. Even among authors versed enough in UML to publish a book on the subject, no two authors use UML exactly the same way.

Much like programming standards, UML standards vary, but the overriding goal is to communicate intent to others reading the same document. Even the smallest project can benefit from the explicit nature of UML diagramming. To illustrate this point I want to start with the simplest of the UML diagrams, the Use Case diagram. In this example, I'll be walking through the architecture decisions of a basic blog.

A Basic Blog

Before I get to the diagrams, there are first some conventions to explain. There 5 different symbols used in the diagram below. These are as follows:

  • Actors - Identified with stick figures, actors signify an external influence on the system.
  • Actions - Identified with circles, these signify different functions being handled by the system.
  • Communication Lines - These are the lines connecting the different actions and actors together.
  • System Boundary Boxes - Identified by a standard rectangle, these signify the limits of the software we are writing.
  • Notes - Identified by a rectangle with a curled corner, these function like comments in code. They provide additional information not inherit to the diagram itself.
Use Case Diagram 1 - The Basic Blog

Without any other documentation, the diagram above says a great deal about the system being proposed. System boundaries indicate the limits of the application being built, so the proposed system will apparently be handling almost everything related to serving a blog on its own. This has its trade offs. On the plus side, the system's developers will have the ability to change nearly anything they don't like about the blogging software. On the negative side, they will have to be exceptional at everything in order for the blogging software to succeed. They won't be able to rely on the expertise and/or services of others.

A Basic Blog - Design 2

Use Case Diagram 2 - The Basic Blog

In this next design, the architect has decided to move the file handling portion of the blog to an external file storage service. With this decision, the architect has freed up the developers to not have to worry about image storing and serving, and instead focus on other areas of building their blogging software. However, in order for this decision to actually improve the overall experience of the blogging software, the challenge now becomes carefully selecting a file storage service that can be relied on.

This decision is made even more important by the fact that, as the diagram shows, the end user, when retrieving images, will actually never interact with our new system. This means that if the file storage service turns out to be unreliable, there is absolutely no development fix to be made. The options would be limited to either switching file storage services or completely redesigning the architecture of the system.

It's worth noting that this system assumes as traffic increases, the entire load would be handled by the application server(s) and the file storage service. This means the developers would have to take into account the possibility of massive changes in load and make sure they don't overload their database. Helping to minimize this possibility is the focus of the next design iteration.

A Basic Blog - Design 3

Use Case Diagram 3 - The Basic Blog

This final design adds another external actor, a CDN (Content Deliver Network). CDNs are highly efficient systems that store local static copies of content and serve them to end users (as an additional benefit, they are generally extremely cheap relative to full application servers). Adding this actor offloads much of the traffic from the application server and frees up the developers to focus on fewer targeted aspects of building their blogging software.

Much like the second diagram, it's important to realize that with every external actor added to the system there has to be an extensive evaluation done to make sure that actor won't adversely effect the system as a whole. Especially in this case, where the CDN will truly function as the first point of contact for the system. This actor should not be selected lightly as it will have a very strong influence on the system as a whole.

Final Thoughts

Intuitively it may seem obvious that the final diagram would be the best performing and most reliable with its external file service and CDN. However, the explicit explanation of why or, more importantly, the acknowledgment of the implicit trade offs being taken may not be as obvious. I hope walking through these various use case diagrams has given a decent example of why a simple use case diagram could be useful for architecting your next application.

Additional Links

For additional information on UML, I recommend Learning UML 2.0 by Russ Miles and Kim Hamilton.

As for tools for working with UML, I recommend Omnigraffle Pro. It's a bit pricy, but well worth it.