Are use cases and UML use case diagrams relevant for a Robot?

Question

For a Robot: Are use cases and UML use case diagrams relevant for describing a robot and its obstacle detection capability?

Example:

Two characteristics are of interest:

(1) A physical mobile robot

(2) The robot has an obstacle detection software subsystem to avoid obstacles

Questions:

Is a detected object an actor?

Or maybe the only actor is a human who pressed the Power On button, maybe many hours or days ago?

Following on from the above, is it of any use / relevancy to draw a simple UML use case diagram for the simple relationship between the obstacle detection subsystem (the use case ‘oval shape’ inside the system boundary) and a detected object outside the system boundary?

Thanks

Avi

Answer 1

UML and uses cases are relevant for any system, from the software intensive systems to human organisational systems ("business use cases", "business activity diagrams", etc). It is therefore also relevant for an autonomous system like a robot.

From the point of view of UML definitions, you could in theory interpret an obstacle to be an actor as it interacts with the system, simply by being there:

Each UseCase specifies some behavior that a subject can perform in collaboration with one or more Actors. UseCases define the offered Behaviors of the subject without reference to its internal structure. These Behaviors, involving interactions between the Actors and the subject, may result in changes to the state of the subject and communications with its environment.
- UML 2.5.1 specifications

So if it helps you to better describe the problem and your design, you can use this approach.

However, this is not a recommended approach, when using goal-oriented use-cases, since the obstacle is neither human, nor an autonomous system, and does in consequence not use the SuC to fulfill its goals nor does it contribute to the goals of the main actors. In other words, there is no active/intended interaction between the obstacle and the robot, in the sense that the obstacle does not initiate a use case nor interact on its own with the robot. The fact that an obstacle may be detected through physical interaction (sending back light, force, or ultrasound) is passive.

In your example of warning system for a car, the main actor would be the driver with a goal to drive safe to the destination, which may include the goal of avoiding obstacles. Pedestrian would benefit from this technology as stakeholder but not as actor.

The analysis would of course be different if the "obstacle" would be meant to be a real actor (e.g. a human playing with the bot) or if using a "mis-use case" i.e. a second modelling technique based on use-cases where actors are people trying to trick the system (e.g. a thief vs an police bot).

Answer 2

An actor is someone or something that interacts with a system under consideration (SUC). Now, it all depends on the perspective. Whom is the SUC targeted for? If it's some task to be automated and the robot is the one to do it for a human then the robot('s software) is the SUC. The obstacles can be (secondary) actors and the humans as well (if they are only there to turn the system on). In order to answer your question you first need to clarify the purpose of the SUC. Once that is clear you can find the actors. And finally you are able to find the added value the SUC brings to its (primary) actors. If the intention is to build a robot that circles just around obstacles, the primary actor is probably a human watching it and having fun. A bit obscure, but that would be the main use case. If the obstacle avoiding is only to find a way to help endangered persons by a robot (to be on the other end of the scale) then the use case would be to find people and the obstacle avoidance only a strong constraint. Edit If it's a SAR scenario then the searched person is an actor and it's UC would be "Get help" or so.

Generally I suggest to read Bittner/Spence about use cases. Definitely the best way to learn what UC are actually about.