IMPORTED (227) - UML profile association - issues related to EA (Bugzilla Bug 26)

[datexii]

RE composite in UML profile manifests as shared aggregation in UML model.zip This issue was created automatically with bugzilla2github.py

Bugzilla Bug 26

Date: 2019-02-28T16:29:57+01:00 From: @ingeniumfaber To: @JosefKaltwasser CC: @iancornwellmottmac

Last updated: 2024-06-03T11:22:10+02:00

[datexii]

Comment 71

Date: 2000-01-01 01:01:01 +0100 From: @ingeniumfaber

The UML Profile initially used the metaclass Composition as the basis for the D2Relation stereotype. A sparx support engineer recommended to Ian Cornwell that we use Association instead, with an attribute set to indicate the composition, because the Composition metaclass was only kept for UML 1 compatibility. We tried using the Association metaclass, and this appeared to work in the EA user interface, but this had unwanted impact in the XMI: - we get extra elements with , implying that something is not recognising the stereotype as part of the profile. - we have 2 different XMI outputs for different instances of new associations, yet we cannot now see any difference between the model elements in the UI. For some instances, but not all instances, the XMI contains an ownedAttribute inside the class at the “whole” end of the composition. To explore, I created 2 new associations between different classes, using the same process; for one association the ownedAttribute appeared in the XMI but for the other it did not. So the implication is that the classes in some way determine whether this element appears, but I don’t know what property of the classes. Neither of the two different possible XMI outputs are the same as the ones created with the old profile, so the XMI is less consistent than before. These considerations caused us to consider reverting to the previous profile, but we should reconsider the issue if we get any further information from sparx.

[datexii]

Comment 72

Date: 2000-01-01 01:01:01 +0100 From: @JosefKaltwasser

EN 16157-1 will now be published based on the Composition metaclass. Should we get informed that the issues described have been solved by sparx, we should consider to migrate to using Association and include the change in a corrigendum to EN 16157-1.

[datexii]

Comment 73

Date: 2019-02-28 16:29:57 +0100 From: bugzilla admin <webmaster@datex2.eu>

--- Bug imported by webmaster@datex2.eu 2019-02-28 16:29 CET ---

This bug was previously known as bug 227 at https://bugzilla.datex2.eu/show_bug.cgi?id=227 This bug blocked bug(s) 2.

Bug Status was IN_PROGRESS but everconfirmed was false Setting status to UNCONFIRMED

[datexii]

Comment 1447

Date: 2020-09-01 15:03:49 +0200 From: @JosefKaltwasser

Set to CONFIRMED. We will re-test, but since it would mean changing the UML profile, this will have to wait for v4.

[datexii]

Comment 1659

Date: 2022-02-18 15:48:11 +0100 From: @iancornwellmottmac

Created attachment 35 Sparx support thread on D2Relation stereotype

Attached file: RE composite in UML profile manifests as shared aggregation in UML model.msg (application/x-ole-storage, 162304 bytes) Description: Sparx support thread on D2Relation stereotype

[datexii]

Comment 1660

Date: 2022-02-18 15:49:18 +0100 From: @iancornwellmottmac

More detail of where the conversation with Sparx in 2017-18 reached:

They agreed that there was a problem with the model using the profile (with the composite association). They said it was not easy to say why this happens. This unexpectedly led to a conversation about EA security, and at that time we had decided to revert for release 3.0, so we told Sparx we would pause the issue for now. In case somebody ever needs to re-raise this, I am attaching the email dialogue with Sparx.

[datexii]

Comment 1707

Date: 2022-06-27 17:16:01 +0200 From: @iancornwellmottmac

We plan to retest in EA v16 once we confirm that v16 and its new QEA format are working OK for us.

[datexii]

Comment 1817

Date: 2023-03-17 08:36:37 +0100 From: @iancornwellmottmac

Ian tested this again in EA v16 using a profile wrapped in MDG technology which we now need to use to get our UML profile to work properly.

The XMI problem of some associations being attached to a "custom profile" rather than the DATEX II profile seemed to have gone.

In my experiments I could see no anomalies with the XMI, but I see from the initial comment in this issue that there were things that appeared for relationships between some classes and not others, so we should check again for a variety of different classes in different namespaces, created at different times in the past, before we conclude that the switch to Association is successful.

By default the Association is directed. We discussed this at TB and agreed that we want to keep it bi-directional like today, so we can set the metaclass property accordingly.

When we set the Composite property of the Association metaclass, we have to choose composite at source or composite at target (source and target being EA terms rather than UML 2 terms). The TB agreed that modellers more naturally think of the "source" being the composite, and the "target" being the part, but DATEX II so far has used the opposite convention. The TB agreed that as modellers unless we remember the DATEX II convention we naturally want to draw relations from composite to part, until we remember that in DATEX II models we have to do it from part to composite, which was agreed to be less natural. Since we are changing the profile and have to build this direction into the profile explicitly in a new way, we considered whether we can change the convention. To do it for all new relations is no extra work, but we'd also have to change all existing relations. The TB agreed that to tell the user community to change the direction of dragging is fine, no issue, so whether we do this depends on the amount of work needed to convert all existing relationships. That will probably need something like an XMI transformation. The TB agreed that if we can do this in no more than 2 days work, we should do it (for v4 of course, assuming that the further test on use of Association shows no issues).

[datexii]

Comment 1961

Date: 2024-06-03 10:59:34 +0200 From: @iancornwellmottmac

Perhaps I was distracted by the source-target order issue (which we resolved successfully by scripting as is described in DevOps work items) because the "direction" property in the v4 profile used for the first attempt at a v4 model was still set to Source->Destination rather than Bi-directional. That needs fixed because it results in new relations being drawn with arrow-heads, which we said in this thread we did not want.

[datexii]

Comment 1962

Date: 2024-06-03 11:17:21 +0200 From: @iancornwellmottmac

Well, "Bi-directional" is not right by itself because that results in both arrows been drawn, even although that seems silly given that is what an unadorned association is supposed to mean.

[datexii]

Comment 1963

Date: 2024-06-03 11:22:10 +0200 From: @iancornwellmottmac

The direction value "Unspecified" seems to work though.