Automatic relationships to parent object?

Started by dsample, June 28, 2021, 21:49:06 PM

Previous topic - Next topic

dsample

I'm fairly new to Archi, and having created a model with composition relationships between a component and features, have then created some serving relationships between the features and other components, but want to create views with different levels of detail without having to create seemingly redundant relationships.

Is it possible to create another view which doesn't have the features from the composition, just the parent, but shows the implied relationship between the other components and the composition, without creating those relationships explicitly?


View 1

* Application Component 1
   * Feature 1
   * Feature 2

* Application Component 2
   - served by Feature 1

* Application Component 3
   - served by Feature 2

View 2

* Application Component 1

* Application Component 2
   - served by Application Component 1

* Application Component 3
   - served by Application Component 1

Jean-Baptiste Sarrodie

Hi,

Quote from: dsample on June 28, 2021, 21:49:06 PM
Is it possible to create another view which doesn't have the features from the composition, just the parent, but shows the implied relationship between the other components and the composition, without creating those relationships explicitly?

No, you have to create those "derived" relationship yourself in your model.

Regards,

JB
If you value and use Archi please consider making a donation! https://www.archimatetool.com/donate

xiaoqi

Hello,

As JB mentioned, you have to create those relationships explicitely, there're not possible to inherit automatically from the relationship like "composition" or "aggregation" etc..

In our team's practice, we face similar case that need to show different digest / detail information view from different layer of concept, we have create the "workaround", see attached two views based on your element relations, when you map in the 01 view, try to add relationship (here is "serving") at the same time to the different level of element,  like those "blue" and "pink" lines, then in 02 view, you can hide the drill down features while still have the "serving" relations between Application Components.

If that's working for your, just need to ensure communicate with your collaboration group, everyone should follow the same way of working, then you'll be in easier position.

Hope that's help, regards,
Xiaoqi

dsample

Thanks. I can understand why every relationship should be explicitly defined, but had a hope it would be smart enough to work out the relationship to the parent objects itself ::)

Quote from: xiaoqi on June 29, 2021, 21:19:46 PM
try to add relationship (here is "serving") at the same time to the different level of element,  like those "blue" and "pink" lines

From a visual point-of-view I wouldn't want a diagram with both sets of relationships visible at the same time, but I can see it being a way to make sure the the relationships are created, and then remove them from the view.

xiaoqi

Hi again,

Got your point, and I also agree that putting some "smarter" & automatically identify the nested relation to the upper level would save time.

However, your previous sample (which we used as 01 and 02 diagram) are kind of the special case, which means that both parent and child element are same type (say Application Component), so if in the child level we create "Serving" relation to other element, we can be sure it would work in the parent level. For this case, "smart" is not a bad expectation.

It may not be valid on all of the scenario, see attached as another sample, if we say Application Component 1 is located in one Server Room, and we have Composition relation "to put Applicaiton Component 1 into the Server Room", then it would be danger that we try to "duplicate" automatically adding "serving relation" from Server Room (type: Location) to other 2 Applicaiton (type: Application Component), in this case, the ArchiMate language syntax is not allowing this kind of relation.

So, I think the safe way is still you, as human architect ;-), to decide the relationships explicitly, as after all, this is our design responsibility on the target architecture landscape.

Any comments are welcome, good luck.

Regards, Xiaoqi