2

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

avi10000
  • 101
  • 5

2 Answers2

1

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.

qwerty_so
  • 35,448
  • 8
  • 62
  • 86
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).

Christophe
  • 68,716
  • 7
  • 72
  • 138
  • I was too vague. I will give more detail. The SUC is a warning system on a vehicle. The warning sys provides the human driver with automatic warning capabilities to detect objects ahead. This helps the driver avoid collisions with other objects (“obstacles”). So the “obstacle” could be a car, or a train, or a pedestrian, or a cow or a deer. So the questions turns into: Are external cars and deer considered actors? Are there any primary actors? I guess the auto-controller of the “own car” is part of the SUC (and not considered an actor). Thanks – avi10000 Aug 27 '23 at 22:57
  • @avi10000 I'd suggest to fix your question then. – qwerty_so Aug 28 '23 at 07:55
  • 1
    @avi10000 the driver is an actor, since he/she uses the system to reach safely destination. The obstacles, including human pedestrians, should not be actors since they do not interact "actively" with the car system. The fact that the lidar will physically capture their presence without their involvement is not sufficient to make them actors. – Christophe Aug 28 '23 at 08:02
  • Hi Querty, Thank you for suggesting. What is the best way to fix my question here in StackOverFlow? To edit (change) my original question? Or to create a new question in StackOverFlow? Btw, > I was too vague. I will give more detail. I had wanted to restrict as far as possible the amount of info that I give out on the nature of the project I am working on. – avi10000 Aug 28 '23 at 09:54
  • @avi10000 In this case, as it is a refinement of the question, the best way is to edit your original question, adding a section "edit" – Christophe Aug 28 '23 at 10:36
  • 1
    @avi10000 Your edit would shift the focus from a general to a specific question and the answers are already targeted for the first making them unfit for the latter. So I suggest you ask a new question. Edit is best for questions that have no answers so far. (Btw. to address someone use the @ notation.) – qwerty_so Aug 29 '23 at 08:43
  • HI @qwerty_so , > Your edit would shift the focus ... making them unfit for the latter. – avi10000 Sep 01 '23 at 12:51
  • so what is your conclusion? Seems you pressed return to early... – qwerty_so Sep 01 '23 at 21:52
  • Indeed, my computer was crashing just before end of work day. – avi10000 Sep 03 '23 at 00:54
  • Excuse me if I carry on this thread and then afterwards I will re-post with the correct question. Anyway, it’s all quite sensitive.... Due to my remarks to my bosses on use cases, they have provided a definition of 'use case’ as below. Well … that’s the way *they* are defining it anyway. A use case is: A. A scenario in which a system or actor receives input or a request and acts on it or responds to it. - or - B. A scenario describing a situation in which a software element is an active participant. – avi10000 Sep 03 '23 at 00:58
  • My notes: (i) In (A) above, I have my doubts about the part “or actor” (since the actor is outside the SUC, and use cases are about using the SUC, but not using the actor). Question (1): Comments? (ii) In (B) above: • A “SW element” is an actual top-level SW process service inside the SUC, where the “SW element” is at a high-enough level to provide a complete service, e.g., ‘Detect Deer Crossing the Road Ahead’.) • They mean that internal SUC processes are using each other to implement the SUC as a whole. Comments? – avi10000 Sep 03 '23 at 00:59
  • If it works for them, then I suppose whatever goes, but … QUESTION (2): Is this accepted Use Case science? QUESTION (2): Most important –The Detection SW is the SUC, not the rest of the vehicle, including its Main Computer. The Detection SW notifies the Vehicle Main Computer of a detection, e.g., deer, which then notifies the human driver. Is there a case for saying that the Vehicle Main Computer is also an actor? – avi10000 Sep 03 '23 at 01:00
  • @avi10000 1) This is outdated use-case science. The scenario based input output understanding is obsolete and it is decades that UML has an authoritative definition (it's an ISO standard). Of course, it may be difficult for you to explain your bosses that they are wrong. 2) It is perfectly valid to design use cases at a component level rather than at system level. In that case one component can be an actor of another, and the SUC is the component. – Christophe Sep 03 '23 at 06:00