1

I have a web page with a graph made up of many nodes inside. The user can obviously view the graph (use case: preview the graph). It can also filter the nodes of the graph based on the argument and the difficulty and in that case the graph updates itself highlighting the nodes of interest (use case: filter nodes).

My problem is: does it make sense to insert an «include» like the one in the figure? I think so, since when the graph is updated the user displays the preview of the graph that has been updated again.

enter image description here

EDIT: This is the graph; on the right there is the FILTER panel to be able to filter by difficulty and topic. enter image description here

MaxyCar
  • 79
  • 7
  • As Christophe pointed out in his answer you're caught with functional decomposition. Search for answers here about include/extend (there are quite some) additionally. As always I recommend to read Bittner/Spence about use cases (and their synthesis!). – qwerty_so Oct 06 '21 at 22:10

1 Answers1

1

UML semantics

«include» means that a use-case is ALWAYS included in another.

We therefore understand from your diagram that Preview graph is an independent set of behaviors but that it can also be included in Filter node. In consequence filtering always implies previewing.

It's formally correct and the meaning seems to match your narrative. Moreover it highlights the reuse of set of behaviors.

Use-case logic

However, use-cases are in principle user goals, not features or functions that are decomposed in more an more details. And your narrative seems to describe features and user-interface much more than goals.

Moreover, an «include» does not represent a sequence. If Filter node includes Preview graph this does not mean that filtering leads to previewing, nor event that filtering happens before previewing.

Take a User perspective

While we could argue that previewing or filtering could be user goals, it is clear that previewing is not a subgoal of filtering.

So what is the real goal for the user here? Could it be to Navigate in the graph? How it is done, is user-interface detail: do we just browse through a picture? do we offer filtering to facilitate the navigation? do we use coloring to highlight some parts ? do we zoom-in to see more? All these are (interesting) features but not independent use-cases.

Edit after your edit

Your screenshot reinfocres what I said before: filtering is just a mean to navigate more easily in the preview. I'd recommend not to consider it as a use-case.

If despite my advice you want to show the filtering on your diagram, then you should use <> to show that the filtering behavior may enrich the navigation behavior:

                                               <<extend>>
actor --------- Previsualize/Navigate graph <-------------- Filter interests
Christophe
  • 68,716
  • 7
  • 72
  • 138
  • That's right, the user's goal is to navigate the graph and then select a node from the graph by clicking on it. The filter is represented by a checkbox, so the user by checking the various boxes can highlight (by coloring them) only the nodes of interest. The second use case I considered it a <> of the filtering because if the user checks some boxes the graph is updated by coloring the nodes of interest but perhaps it is a bit of a stretch and also something quite obvious. Maybe it would be more normal to leave "filter the nodes" and "view the graph" as separate simple use cases? – MaxyCar Oct 07 '21 at 07:05
  • 1
    @MaxyCar If we take the classical example of the ATM, there is in principle a use case "Cash withdrawal", but not a use case "Insert card" (because it's not a goal, but just a mean/constraint to achieve the goal) nor a use case "choose bank notes", (because it's not a goal, it's just a detail about how the goal is achieved). In your case, the question is whether filtering is a separate goal for the user, a constraint, or an implementation detail. Would a user use your app just for the sake of filtering? Or is filtering just a feature that could help the user for the main goal? – Christophe Oct 07 '21 at 22:40
  • it is, if necessary, something the user could do to help themselves in the decision process about the type of node to choose and click. I also edit my question with the graph preview. – MaxyCar Oct 08 '21 at 06:27
  • 1
    @MaxyCar Great! Looking at your edit, I definitively confirm my recommendation: from a use case point of view, there is only one use case. The filtering is not a separate goal but a feature that helps the navigation. Normally, you'd document this in the use-case description. I'd by the way recommend the "essential use-case" style that lists intent of the actors rather than a sequential flow. – Christophe Oct 08 '21 at 16:22
  • 1
    @MaxyCar Now if despite my advice you really want to show the filter on the diagram (your diagram, your decision), then you should have only an association of the actor with the preview/navigation use case, and have the filtering with an <> dependency to the main use case. Extend means that it may enrich the behavior but not necessarily. – Christophe Oct 08 '21 at 16:25
  • 1
    Thanks, you are the best! – MaxyCar Oct 08 '21 at 17:50