My use case diagram is a mess. What can I do?

Question

I was asked to build a use case diagram for a case study of a charter boat company. I said that the system will implement a shift away from their use of manual forms into an online booking and payment system. There are also staff provisions for financial reports and performance dashboards/market trends.

But the diagram is just so large. Obviously will be the main secondary operator, but I've now just have a huge spider web of relationships with the server. And the instructions seems to describe an exhaustive inclusion of use cases like all of them, I've already omitted some of them but they are still pretty expansive.

I'm not sure what I'm doing wrong.

This is my variant. I've split one server into objects from my class diagram. For some reason i have all of accounting, transactions and financial data into one object called "Transactions" it has not inherited relationships, etc.

So this business can now handle things in person and online. So for instance, communication can now branch out in an in-person or online communication. These branches have two different actors. Do I relate both actors to the main use case or to the the sub-use case?

Answer 1

The biggest problem that I see is the wrong level of abstraction.

First, I'd remove the things that aren't use cases. A use case describes a goal that an actor has. "Log In", "Two-factor Authentication", "Staff Login", "Staff Registration" aren't use cases. People will not just log in to your system or register for your system. They will register and log in to do other things. I see some of these things on the diagram - "Pay Booking", "Book Charter", and "Generate Financial Report". Along the way, you may end up removing actors that are no longer linked to any use cases, such as "Two-Factor Authentication Service".

Then, I'd remove actors that aren't directly linked to use cases. For example, "Customer" is decomposed into "Prospective Customer", "Active Customer", and "Special Charter Company". However, these more granular Customers aren't directly linked to any use cases. They should be linked to use cases (and goals) these groups want to achieve, or they can be removed. You can talk about specific customers later on.

Once you have your highest-level use cases, it's crucial to consider the audience. Registration, logging in, and two-factor authentication are likely prerequisites for executing some other use cases, but does it make sense to have them on the diagram? Understanding the needs and expectations of stakeholders is key in this decision-making process.

At this point, I'd iterate between textual/tabular descriptions of use cases and the diagram. I tend to avoid use case diagrams. They don't offer much value over a list of use cases and tabular representations for details, yet require time and effort to create and maintain. However, if I do have one, I tend to use it as an index into my tabular use cases. As I'm documenting the preconditions and extensions, if it's valuable to extract and express a shared precondition and extension in the use case format (keeping in mind that it isn't a use case in and of itself), then I would express that extraction on the diagram as well.

I've found Alistair Cockburn's Writing Effective Use Cases to be a good treatment of how to document use cases effectively and it covers a few varieties of textual/tabular formats.

Answer 2

Two approaches might help you:

• Don't try to cram several use cases into one diagram - instead, create individual diagrams where each shows only one (main) use case. This will make it a lot clearer which cases and actors really belong to one use case, and which of them belong to a different one.

• Choose a different level of abstraction, moving certain details from the diagram into the textual description of the use case. For example, though it is not "forbidden" to show something like the 2-factor-authentification in a use case diagram, it can increase clarity by leaving this out in the graphics and only mention it in the text. In case you think a textual description isn't clear enough, consider to use other types of diagrams like activity diagrams to flesh out the details.

In the end, it seems you are describing a complex system with several different actors and use cases involved. Hence it is not astonishing your use case diagrams need to have a certain complexity.

Answer 3

As first advice, use the "roles" or actor names to keep the diagram cleaner and not mix up stuff like authentication in identifying the system mission.

In particular, you can have a visitor actor that can login/logout (some people have other actors inherit from that one, but it stays cluttered I'd prefer explaining that all logged in actors can disconnect in the text since diagrams are never dry) , and avoid all those nasty includes to login, past the login, the user is recognized in one or several roles according to the security/access policy. An actor has available actions, ofc he is in that role to access them. Anyway, an "A include B" means each time you do A you must do B as a part of A, so the diagram is incorrect if you have a session notion. So you just accompany the diagram with a table ascribing to each actor name its business name/role and how to reach that level of recognition (e.g. you need to login and have that level of permission).

For the rest, secondary actors are "secondary", so not important to a use case presentation from client POV, they can be left out of a higher level presentation, though they are ineteresting to introduce for design/lower phases of the cycle.

Just focus on "a use case has business value for its primary actor, who triggers it to gain that business value"

some use cases of your diagram might actually be two separate use cases, e.g. access updates is not the same use case for the client (just his own status) and the reception (be informed of warnings ? a huge set of status in sight so search and scroll tools, and maybe admin status to solve issues) A use case diagram is about how external people (actors, so they could also be machines) use our system. In a computer based interaction this means two primary actors don't actually touch the same use case unless there is some kind of symmetric chat involved (unlikely). For human face to face relations it's different, you do have two actors interacting, but over/under the counter w.r.t. to a computer system that would implement the exchange. In most cases, you just get a single use case, that the company employee touches in response to the user queries (on the phone, physical in front of desk). Or there is an online service for clients to pose questions which is another use case.

In any case, you need to better define the boundaries of your system imo, are your employees part of it in this modeling ?

Maybe not, so you focus in the diagram on what your business brings to the clients (the whole point of these diagrams), regardless of current internal organization (secondary actors on right, design/problem solving issues). Then we can separately study how to build an information/UI system to help our employees satisfy those needs, which are separate use cases since they handle a base of clients.