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.
Best Answer
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:
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:
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:
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).