Question on how to draw a element belonging to multiple parent (multi-nesting)

[Xiaoqi]

Hello,

Learning on the ArchiMetal case study, one question pop up at Figure 11 which show as first attached image.

The highlight part is the EAI Bus application components belongs to both PC and DC, when I try to draw this in our Archi tool, see attached #2, there're three relationships can be chosen (Composition, Aggregation or Realization), but no matter which relation uses, I cannot reproduce the view as shown in the case study, see #3 and #4, when drag the EAI Bus element to the view, it can only allow you either put that in the PC or DC, but not both, and although I can expand the width of the element, it will be put as back of another parent and cannot show that in front.

If there any technic I don't use to draw such kind of "multi-nesting" way? I met similar needs in some of my other models when discussing certain enterprise level components.

Thanks and regards,
Xiaoqi

[Jean-Baptiste Sarrodie]

Hi,

The trick is to put the "EAI Bus" outside of both locations and then resize it so that it it shown as expected. This won't trigger the ARM (automatic Relationship Manager) and the "EAI Bus" won't be forced to be nested in one or the other. You can add relationships to make sure the underlying model is coherent, but you'll have to manually remove them from the view because there is no nesting at play, so it can't be automatically hidden.

Re the relationships (to make is simple) you should always use composition or aggregation (in this case aggregation because you explicitely model that the "EAI Bus" is part of both location).

Regards,

JB

[Phil Beauvoir]

Another method- when you drag the "EAI Bus" ensure that the mouse pointer is between the two Location elements when you drop it. You'll see that neither of the Locations highlight the blue outline then.

[Xiaoqi]

Thanks JB and Phil on your "trick" but workable method, I didn't realize that just for view purpose, I can drag to the mid of two element but not force it belong to each one.

Also, keeping the actual belong relationship created is good as well, since that build the relation from the EAI Bus to the others, I'll be fine to have them and then remove in the view just for showing purpose

Thanks again,
Xiaoqi

[LapizLazuli]

Hi,

Finding this post now. I thought I would give my two cents to fuel the reflexion.

Here, the diagram shows an EAI bus spanning over two locations. Thinking out-of-the-box, I would come back to the real situation. In the real world, there is no software component spanning over two or several locations.
- Physically, the EAI has one component in Location 1, and another one in location 2. They communicate with each other. There may be a Master component, orchestrating the other components, but it is still in one given location.
- The EAI Bus is only conceptual, aiming at simplifying the representation.

So I would introduce EAI1, in location 1, EAI2 in location 2, and as many as required, if there are more locations. These EAIx are relevant, because they correspond to actual software components.

Then another item can be "EAI Bus". Being conceptual, with no physical reality, it can be positioned anywhere. EAI1 and EAI2 are then linked to EAI Bus through typically a "realizes" relationship.

Then, representing:

• the EAI Bus spanning over the two locations
• or EA1 in location 1, and EAI2 in location 2
• or both

is just a matter of viewpoint, depending what we want to show to whom.

This modeling is relevant since it correctly mirrors the real world, allows for the representation of the 'EAI Bus' spanning the two locations, and removes the need of multiple parents.

Regards.