uml use case diagram - how can I model an “autonomous” system?

Question

I have a system in which there is a controller and a robot that interact to do something. The system is self sufficient, in the sense that once online and functioning, the entity that we called controller takes decisions on its own on what the robot should do, so every "use case" in the diagram is "made" by the controller. Since the actor in a use case diagram is, by definition, an external entity that interact with the system, what is the right way to model my system with this diagram? The controller cannot be an actor since it's part of the system, but then how can I model the functionalities?

Answer 1

If the system is really autonomous you can ask it: what is the added value you get? I bet it can't answer. So it's not autonomous on itself (like you hopefully are). It acts on behalf of its constructor or purchaser. And they will have an added value. So that's the one perspective.

Now you implement a system. This is intended to fulfill the added value. It does not matter whether this is done autonomously or not.

What you can do, is to detail the system and construct technical use cases. So to control visual perception you have sub-systems with own use cases. Or to sense something. But that is a different level and not to be mixed up with the business logic behind it all.

Answer 2

根据UML规范，传感器可以视为角色。

Answer 3

Your system presumably is not a complete black box. It reacts on some external events (usually - timer first of all) triggered by some sources. Straightforward way is to introduce sources of those events (timer, accelerometer, valves, etc) as actors who are triggering scenarios.

In your case the only involvement of such actors could be potentially denoted to only triggering the scenarios. If so take a shortcut and do not introduce the actors, just write in the use case trigger: "pressure drops below ..."

You may or may not want to separate the system actor to the robot and the controller actors (ie establish System under Discussion one level lower). Who will be reader of your documentation? Customers are not interested in what's inside the black box, but two development team writing each of the pieces will push you to separate and define precise interfaces.