2

I have seen examples of people representing CRUD use cases in use case diagrams as "Manage X", but I wanted to know whether I can use a generalisation like the one in the screenshot to group many of them.

My intention is that "manage item" applies to the current catalogue being browsed. Would this be fine?

Use case diagram:

enter image description here

Christophe
  • 68,716
  • 7
  • 72
  • 138
AnotherSherlock
  • 35
  • 5
  • Well, it's opion based. However, it more looks like you are on the best way to functional decomposition rather than use case synthesis. – qwerty_so Oct 08 '22 at 09:08

1 Answers1

1

Yes, you can use a generalization to convey the intent that the actor manages items, and that items can be of different kind.

But your diagram looks very detailed and appears to be more a user interface model rather than a real goal-oriented use-case. I.e it describes more the “how” than the “what”. This is not forbidden according to the UML specifications, but not advised, as it leads to complex diagrams, distracts the modeler from the user goals, and leads to a premature design of a user-interface, whereas other modeling techniques are better suited to ensure an optimal user experience.

See also this question, that addresses similar concerns but at a lower level of abstraction.

P.S - Unrelated thoughts: The diagram might create ambiguity, since it suggests on one side that browsing is specialized by types of items (browse X and browse Y), but at the same time it suggests that any browsing can be extended with managing any kind of items (manage X, manage Y). This could be one more symptom that the use case was created with some class design in mind and not centered on user goals

Christophe
  • 68,716
  • 7
  • 72
  • 138
  • 1
    Thank you very much for your answer! Yes, you are right, it does look like a user interface model. I will take that into account in my actual diagram, as well as the extension ambiguity. Thanks for the link, too. – AnotherSherlock Oct 08 '22 at 13:55
  • I think there are situations in which OP's approach *is* advised. Usually, each use case is defined as a series of steps, with one basic flow and multiple alternative flows. Suppose Manage X and Manage Y have 80% of the steps in common, but 20% is different. Then OP's approach has the advantage that the 80% can be specified in Manage Item and the 20% in the specialized use cases. If you would not have Manage Item, you would get duplication and possible inconsistencies in the other use cases. If you would not have Manage X and Manage Y, you would pollute Manage Item with X- and Y-specific info. – www.admiraalit.nl Oct 11 '22 at 11:17
  • @www.admiraalit.nl I think I fully agree with this point of view. Maybe there’s a misunderstanding here. I do not claim that generalization is not advisable; on contrary. My point is more about the rest of the diagram and the ambiguity created by the double generalization – Christophe Oct 11 '22 at 18:56
  • I see. Very well. – www.admiraalit.nl Oct 12 '22 at 06:23