1

I was wondering how it would be possible to relate, within a SySML block diagram, the data flowing through two components with the interfaces that they expose.

As an example, assume that you have a supervisor component setting a reference for a lower level controller. The controller exposes an interface Operations which features the operation set_reference() and this latter specifies a float parameter reference. The supervisor will use the interface to effectively set the reference for the lower level controller. This operation tells that there exists a data flow between the two components (e.g. each component also has a flow port) and the exchanged data is the reference. How would you model this scenario in SySML? Does it exist a way to specify both the interface and the dataflow and say "look, this dataflow is realised through this interface".

Thanks a lot for your help

jeb
  • 78,592
  • 17
  • 171
  • 225
giudaballerino
  • 55
  • 6

1 Answers1

3

A block definition diagram is usually not used to show the flows between components of your system. Instead you would use an internal block diagram of your system with the two parts s:Supervisor and c:Controller.

To specify that the controller provides the operation set_reference(r:float) you would use an InterfaceBlock as Type of a port of the controller. The same InterfaceBlock would be used as Type of a port of the supervisor. This time, however, conjugated. That will be shown by prepending a ~ symbol. Then you need to connect them via their ports. This already suffices to specify that a float value can flow across the connector. Nothing else is needed.

However, sometimes you didn't decide yet, how to realize the flow (there is more than one possibility. The set_reference operation, as you have done it, a get_reference operation provided by supervisor or a flow property). So, you only want to specify the need for some item flowing, but not the mechanism. In this case you could leave the ports without a type and model an ItemFlow across the connector. It would be shown with a filled triangle placed somewhere near the center of the connector and labeled with the name and type of the flowing item. A tool could even support you, by later creating the InterfaceBlocks and operations automatically.

As I said, if you already know, how you are going to realize the flow, modeling the ItemFlow is redundant. Except of course, if you want to limit the possible values in your specific system. Lets say, double is a specific float, and in your system only doubles will be used, even though the controller could also handle singles. This can be expressed with an ItemFlow of Type double.

Some people prefer to only model ItemFlows and leave out the connectors. ItemFlows alone are shown as dashed arrows with the keyword «flow». I advise against this, because ItemFlows don't imply that the parts are connected (the flow could be realized by intermediary elements).

Axel Scheithauer
  • 2,758
  • 5
  • 13
  • Thanks Axel for your answer, it has been very clear. I would have another doubt, this time it is about the specific implementation of relationships between bdd and ibd of Visual Paradigm. – giudaballerino Dec 18 '20 at 00:57
  • Assuming that I am modelling a cruise control system, first I create a Block Definition Diagram where I define the block Car and a Composition Relationship with blocks Sensor, Actuator and Controller. At the moment of the creation of the relationship, Visual Paradigm automatically adds the parts ^sps:Sensor, ^act:Actuator and ^ctrl:Controller, where sps, act and ctrl are the name of the relationships. This is theoretically fine although I couldn't find the meaning of the prefix ^ anywhere (btw, do you know it by any chance?). – giudaballerino Dec 18 '20 at 00:57
  • However, when I try to create a Internal Block Diagram for the Car to model interactions among its components, I cannot use the same parts that I already defined in the BDD but it only allows me to create other parts (of the same type). As an example, it doesn't let me use the part ^sps:Sensor (that I defined in the BDD in aggregation with the car) but instead it asks me to create a further part speedsensor:Sensor, which I find redundant. – giudaballerino Dec 18 '20 at 00:58
  • Am I missing something in SySML (like ^sps is the relationship while speedsensor is the instance) or it's something particular to just the Visual Paradigm implementation of it? Many thanks! – giudaballerino Dec 18 '20 at 00:58