Inconsistent visually nesting behaviour

[Modesto Vega]

While working on an ArchiMate 3.1 diagram I noticed a visually nesting behaviour I really like. If I have 3 elements A, B and C, with B and C linked to A using an aggregation, and I visually nest them, the aggregation is hidden - i.e., the aggregation is only visible if the elements are not visually nested.

I have replicated this with UML classes but it does not seem to work with other types of relationships such as a generalization.

Is this a bug or by design? If by design, what relationships are affected by this behaviour?

-----------------------
|            A            |
-----------------------
|                          |
|   ----------------    |
|   |        B        |   |
|   ----------------    |
|   |                  |   |
|   ----------------    |
-----------------------

[Eve]

Yes. Different connectors have different behavior.

Nesting Aggregation/Composition are all specifying containment, while a Generalization isn't. ArchiMate specifies specific behavior for inferring specific relationships from visual nesting.

[Paolo F Cantoni]

Yes. Different connectors have different behavior.

Nesting Aggregation/Composition are all specifying containment, while a Generalization isn't. ArchiMate specifies specific behavior for inferring specific relationships from visual nesting.

Eve is correct in specifying what ArchiMate says on the matter (and if you're constrained to strict ArchiMate conformance, Modesto, you're out of luck).

But in the more general case, what you observed is the Use Case: "As a Modeler, I want to show that there is some sort of relationship between the enclosing and the enclosed items—by virtue of the enclosure."
"I am prepared to lose some visual information (i.e. the type of relationship), and I am prepared to conform to the requirement that all the enclosed items must be related to the enclosing item by the same type of relationship - whatever it is).  I will also materialize those relationships so that the relationship will be visible if the enclosed item is moved from the enclosure".

We developed a script to make everything happen and correct what we thought were anomalies in Sparx's implementation.  IIRC, the relationship is visually hidden, but the t_diagramlinks doesn't mark it as such.  We believed that t_diagramlinks should reflect the real state of the arc, depending upon the enclosure state.

HTH,
Paolo

[Modesto Vega]

I wasn’t referring specifically to ArchiMate’s implementation.

Nesting Aggregation/Composition are all specifying containment, while a Generalization isn't. ArchiMate specifies specific behavior for inferring specific relationships from visual nesting.

Are we risking reducing visual nesting to containment? Aggregation and Composition imply containment and I don’t have an issue with how Sparx EA hides these connectors  when visually nested, irrespective of whether I am using UML, ArchiMate, or SysML.

But they are not the 2 only connectors that would benefit from visually nesting. I would most definitely like to hide generalisations/specialisations when visually nesting, although they don’t specify containment. Sparx EA doesn’t make this very easy; as Paolo mentions in his reply, the only way to do this efficiently is writing a script.

[ea0522]

I use the visually nesting regularly, e.g. when an Application Component is served by a technical Node.
This is also one of the connectors which are not automatically hidden when visual nesting is applied.
The solution I use is to manually remove the connector from this diagram. As I usually draw diagrams by hand, this is not that much of a burden...

[Modesto Vega]

Good point, very often I manually hide links on diagrams but it is not very elegant. Ideally, I would like to have the functionality of hiding connectors on a per diagram basis in a similar way I can control element compartments,

[Eve]

Are we risking reducing visual nesting to containment?

You can use it however you want. My comment was an answer to your questions. "Is this a bug or by design?" - Design. "what relationships are affected by this behaviour?" - Aggregation, Composition, and Nesting.

[Eve]

IIRC, the relationship is visually hidden, but the t_diagramlinks doesn't mark it as such.  We believed that t_diagramlinks should reflect the real state of the arc, depending upon the enclosure state.

The problem with that is that EA wouldn't be able to tell if the user explicitly hid the relationship or it was hidden because it satisfied some condition (in this case visual containment of its ends). Dynamically determining it allows EA to preserve the state. Of course the opposite side of that is that you can't directly query for hidden/visible relationships.

[Paolo F Cantoni]

IIRC, the relationship is visually hidden, but the t_diagramlinks doesn't mark it as such.  We believed that t_diagramlinks should reflect the real state of the arc, depending upon the enclosure state.

The problem with that is that EA wouldn't be able to tell if the user explicitly hid the relationship or if it was hidden because it satisfied some condition (in this case visual containment of its ends). Dynamically determining it allows EA to preserve the state. Of course, the opposite side of that is that you can't directly query for hidden/visible relationships.

We understood this but felt it was the lesser of two evils.  We originally built the script because users were visually enclosing (note how we DON'T use the term containment) but NOT linking them with the appropriate relationships.  Our script examines the diagrams and asks the user what relationships to create when it finds cases of visual eclosure with missing relationships.  The relationships are created and then hidden - since this was clearly (as far as we are concerned) the user's intent.

We haven't had any complaints so far.

Paolo

[Edit: to do anything more complex (without a property to tag the suppression due to visual enclosure) would be immensely complex.  Also, we would need to tackle the question of "when we visually embed, are we implying that the same type of relationship exists between the Enclosing and enclosed items or not?  If not, how do we show any distinction?  Should we?]

[Eve]

We understood this but felt it was the lesser of two evils.

As long as I've communicated that your "should" is a matter of selecting from different imperfect solutions with different priorities then I'm satisfied.

[Modesto Vega]

Are we risking reducing visual nesting to containment?

You can use it however you want. My comment was an answer to your questions. "Is this a bug or by design?" - Design. "what relationships are affected by this behaviour?" - Aggregation, Composition, and Nesting.

Thank you for clarifying that this behaviour is by design and the foundation of Sparx EA - i.e., it is not an ArchiMate, UML, or SysML specific implementation. Your reply triggered the question in the quote above, to paraphrase myself:

Could the way Sparx EA implements visual nesting be understood as making visual nesting equivalent to containment?

If it is by design, why cannot be enhanced?

P.S.: We have had this conversation in this forum for as long as I have been a member.

[qwerty]

I guess it has historical roots. UML1.5 had no nesting association. It has been introduced only in a later edition. Even in 2.5.1 the nesting has no real name. It's described as "UMLEdge (between Namespace and NamedElement shapes)". So probably a difficult concept. Explains the length of the discussion.

q.

[Eve]

Could the way Sparx EA implements visual nesting be understood as making visual nesting equivalent to containment?

You seem to be understanding it that way. If so, at least it makes the meaning clear.

If it is by design, why cannot be enhanced?

It could, but it won't be from a random post on the forum. Submit a feature request.

[Modesto Vega]

I guess it has historical roots. UML1.5 had no nesting association. It has been introduced only in a later edition. Even in 2.5.1 the nesting has no real name. It's described as "UMLEdge (between Namespace and NamedElement shapes)". So probably a difficult concept. Explains the length of the discussion.

q.

Good point, the nesting connector is another form of containment and I am sure it add to the confusion. Visual nesting is an embellishment that does not imply containment, perhaps, as suggested by Paolo above, we should use visual enclosure instead of visual nesting.

The purpose of the embellishment is to convey more with less, less connectors in this case, whilst retaining all the supporting information in the repo.

Could the way Sparx EA implements visual nesting be understood as making visual nesting equivalent to containment?

You seem to be understanding it that way. If so, at least it makes the meaning clear.

I am attempting to clarify if Sparx EA currently treats visual nesting as containment. I do not understand that way, visual nesting/enclosure does not always imply containment. This is the point I am trying to convey in this thread.

If it is by design, why cannot be enhanced?

It could, but it won't be from a random post on the forum. Submit a feature request.

Done.