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:

use case

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?


  • 1
    It's more important for your UML diagram to be useful and to effectively communicate ideas than it is to be technically precise UML. Commented Mar 29, 2018 at 17:34

1 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


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: enter image description here

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.

  • Do you think "Run" is a better name than "Start"? The goal of the actor is to run the system ("Perform a predefined set of actions" seemed a bit long ;)). Thanks for your input. Commented Mar 30, 2018 at 8:20
  • 1
    @MartheVeldhuis start/stop sounds like switch on/off. Run/stop raises awareness that there could be more behind, do I think it could be better. But what about launch/land ? Wouldn't they express more accurately the user's primary intentions ?
    – Christophe
    Commented Mar 30, 2018 at 8:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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