2

I have a system that is divided into partitions (avionics system). THe basic means of sending and receiving information is via read and write calls to a certain port. The reading and writing is handled by the Real-Time Operating System (RTOS).

Partition A must send some data to Partition B. One could draw a sequence diagram with two lifelines representing the two partitions, and then a message between the two. However, the semantics of UML which is more object-oriented, are more like partition A invoking an operation on partition B. This may help in sketching something and usually most people would understand it. However, are there other ways to sketch this? I thought about putting the RTOS as a lifeline, but then that leads to clutter and it takes away from the inter-partition communciation focus, because now the two partitions are decoupled, which reflects reality, but diagramatically, there is a third lifeline.

OPTION 1, objects invoking behavior on other objects

OPTION 2, objects communicating via mediator

enter image description here

enter image description here

Improve this question

2 Answers 2

Reset to default
3

Your approach will likely depend on the mode in which you use UML. For example, using UML as a sketch to communicate high-level details about how elements of the system are related will likely look different than using UML as blueprints that need to lay out design and implementation details for future developers or testers. I've also found that UML diagrams don't often stand on their own and are supported by other diagrams, text, tables, and other non-UML diagrams that offer additional details.

That said, either of the diagrams that you present could be useful, depending on the context. However, there may be other things that you could also consider.

One thing to consider is if it is necessary to include both Partition A and Partition B on the same diagram. Perhaps a more detailed diagram showing the process of Partition A that results in data being written to a data store or published on a communication channel and a second detailed diagram showing the process of Partition B that requires reading data could be useful. It seems like both Partition A and Partition B would be doing more than just writing and reading data, so diving into those details and using a textual description of how the RTOS functionality enables exchanging data between components could be helpful.

The broadness of "RTOS" is also interesting. A real-time operating system tends to offer various elements. Regardless of if you take your current approach or the approach I propose above, instead of showing an interaction with "RTOS", showing an interaction with more specifically-named services offered by the RTOS could give additional details about the system design.

If you take the UML as Sketch approach, there's also nothing preventing you from having multiple diagrams. Your second diagram, showing that data flows from Partition A to Partition B may be useful to some stakeholders, but additional diagrams showing more details about Partition A and Partition B in isolation could be useful to other stakeholders. This is essentially combining approaches.

Understanding exactly who will be using this diagram and what they will be using it for can help you determine how to structure it.

Improve this answer
1
  • This answer made me think about an example in the book Applied Software Architecture by C. Hofmeister. There was an example where they showed how a component used ports to communicate. However, they only showed the component itself and messages to and from the boundary. No other componetns were shown on the sequence diagram. Using my example, I created a sequence diagram with a port as a lifeline and the component itself (the partition). This would keep the diagram focused on the incoming event, the processing of some data, and then the actual writing of the data to a port. Commented Jan 16 at 16:58
1

The choice is yours and UML is neutral on this point:

  • your high-level design doesn't care about the implementation details. The primary focus is on Partitions (subsystems) A and B exchange information (messages). That's the second diagram. No details on how this exchange of messages is implemented. Perfectly fine.
  • for the implementation, you may need to clarify how messages are passed in practice and show all the components involved. Could be RTOS, could be a message broker, etc. You may then show this implementation detail with the first diagram. This leads however often to more complex diagrams.

I'd therefore advise to go for the simpler diagram, and add implementation details only if absolutely required.

Improve this answer

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.