0

I would like to make a component diagram for a multiple robot coordination system.

I would like to show on the component diagram that the sub-component "Perception" of each "Robot" component communicates through an interface with each other. Indeed, the sensors of all robots are used in order to estimate the position/velocity of each robot, it is a cooperative sensing.

How can I do that ? Should I have an interface which would be both provided and required by the component "Robot" ?

Thanks.

user996987
  • 45
  • 6
  • It depends on how strict you are in making diagrams. I think that UML diagrams are really good when you use it to communicate the general design not the details. In this case I think that you can use a simple comment pointing the Perception component specifying the cooperative sensing, otherwise you will end with a diagram difficult to understand, that's my opinion. – Miguel A. Carrasco May 26 '14 at 15:50
  • Thank you for this suggestion. I think it is a good option. However, I am wondering whether there are "best practices" for the modelization of multi agent systems with component diagrams ? – user996987 May 26 '14 at 15:54
  • Well, I don't know about best practices in this kind of systems, but usually when you use an interface in the component diagram it's because you are trying to communicate that you can interchange the implementation component with another "different" component that can communicate through this interface. In this case they are essentially the same components, so I think this "interface to itself" detail it's better specified in the class diagram instead, (in case this interface is a programmatic one) – Miguel A. Carrasco May 26 '14 at 16:20
  • If I understand well, it means that actually, I just don't have to show in the component diagram the communication between robots. However, I can show this in the class diagram instead. However, in the class diagram, I cannot go into more details than using an association "1 -- *". What if I want to show precisely what the robots share with each other (for example, robots only share the laser data with other robots, but not the video data) ? – user996987 May 26 '14 at 16:34
  • Is it something standard to make a component diagram with two instances ":Robot" and ":Robot", and to show the required and implemented interfaces ? – user996987 May 26 '14 at 16:36
  • Why don't you consider to use the deployment diagram to explicitly show 2 or more nodes as the different robots and use an asociation to show the interactions between them? – Miguel A. Carrasco May 26 '14 at 20:47

1 Answers1

1

For this type of system you are in position to use full power of UML and make really effective documentation. You will most likely need some (or all) of the following diagrams:

  1. Component diagram - to show the "big picture" and the main parts of your system ant their interfaces and dependencies. Components are "black boxes" here and will be detailed in the following diagram
  2. Composite structure - are perfect to open up the components and show their internal structure. You can take "black boxes" and their interfaces as kind of input to this work. Each component (except the external ones) should be modelled internally. This kind of diagrams lets you use the whole-part paradigm to model internal structure as a network of interconnected elements. Previously detected interfaces will be used here to show how they are actually implemented.
  3. Class diagrams. If you need to further specify the elements of internal structure (their attributes, methods, associations, etc), this is the diagram to draw.
  4. State machines. In embedded real-time systems, lots of classes are active and have states. Identify those classes (or even components) and use state diagrams to show their internal logic.
  5. Sequences and interactions. These diagrams will help you to specify how different elements of your system work together to implement different scenarios.
  6. Deployment diagram. As robot is a piece of hardware and these components run on it (or them, if there are more than one hardware node) you might want to show how the components are distributed over the hardware structure.
  7. You could also have a look on timing diagram, relativelly new one, designed especially for real-time systems. It might come on handy if you need to express time restrictions, durations, etc.

If you are new to UML, I would recommend to start with components and deployment. They are relativelly easy to learn. As you feel understanding and need to express your ideas further, dive in the composite structure and states. And finally classes.

Have fun!

EXAMPLE

This is how I understand your model and its elements. This extends my comments.

Explanations are in comments and in the diagram notes.

A component diagram:

enter image description here

A component instances' diagram: enter image description here

Note that the first diagram should be extended with the "connectivity rules" that define all valid connectivity possibilities. Is there only one CentralManager? Must each Robot be connected to CentralManager? Can a Robot talk to itself? And so on...

These and other questions should be modelled separatelly. On class diagrams benavior diagams, according to concrete details.

Aleks
  • 5,674
  • 1
  • 28
  • 54
  • Thank you for your answer. However, it is a bit general and for my particular system, the question that I'm trying to formulate is: is it possible to describe the interactions between the instances of a same component in a component diagram. I have already defined the interfaces between the robot component and the "central manager" component without problem. But not between instances of "robot" component. I can build a sequence diagram to show precisely these interactions, but I would like to show the inter-robots interactions just through interfaces. Do you think it's feasible ? – user996987 May 26 '14 at 18:40
  • Component diagram shows the structure and not the dynamic aspects (behavior), so you cannot use component diagram to show any kind interaction. However, you can use sequence or interaction diagram with the instances of your components (same component or different ones) to show this communication. An instance can even talk to itself (send message to itself) if this is what you need. What do you mean by your last sentence, can you explain it please? What does it mean " inter-robots interactions just through interfaces"? – Aleks May 26 '14 at 19:12
  • Thank you for your answer, I think indeed that what I want to show should be shown through interaction diagrams. But for example, I have a system of requests between the "central manager" and the robots. And I have used the component diagram to show that the "robot" component can send a request to the "central manager" component through a "Request" interface. Then, I use an interaction diagram to show in details the system of requests. Is it possible to to do something similar between robot instances ? – user996987 May 26 '14 at 19:22
  • Of course, between any two instances, wether they originate in the same component or different ones. I suspect you don't distinguish enough between the concept of "component" (or "class") and "instance" of component (or class). If you are not sure about it, it would be great to study the topic, it's a base of everything in OO. A component diagram shows the "components" and their relationships (system design), while dynamic diagrams, like interactions, show communication between their "instances" in run-time. You can have one component on 1 comp.diag. but many "instances" on interaction diag. – Aleks May 26 '14 at 20:06
  • Actually, my "something similar" referred to something similar in the component diagram. I understand the differences between instances and classes. But let think of the class diagram: it is possible to have a binary reflexive association for a given class. Is it possible (and if not why) to have a interface which is both required and implemented ? It would model the fact that an instance of the component implements this interface, but also requires this interface to be implemented by other instances of the component. I hope I'm clear (I'm new to UML, but I'm used to OO). – user996987 May 26 '14 at 21:42
  • You'r clearand the answer is - yes, it is VERY possible that a component has an interface which is both required and implemented. :) At least from the syntactical point ov view, you just have to give it a semantical meaning (expressed in other diagrams). A single component can have a lot of instances, each having its own "identity" and probably something related with it. They talk to each other using this interface. It's kind of client-server connection between 2 objects of a kind, while each of them can be client, server or both. :) Am I close? – Aleks May 26 '14 at 22:11
  • Thank you, that is exctaly what I wanted to know. However, I never see that (interface which is both required and implemented) in component diagrams. Do you have examples ? – user996987 May 27 '14 at 07:22
  • Please see my updated answer - you can see it in both component and component instance level. – Aleks May 27 '14 at 07:23
  • Thank you, it's now very clear. I never heard about "component instance diagram", is it something starndard ? – user996987 May 27 '14 at 07:40
  • Maybe we can see the "component instance diagram" as a particular "object diagram" ? – user996987 May 27 '14 at 07:46
  • Excactly, it's just another kind of object diagram (no formal component instance diagram in UML). Both UML Component and UML Class are on UML metalevel specializations of so called Classifier. The main feature of Classifier is the ability to be instanciated. In consequence, with component instances you can do virtually all that you can do with class instances. – Aleks May 27 '14 at 09:25