Element in view always below relationships?

[LapizLazuli]

Hi,

I ran into a weird behavior, and did not find any post about it in this forum. Am I doing something wrong?

Apparenly, I can't manage an element to appear "above" a relationship.

Please check the attached image and model: the DataObject element has been brought to front "View/Order/Bring to front". Nevertheless, it doesn't hide the relationship, as would be expected.

Any help welcome.

Thanks and regards.

[Jean-Baptiste Sarrodie]

Hi,

Yes, relationships are always above elements. This is both per design (an element being above a relationship would at least partially hide it and let people think it is the source/target of the relationship while it isn't), and also a technical constaint (relationships are drawn on their own "layer" in the eclipse framework, so they must be ALL above or below, which wouldn't make sense).

Regards,

JB

[Xiaoqi]

With explanation by JB on the feature-by-design as well as technical constrain, in my practice, I normally don't simply place one element in the middle, as that's not mentioning any relationship hence you don't have way to joint analyze this diagram.

Instead, I prefer to use "association" relation at least to connect your sample's Data Object to the App-to-App link. As attached model with the image exported. For your reference.

Regards, Xiaoqi

[LapizLazuli]

Hi,

Thanks for your answers. There are still rationales behind the view I'm showing. I will try to detail in a separate post, if I can find time.

@Jean-Baptiste Sarrodie : in the meantime, I take note of the technical constraint, thanks.

@Xiaoqi : thanks too. I use a similar notation, eg. to qualify the underlying technology of an interfaces, such as ESB, file transfer, message oriented middleware (mom), etc.
However, with the notation you propose, how would you:

• Manage the 4 possible flow directions:
  
  • APP1 >> DATA >> APP2
  • APP1 << DATA << APP2
  • APP1 << DATA >> APP2 (both ways)
  • Unspecified
  Association relations can be directed, but are still missing either the "two ways" direction or the "unspecified" one, depending on the meaning given to the "undirected" one.
• Manage the display, when there are several interfaces (some IT landscapes have dozens) flowing from the same pair of applications? The view can become very clumsy then.

[LapizLazuli]

@Xiaoqi, regarding this point:

2. Manage the display, when there are several interfaces (some IT landscapes have dozens) flowing from the same pair of applications? The view can become very clumsy then.[/li][/list]

A picture may be worth thousand words, so here are two illustrations.

1. The layout with the APP <--> APP model you propose:

How would you then get a clear display, if linking each data to the related composition relationship?

2. The workaround I've got to use, in order to get more control over the relationships position on the layout. Below, the apps are in amber, the data in blue.


Both are from anonymized real life examples.

[rchevallier]

• APP1 >> DATA >> APP2
• APP1 << DATA << APP2
• APP1 << DATA >> APP2 (both ways)
• Unspecified

You can use between apps the flow to relationship between the components, with data linked to the flow, or simply the access relationship between component and data.

Both are valid and depends on what you want to express: a flow between application, or that application consume/produce the same data.

[Jean-Baptiste Sarrodie]

Hi,

1. The layout with the APP <--> APP model you propose:

How would you then get a clear display, if linking each data to the related composition relationship?

Two remarks here:
- Most of the time you don't have so many flows as you don't create one per data, but usually one per set of similar data
- If you really need so many flows, then use bendpoints to make them all horizontal and equally distributed.

Last, in general, I would simply set a good name on flows that whould help people understand which information is "flowing" (and not make any business or data object visible).

Regards,

JB

[LapizLazuli]

Hi,

@rchevallier: thanks for the reply. Using two relationships instead of one, depending on the direction, as shown on the upper part of your diagram, is what I was trying to avoid. However, I must acknowledge that your representation is clear, and worthwhile using.
The lower part of the diagram is the one I'm using.

@Jean-Baptiste Sarrodie: thank you for these hints.

- Most of the time you don't have so many flows as you don't create one per data, but usually one per set of similar data [...]
Last, in general, I would simply set a good name on flows that whould help people understand which information is "flowing" (and not make any business or data object visible).

This probably depends on the reason for using Archi. In the early parts of a study, high level views are fine, we indeed don't need to detail the interfaces. However, if the goal is also to use Archi for impact analysis at the start of large transformation programs, data-centric questions such as:

• Which data is used by which application?
• By which business processes?
• Which ones are flowing from where to where?
• Which application is SSoR for which data?
• How does that impact the various programme substreams?

are probably better answered, if technically possible, by providing more detail to the high level view.

- If you really need so many flows, then use bendpoints to make them all horizontal and equally distributed.

Very useful hint, thank you. I thought bendpoints were just to change the shape of a relationship, so I didn't even think of using them in this purpose. But giving it a try, I see that just moving the bendpoints up or down, provides the same kind of layout as the second illustration in my post above, without necessarily introducing the data element at first. There is another benefit: displaying the name of the relationships, as you suggest, now become possible, without clumsying the diagram, since the relationships can be made distant from each other.
Yet there is an impact there: in order to produce this diagram, I wrote a script to manage the proper and regular alignment of the DataObject elements. That would be too time-consuming to do it manually. This then automatically moves in turn the relationships links. Before using this hint that you are proposing, I will have to write a similar script to align the relationships, by moving the bendpoints. That should be manageable though.

[Jean-Baptiste Sarrodie]

Hi,

Before using this hint that you are proposing, I will have to write a similar script to align the relationships, by moving the bendpoints. That should be manageable though.

Fotunately, @William Malabry shared a script for that some time ago: https://forum.archimatetool.com/index.php?topic=1174.msg6254#msg6254

Regards,

JB

[LapizLazuli]

Fortunately, @William Malabry shared a script for that some time ago: https://forum.archimatetool.com/index.php?topic=1174.msg6254#msg6254

AWESOME !!

Thanks for sharing the link!

[LapizLazuli]

Hi,

Coming back to this suggestion:

- If you really need so many flows, then use bendpoints to make them all horizontal and equally distributed.

Using the breakpoint works fine to move a relationship. However, when trying to move it a second time, it comes back to its original position. From there, it is again possible to move it somewhere else.

Same behavior after using the script which distributes evenly the relationships.

See the attached video: moving twice a relationship, then running the script, then moving again the relationships.

Question: is it something I'm doing wrong? Or is it a limitation?

In any case, this is slightly annoying, but still easy to work around.

Thanks and regards.