Question on modeling styles and architecture connectors (sequence diagram)

[mse]

I need to decied between two possible approaches to modeling read/write communication in a sequence diagram and would like some advice.

I have a situation where I need to model components sending data to one another. However, the way the data is sent is via read/write communication. For example, there is a data that a component writes to, and the other component (the receiving component) reads that same data. I am not sure which approach to take in modeling this in a sequence diagram. If I show the data stores as lifelines, I have to draw arrows for the read/write calls. If I leave out the data lifelines, the diagram does not show what data is written. Here is the static view of things:



The components do not talk with eachother directly however, but instead via data buffers, like a central data store of sorts (this is hidden in the connectors show above).

Below are the two alternatives for sequence diagrams:

Omitting data lifelines


Showing data as lifelines

[qwerty]

You could simply show these buffers. There is a stereotype for it (can't recall the name, just look up the toolbox). Of course you can show different views. One abstract without the buffers (for overview purpose) and a detailed one with the buffers inbetween.

q.

[Takeshi K]

Did you mean: Central Buffer Node

[Richard Freggi]

Data is not a class therefore it has no objects that can be participants in a sequence diagram.  The arrows between participants are messages calling the recipient's methods.  A good summary here: https://www.uml-diagrams.org/sequence-diagrams.html   . Good luck!

[mse]

The participants do not talk to each other via calling methods. In that sense they are decoupled. The sender writes their data to another component (like a central repository of sorts that has all the data for all components). The receiver requests that data via some Read function.

My composite structure diagram does not show that central repository but instead hides that in the connectors between sender and receiver. So I have a dilemma. If I show the central repository on a diagram, then the amount of connectors increases (one for read, one for write). If I hide the central repository, then the sequence diagram shows the central data buffer and the reader is left wondering where it came from.

This does not happen when components invoke one anothers methods of course. However, that is not the architecture style our system follows.

[mse]

Yet another alternative would be to show the repository on the sequence diagram, just like it is shown in a Mediator design pattern.



This strategy saves on lifelines.

[qwerty]

Just repeating what others have said: Components do not talk to each other, but objects. A component consists of a number (1 or more) classes which can be instantiated. And these instances will send messages (call operations of classes). So the ComponentA (in ths SD) must be an instance of a class ComponentA (not shown anywhere yet) within the ComponentA (show in the component diagram), not the ComponentA (from the CD) itself. As you see naming things is important.

BTW: if you use the component as lifeline your model will corrupt after XMI ex-/import. EA still does not hinder you to use non-objects in SDs. It just crashes later :-(

q.

[Modesto Vega]

Just some random thoughts on various aspects mentioned in this thread.

Components can have ports and interfaces. It is possible to connect 2 components via an assembly, connecting 2 interfaces, or by using other relationships such as InformationFlows. Components may not talk to each other but it is certainly possible to represent the flow of data between components.

If those data buffers are similar to queues - i.e., if a component (or an object within the component) places data into a queue/buffer and another component (or object within another component) retrieves it and processes it, I would argue that the queues/buffers are also components.

I would also argue that structure of the data held on a queue/buffer can be modelled using one or more classes.

Unless you are developing software or you can reverse engineer code, we do not always have the luxury how a system is constructed in terms of components, objects and classes. But we still need to model/represent/document how data moves between them.

[mse]

These are all excellent points. And thanks to qwerty, I corrected the sequence diagram to show the objects of type classes. I totally agree with qwertys' observation:

naming things is important

I guess I am only left to decided between hiding those queues/buffers behind a single lifeline, and send read/write messages to it, or to show the individual queues/buffers and again send read/write messages to each one. The second approach will make for some long sequence diagrams depending on how many buffers are involved in a scenario (I only include what is necessary). The first approach will hide it all behind a huge DataStorage lifeline.

In reality, the type of sytem we are implementing is built that way, a large data storage module that manages all buffers. other modules then use the appropriate read/write functions to get the data.

[qwerty]

Quite often you can simplify things in diagrams. Adding a note is often easier to create and read (!) than any exact model. You know your Einstein...

q.