I'm not sure if my diagram is correct, is it ok to have this number of include relationship?

Note: My system scenario: user go to web page and enter any Twitter user account, then my system will collect the desired user's tweets, clean and pre-process them, classify them, calculate classification result, finally show the result to the user.

Use Case Diagram


Is it about the use case diagram ?

Use case shall give the big picture of the system under consideration, by showing what it is used for and how it brings value to the actors in its environment.

The "value" concept is essential for the identification of the use cases: the intent here is not to describe in detail how the system shall behave, nor its internal interactions. It's about the purpose. Each use case in the diagram shall be:

the description of a set of sequences of actions and variants that a system performs that yield an observable result of value to an actor.
- Ivar Jacobson

Let's apply this to your example: collect tweets, clean tweets, pre-process tweets, classify tweets and calculate results all seem to be steps that, have no observable result and no value to the user if taken separately. Similarly, display results is not an independent use case either: it has only value in the context of the request.

But when reading what your system does, I understand that the user wants to enter a twitter account and obtain a classification. This is the only thing that is really of value for your user:

enter image description here

If it's the only use case, this diagram would be a little overkill. Spontaneously, I'd suspect that a second use case could be: train the classification engine (as you have some ML component).

Or is it about the details of your processing chain ?

If you want to represent the internals of the use case, i.e. the sequence of actions that are performed, you may consider using an activity diagram:

enter image description here

There are some advantages: the processing flow is highlighted through the arrows. You can also show joins and forks in your processing flow. You eventually can highlight what objects are exchanged between the process steps. ANd you don't need to go into technical details of the third party components (e.g. in a use case you'd show independent systems as actors, but not libraries).

  • Your diagram is arguably less useful and clear than the OP's. – Robert Harvey Mar 21 '18 at 19:40
  • @RobertHarvey this diagram says what the user can expect from the system, and which other systems are involved. Isn't this the purpose of a use case diagram ? And wouldn't describing the OP's detailed steps be presented in even simpler ways in an activity diagram ? – Christophe Mar 21 '18 at 19:56
  • Well, yes, but I'm generally less concerned about diagram correctness than I am about effectively communicating ideas. – Robert Harvey Mar 21 '18 at 20:37
  • @RobertHarvey I agree fully agree with you. But using an activity diagram would allow both expressivity and correctness. In addition, the arrows would correspond to the processing flow and not be reverted with an artificial "include" semantic. – Christophe Mar 21 '18 at 20:42
  • 2
    +1 Use case diagrams are supposed to be a "table of contents" of the use cases (which are supposed to have value to the user), not the details of how they work. The details of the steps are in the text of the use case (not the use-case diagram) and could be supported by an activity diagram (as shown here). – Fuhrmanator Mar 23 '18 at 15:51

You should not decompose a use case like that. This is just a single simple use case "Request user's classification" with relatively many external systems as involved actors.

The decomposition to show how the use case is processed should be depicted on a separate diagram. I would suggest sequence diagram due to multiple interactions however activity diagram will also do (just might be less clear).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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