What you are doing (and it's a typical mistake at the beginning) is decomposing how to execute a single use case as "smaller use cases". As a result you're getting a messed diagram with a ton of includes (and usually also extends).

As a rule of thumb, if the number of your dashed arrow exceed 1/3 of the number of use cases you've surely fallen for this trap. In real life that'll be closer to 1/10 to start reconsidering your diagram (that is majority of the diagrams will have zero inclusions or extensions).

I'd say the proper diagram here would have just... one use case: "take a passenger to the selected floor". Only in other diagrams would you show steps to complete the use cases.

I'd strongly recommend you read a bit more about what a user case is (and what isn't).

What you are doing (and it's a typical mistake at the beginning) is decomposing how to execute a single use case as "smaller use cases". As a result you're getting a messed diagram with a ton of includes (and usually also extends).

As a rule of thumb, if the number of your dashed arrow exceed 1/3 of the number of use cases you've surely fallen for this trap. In real life that'll be closer to 1/10 to start reconsidering your diagram (that is majority of the diagrams will have zero inclusions or extensions).

I'd say the proper diagram here would have just... one use case: "take a passenger to the selected floor". Only in other diagrams would you show steps to complete the use cases.

I'd strongly recommend you read a bit more about what a use case is (and what isn't).