Allow free-standing structural elements in composite diagram

[Uffe]

Hi all,


EA does not allow structural elements (ports, activity parameters, etc) to be placed in a diagram unless their parent element is in the diagram as well.
This makes sense in most situations, but when the diagram is the composite diagram for the parent element it does not.

I would like to propose, therefore, a relaxation of the parent element restriction to allow structural elements to be placed in a diagram without their parent element if the diagram is the composite diagram of the parent element.

A composite diagram typically depicts the inner structure of a parent element -- a structural breakdown in the case of classes and components, or a behavioral breakdown in the case of activities -- with the structural elements representing parts of that breakdown.
In these cases, the presence of the parent element in the diagram serves no semantic purpose: if the diagram's context is a breakdown of an element, that element is unnecessary. All it does is cause layout problems.
However, if you want to show the structural elements, you have to include the parent. There's no other way to get them in there.

So EA should allow structural elements to be placed freely within the composite diagram of their parent element.

If the user chooses to place the parent element in its own composite diagram, the old rules should apply and the layout of the structural elements should be locked to the parent element.

You can almost see what I'm after by creating a diagram filter which hides the parent element's type, and applying it in a composite diagram. This causes the structural elements to appear to be free-floating, although they are in fact still constrained by the hidden parent element.


/Uffe

[Paolo F Cantoni]

Interesting proposal, Uffe.

However, notwithstanding EA's UI, the ONLY thing EA knows about the attached diagram is that it is attached to the Parent object.  We use that fact to hijack the linkage for our Neighborhood diagrams.  Consequently, how can you tell it's a composite structure diagram?  In my MDG, the usual markers may not apply...

Paolo

PS: Our Neighborhood diagrams bump into the same problem.  But that's because we haven't written the code to place the parent object on the diagram.  Like Sparx bug fixes, it will come sometime before the end of the universe...   

[Uffe]

Interesting proposal, Uffe.

However, notwithstanding EA's UI, the ONLY thing EA knows about the attached diagram is that it is attached to the Parent object.  We use that fact to hijack the linkage for our Neighborhood diagrams.  Consequently, how can you tell it's a composite structure diagram?  In my MDG, the usual markers may not apply...

Paolo

PS: Our Neighborhood diagrams bump into the same problem.  But that's because we haven't written the code to place the parent object on the diagram.  Like Sparx bug fixes, it will come sometime before the end of the universe...   

I'm not sure I quite understand the objection. Looking at a diagram in and of itself, you can't tell whether it is the composite diagram for an element. But you can tell whether an element has a composite diagram, and if so, which one it is. (NType=8, PDATA1=Diagram ID). This works even if someone has been evil and moved the diagram out of its parent element in the project browser (meaning the diagram's ParentID no longer contains the ID of the element for which it is the composite diagram).

So you can ascertain whether a diagram is a composite diagram, and if so, which element it is the composite diagram of. That's all you need.
Now it is possible to abuse EA and make one diagram be the composite diagram of two elements. But that's not a problem for this proposal: as long as you can establish that a diagram is a composite diagram, you can relax the parent-element-must-be-present restrictions for the structural elements of any of the elements for which the diagram is the composite diagram.
For the proposal to work, you only need to establish whether the diagram is the composite diagram of an element which has structural elements.

EA already does this kind of check when determining whether to draw the composite icon on an element, and it does it correctly even when abused as outlined.


/Uffe

[Paolo F Cantoni]

Hi Uffe,

Sorry, I didn't make myself clear enough.  I have no objection to the proposal, just the terminology.  "Composite Diagram" as a term (a contraction of Composite Structure Diagram) has a specific meaning.  EA can create such  (formal) Composite Diagrams and attach them to the item.  However, as I pointed out, not every attached diagram need be a Composite diagram (and in our repository the overwhelming majority aren't).  The chain link indicator hints at the difference between composition and linkage.

I've currently started working on our diagrammer to make it include the "embedded" items on our Neighborhood diagrams.  (Embedded is not quite the right term in my view, but I'll use it).  It's not rocket science, but it is a bit tedious.

Palo

[Uffe]

Right, with you.

While it is overwhelmingly likely that the term "composite diagram" indeed derives from "composite structure diagram", they're not the same thing in EA's terminology. "Composite structure diagram" is a diagram type, while a "composite diagram" is, shall we say, a diagram role -- it indicates a special relationship between an element and a diagram.

In MDG Technology design, you specify in an element stereotype definition whether creation of elements with that stereotype should also cause the creation of such special diagrams, and if so, what type of diagram should be created. These properties are called _makeComposite and _defaultDiagramType, respectively.

So the term "composite" is in there, and does not refer specifically to the "composite structure" diagram type. In addition, the GUI allows you to select any type of diagram as the "composite diagram" for an element. Even the default composite diagram type for an element type is not necessarily the composite structure diagram. Activities, for instance, get an activity diagram.

I agree that "attached", or better still "linked", diagram would be a better term for these, especially since as you point out a link is clearly what the icon indicates. So an element may have any number of "child" diagrams, and may have one "linked" diagram, which by default is a child diagram, but does not actually have to be(!).
Buuuut, since the term "composite" is used in MDG Technology definitions, it can't be changed.

Also, I make it a policy to rather use a supplier's bad terms than make up my own good ones -- at least that way, explaining them isn't my problem. 


/Uffe

[Paolo F Cantoni]

[SNIP]

Also, I make it a policy to rather use a supplier's bad terms than make up my own good ones -- at least that way, explaining them isn't my problem. 


/Uffe

That's OK when there's only one supplier.  In my "day job" there are several in many instances and they all tend to disagree. So, my experience is that it is better to use the correct term - with, of course, supplying the mapping.

Also, since I also have to create structured language and have now a reasonable idea of "how language needs to work" in order to communicate unambiguously, I get protective of terms.

"Composite Structure Diagram" makes sense, "Composite Diagram" actually doesn't.  The former means a diagram that is the composite structure (of something), the latter means a diagram of composites?

Paolo

[Uffe]

[SNIP]
Also, I make it a policy to rather use a supplier's bad terms than make up my own good ones -- at least that way, explaining them isn't my problem. 

That's OK when there's only one supplier.  In my "day job" there are several in many instances and they all tend to disagree. So, my experience is that it is better to use the correct term - with, of course, supplying the mapping.

Absolutely. When maintaining the mapping is an option, that is the better way to go. I was speaking more specifically about this forum.
Contexts for, uh, hontexts, I guess.

Also, since I also have to create structured language and have now a reasonable idea of "how language needs to work" in order to communicate unambiguously, I get protective of terms.

That's OK. It just means you're an architect. A much maligned profession, without which nothing has a hope in hell of being delivered to spec or on time.

"Composite Structure Diagram" makes sense, "Composite Diagram" actually doesn't.  The former means a diagram that is the composite structure (of something), the latter means a diagram of composites?

Yeah... "Linked Diagram" would be better, but we won't see that change I fear.

/U