3

Can there be different use case diagrams for the same system with differing levels of complexity?

My question arises due to the fact that use case diagrams can represent a single system in a complex way (more use cases and different relations with detailed representation of each feature) or in a simple way (just an overview). But as it turns out if a stakeholder who is from a non-IT domain would want to look at the use case diagram, we want it to be simple and make him understand what the system does on a higher level, whereas when a developer looks at the use case diagram he would want to know about the detailed diagram for developing a feature.

How would such a scenario be handled?

1
  • It's a good question. I would only state that many experts will recommend that the details for developing features be put in the text of the use case, rather than the diagram. Use case diagrams are a kind of "table of contents" of a system's requirements. Mar 17, 2019 at 1:21

3 Answers 3

4

TL;DR

Yes. You can have separate UC diagrams focusing on different parts (functionalities) of your system and one of options is to split them by involved actors.

Explanation

When you describe a system what you do is creating a model. A model is an abstraction of the actual thing (in this case of the system) intended to represent properties of the actual object. We're used to physical models, like scale model of a plane or car. There are also various reasons to build a model. You can build a model to show how something is going to look like or to test some physical properties (like aerodynamic drag).

Using an abstraction definition, a plan of a house, while might not be perceived as such, technically is also kind of house's model.

UML is intended to build models of systems (not only computer systems, however this is the main usage). To represent the system you need to model its various aspects and while the system is not a physical object the model has a form of diagrams depicting those aspects. A single diagram focus on a specific aspect of a system and to get the whole idea you need to study all of them. Thus all diagrams of the system combined constitute a model.

It's difficult if not impossible to show all aspects of even a simple system on a single diagram. Actually the number of diagram types comes from the fact that they focus on different aspects of the system, e.g. class diagram focuses on static data structures while activity diagram or state machine diagram focuses on changes of the system over time. It creates natural layer of abstractions and aspect borders.

But it is not the only limitation of modelling. To make it efficient model has to be understandable. with increasing complexity of the system it becomes impossible to depict all the information of one kind (e.g. data model or system functionalities) on just one diagram so to keep things clear those can be further split into smaller diagrams, adding new aspects. For classes it can focus on main business areas. For functionalities one of good options is separating the diagram by actors involved.

If you read into details of UML specification it clearly states, that the information on a single diagram is hardly ever complete information for the whole system. Even a full model might not cover all details.

So feel free to organise your diagram in a way that is most efficient to use for you and other stakeholders involved. And yes, of course you may produce multiple UC diagrams for a single system as long as they are consistent.

Notes

If you look at the UML specification, the class diagrams there represent the whole UML language model. Of course they are split into multiple class diagrams as otherwise they would be totally unreadable.

If you take any CASE system (like Enterprise Architect, Visual Paradigm, Rational Rose or even StarUML) you will find a difference between model and diagrams. Elements that you put on your diagram become parts of your model (usually visible in a form of a model tree) but it's not enough to remove element from a diagram to remove it from the model. Moreover if you drag two related elements from a model on a new diagram, they will automatically show with the relationship already presented.

4

Sure there can be multiple use case diagrams. If it helps to improve communication, why not?

Use case diagrams are usually a very informal way of describing a system, there is not "one right level of abstraction" for using them. If you need to have different ones, and you have enough resources to draw and maintain those diagrams on different levels of abstraction, then go ahead.

1
  • In addition to the answer. UMLs, as a form of communication, it's good if it's adapted to the interlocutor background and its domain language. the system is seen or perceived differently from different standpoints, so why not adapt the "message" to whoever has to read it?
    – Laiv
    Mar 15, 2019 at 8:24
4

Yes, you can have several diagrams for the same system under consideration, showing for example:

  • different viewpoints (e.g. business vs. system)
  • different levels of details. Although they are not part of the UML specs, there is some commonly used kind of levels.
  • different parts or components of a more complex system, since the subject does not even have to be the whole system.

Nevertheless, even if there are several diagrams, you still have a single model of your system. So if you use a diagramming tool rather than a modelling tool, you’ll need to ensure overall consistency (e.g. not two different use cases wearing the same name).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.