Sparx Systems Forum
Enterprise Architect => Automation Interface, Add-Ins and Tools => Topic started by: Viking on August 13, 2024, 03:46:46 am
-
Hi,
- From my point of view Archimate Grouping is normal Element. O.k., a composite element, but still like the others. EA considers it as a relationship. Is this correct?
- In EA, if the element has been created, it is added under the 3 dots like text elements, etc. It is handled as an UML boundary, not as a normal Archimate element. Why?
- By the way, what’s the name of these three dots and is it described somewhere, what I can do with this? By the way, if adding an “Archimate Relationships (dynamic.other)” (this is where to find Grouping in the toolbox), why are other relationships are not handled the same way? I would find it very helpful to find relationships in the project browser (like other tools do).
- If I copy a diagram without (Archimate) elements, the elements are not copied, excepts the Grouping. Why?
- The Archimate speciation proposes to use Derivation relationship in conjunction with Grouping. Is there any in EA? I could not find it.
Many thanks in advance, V.
-
1. Why do you say EA considers it a relationship?
2. Because the closest analogy is the Boundary, and so that the default behavior for moving an element onto one isn't to move the element under the group.
3. I don't know if there's a name. You can see the elements in the browser because before that was added you couldn't.
4. Because even a shallow copy copies boundaries.
5. Derivation isn't a relationship type. The example in the spec shows an indirect serving relationship being derived.
-
1. Why do you say EA considers it a relationship?
2. Because the closest analogy is the Boundary, and so that the default behavior for moving an element onto one isn't to move the element under the group.
3. I don't know if there's a name. You can see the elements in the browser because before that was added you couldn't.
4. Because even a shallow copy copies boundaries.
5. Derivation isn't a relationship type. The example in the spec shows an indirect serving relationship being derived.
Many thanks @Eve for your answers. Very helpful.
"1. Why do you say EA considers it a relationship?" I mentioned this below: “Archimate Relationships (dynamic.other)”
"2. Because the closest analogy is the Boundary" Yes, I understand that. But because of that it seems not to be an element like the others. It does not have an Archimate "name", etc.
"3. I don't know if there's a name." you are from Sparx. Just take one :-)
"3. You can see the elements in the browser because before that was added you couldn't." Yes, its helpful. Before I thought that they were gone. I transfered an old repositoty into a new version of Sparx and surprisingly there were a lot of old elements.
One missing answer: wouldn't it be helpful to list relationships like elements in the project browser? In the folder of the 3 dots.
-
1. The 'Other Concepts' is a group that isn't attached to any of the groups above. So the label 'Relationships' that appears on groups above are irrelevant.
2. If you select it the properties window still offers all the same properties including name.
3. The issue was that I didn't want to look at the documentation.
https://sparxsystems.com/enterprise_architect_user_guide/17.0/the_application_desktop/modelpackagereference.html (https://sparxsystems.com/enterprise_architect_user_guide/17.0/the_application_desktop/modelpackagereference.html)
An Annotation Package is a specialized form of Package that is automatically created when a parent Package has one or more diagrams that contain diagrammatic elements - non-model elements that have no purpose outside a diagram. Such elements include Notes, Text, Boundary elements and Navigation Cells.
There have been requests in the past to show relationships. I'm not going to discuss any feature requests here.
-
Maybe a silly question in this discussion.
Is this not an issue of the ArchiMate MDG?
According to the specification (https://pubs.opengroup.org/architecture/archimate3-doc/ch-Generic-Metamodel.html#sec-Grouping (https://pubs.opengroup.org/architecture/archimate3-doc/ch-Generic-Metamodel.html#sec-Grouping)):
4.5.1. Grouping
The grouping element aggregates or composes concepts that belong together based on some common characteristic.
So shouldn't then the ArchiMate MDG define a Grouping element?
In my experience, there is a difference between the ArchiMate Grouping element and the visual grouping of elements on a diagram.
With the ArchiMate Grouping, it should be possible to define relationships between the Grouping element and the elements grouped by it.
While the grouping on a diagram is only visual, there is no relation with the elements contained within the group.
-
2. If you select it the properties window still offers all the same properties including name.
Is Grouping really just a "diagrammatic element" due to the Archimate specifiation? For my understanding it is a "normal" element and that's why I would have considered it in the normal toolbox, with a stereotype assign to it and furthermore not stored in the annotation package.
3. The issue was that I didn't want to look at the documentation.
https://sparxsystems.com/enterprise_architect_user_guide/17.0/the_application_desktop/modelpackagereference.html (https://sparxsystems.com/enterprise_architect_user_guide/17.0/the_application_desktop/modelpackagereference.html)
An Annotation Package is a specialized form of Package that is automatically created when a parent Package has one or more diagrams that contain diagrammatic elements - non-model elements that have no purpose outside a diagram. Such elements include Notes, Text, Boundary elements and Navigation Cells.
:-)) Many thanks.
There have been requests in the past to show relationships. I'm not going to discuss any feature requests here.
Yes, of course.
-
Is Grouping really just a "diagrammatic element" due to the Archimate specifiation? For my understanding it is a "normal" element and that's why I would have considered it in the normal toolbox, with a stereotype assign to it and furthermore not stored in the annotation package.
This is the key question; it was a bit disappointing to find it is not implemented as a "proper"/"normal" element. But if the specification mandates it is essentially a decoration, it probably has been implemented correctly.
-
Is Grouping really just a "diagrammatic element" due to the Archimate specifiation? For my understanding it is a "normal" element and that's why I would have considered it in the normal toolbox, with a stereotype assign to it and furthermore not stored in the annotation package.
This is the key question; it was a bit disappointing to find it is not implemented as a "proper"/"normal" element. But if the specification mandates it is essentially a decoration, it probably has been implemented correctly.
Could you post a reference to this, please?
-
Could you post a reference to this, please?
According to the specification (https://pubs.opengroup.org/architecture/archimate3-doc/ch-Generic-Metamodel.html#sec-Grouping):
4.5.1. Grouping
The grouping element aggregates or composes concepts that belong together based on some common characteristic.
So shouldn't then the ArchiMate MDG define a Grouping element?
In my experience, there is a difference between the ArchiMate Grouping element and the visual grouping of elements on a diagram.
With the ArchiMate Grouping, it should be possible to define relationships between the Grouping element and the elements grouped by it.
While the grouping on a diagram is only visual, there is no relation with the elements contained within the group.
-
Could you post a reference to this, please?
According to the specification (https://pubs.opengroup.org/architecture/archimate3-doc/ch-Generic-Metamodel.html#sec-Grouping):
Thank you. But I meant, if the is something in the specification which says something like this: "the specification mandates it is essentially a decoration"
-
if the is something in the specification which says something like this: "the specification mandates it is essentially a decoration"
Sorry, I don't understand.
If the specification says "The grouping element aggregates or composes", why should it then be (only?) some decoration?
As I said, there is a difference between a grouping decoration and a Grouping Element.
The grouping decoration is purely visual and supported by all drawing tools which are capable of drawing a rectangle over some other objects.
The Grouping Element is (or should be) a modeling object with attributes and capabilities like other modeling objects like e.g. a name, relationships, etc.
-
if the is something in the specification which says something like this: "the specification mandates it is essentially a decoration"
Sorry, I don't understand.
If the specification says "The grouping element aggregates or composes", why should it then be (only?) some decoration?
As I said, there is a difference between a grouping decoration and a Grouping Element.
The grouping decoration is purely visual and supported by all drawing tools which are capable of drawing a rectangle over some other objects.
The Grouping Element is (or should be) a modeling object with attributes and capabilities like other modeling objects like e.g. a name, relationships, etc.
It should not, I think that this is just an accident. I experimented with it yesterday and it turns out that it behaves as a proper element - i.e., I can draw relationships such as Flows, Compositions, Aggregations.
-
Hello all,
I think that even though we can draw a relationship between an Archimate Group and other Archimate elements, we cannot say that the elements are belong to the Group because the current EA Boundary (the base of the Archimate Group) is just a graphical object. Even if we move an object into the boundary in a diagram, we have no way to confirm that the boundary has (contains) the object as model (without diagram presentation). We cannot see the relationships between the Group and elements in the Group in the current EA features.
If an Archimate Group were extended from another type e.g., Class, we could confirm a parent-child relationship in the Browser and in the Traceability window when we move an object into an Archimate Group. But to apply this implementation, there must be a constraint that an object can be belong to at most 1 Group. I could not find such a constraint like this.
From this point of view, I think the current implementation (i.e., an Archimate Group is extended from the Boundary) might be reasonable.
-
if the is something in the specification which says something like this: "the specification mandates it is essentially a decoration"
Sorry, I don't understand.
If the specification says "The grouping element aggregates or composes", why should it then be (only?) some decoration?
As I said, there is a difference between a grouping decoration and a Grouping Element.
The grouping decoration is purely visual and supported by all drawing tools which are capable of drawing a rectangle over some other objects.
The Grouping Element is (or should be) a modeling object with attributes and capabilities like other modeling objects like e.g. a name, relationships, etc.
100% agreed. A grouping is an Element, not a decoration. That's why EA should change this.
-
It should not, I think that this is just an accident. I experimented with it yesterday and it turns out that it behaves as a proper element - i.e., I can draw relationships such as Flows, Compositions, Aggregations.
EA stores a "Grouping" in the Annotation Package (3 dots), where EA stores the decorations like note, text, etc. In EA, Grouping is not a "real" element (like an UML class).
-
I think that even though we can draw a relationship between an Archimate Group and other Archimate elements, we cannot say that the elements are belong to the Group because the current EA Boundary (the base of the Archimate Group) is just a graphical object. Even if we move an object into the boundary in a diagram, we have no way to confirm that the boundary has (contains) the object as model (without diagram presentation). We cannot see the relationships between the Group and elements in the Group in the current EA features.
The fact that you cannot see whether there is a relationship defined between the ArchiMate Grouping and its contained elements is part of the ArchiMate specification and very similar to the nesting of elements when using Composition or Aggregation relationships. If you enlarge an element and drop some other elements within its boundaries, the Composition relations are not shown on the diagram which is according to the specification.
If an Archimate Group were extended from another type e.g., Class, we could confirm a parent-child relationship in the Browser and in the Traceability window when we move an object into an Archimate Group. But to apply this implementation, there must be a constraint that an object can be belong to at most 1 Group. I could not find such a constraint like this.
Why should there be a constraint that an object can only belong to at most 1 Grouping? There is no such constraint on other relationships like Composition or Aggregation. And I think it is possible to have a single element to belong to more groups. Even when using the drawing option, it is possible to draw a (very) large group containing more groups each containing other elements. The inner elements then should belong to both groups.
So, concluding, I believe both options should be available:
- ArchiMate Grouping as a separate Element type which can be re-used and moved around like other ArchiMate elements.
- Visual grouping as implemented now with only visual impact and stored in the ... folder.
Possible solution to add the ArchiMate Grouping as element to the ArchiMate MDG implementation?