Use case causes other use cases

Question

I am making this independent drone control system that a user can start and stop. When the program is started, the connected drone takes off, hovers, and turns to face the other side. At first I though of a use case diagram like this:

The issue with this is that it seems as if the developer can execute "Take off" etc. even though this is only done by the system. At least, that's how I interpret it from most example use case diagrams. In this other question the included use case was something done solely by the system as well, but was deemed unsuitable for the use case diagram. Therefore,

• Do I remove the included use cases?
• Do I still describe these in the main flow of the "Start" and "Stop" use cases if I remove them?

For example, the main flow of the "Start" use case:

The developer starts the program. The drone takes off. The drone hovers in the air. The drone yaws to face the opposite direction.

• Do I keep them but add a "FlightController" actor that connects to the included use cases?

Thanks

Answer 1

Your use case seems correct

Each use case of the system under consideration (your drone system) is:

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

Every UC in your diagram comply with this definition.

The link actor/UC means that the actor is involved in the use case. Here I'd understand that the Developer is involved in starting. But you say nothing about the included cases, I wouldn't assume that the actor would be directly involved in them although I couldn't exclude it either.

Adding a FlightController would be incorrect because it's not an actor in the environment of your system, but a part of it.

The only thing I find confusing is the misleading name of Start: the naming suggests that the actor would just have the goal of starting it. But in reality, the goal is to perform a predefined set of actions.

Remark: In the other question you refer to, it's suggested that saving to the database is not a UC because it's not performed by the user. It must be said that in addition saving to the database is not something obervable to the user. THe user only sees what's in the database via other use cases. Your situation is a little different since the drone behavior is observable, and perhaps even desired by the user

Alternative

As an alternative, you could nevertheless consider:

• a use case limited to the user's goals and where the user is really involved (e.g. start flight, and stop).
• use an activity diagram to describe the details of behaviors that happen for the use case, especially if the user is not involved.

This could look like:

The main benefit, is that you could improve the flight logic and make it more complex without loosing the big picture that the use case diagram should provide.