If bus behavior is neglected (i.e. “Functional Model”), the bus is graphically represented by a data store.
If bus behavior is needed (e.g. in order to simulate message loss or delays) the data store should be replaced by an activity with a respective behavior.
In general, the bus communication between data sources and data sinks is captured by two information flows as illustrated in the following figure:
Both flows are decomposed into further information flows (“message containers”) which, by their labels explicitly identify the data source and sink, as well as the fact that this flow contains bus messages: i.e. MSG_<source>_2_<sink>.
Message containers have the structure of a record, with each field of the record specifying a particular component of the message. If bus nodes share messages from a specific data source, these messages have to be defined in the respective message containers.
Note: At this stage it is not necessary to define the elements of the “message containers.” Instead, you can define them when the system behavior is captured (typically starting at hierarchy level 2).