Automatic relationships to parent object?

[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?

Code Select Expand


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,

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

[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

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