Hopex Unicity Constraint question

[dvanhoegaerden]

Hi,

A question about Hopex-Readiness.

As stated in the "how to prepare for Hopex" document,
the Hopex-Metamodel introduces a unicity-constraint : "Each Diagram can have only 1 described-object".
Macro's have been delivered to list violations to this constraint in earlier versions.

However,

When working with Mega Hopex V1R3(CP8), we notice that
multiple described-objects OF DIFFERENT METACLASSES are possible to create.

In the attached explorer screenshot (made by Hopex V1R3) you can see that Diagram "_Class Diagram-Test"
has 2 described objects : 1 Package and 1 Use case.
This behaviour is tested thoroughly by us, and it seems to be a stable construction.

Note: Adding another use-case will result in replacing the existing use-case, but eg. adding a class as a described-element, will work.

Questions :

1. Can this behaviour be accepted as normal Hopex-behaviour?

2. Can we rely on this in further cp's and patches?

Thx for your reply.

[jhorber]

This issue has been escaladed to MEGA R&D
Follow it with this ID: CR47627
We will keep you informed.

Note that in this scenario, a diagram is dragged and dropped onto a possible described object

At a functionnal level, this makes little sense.

[jhorber]

Hello

I can confirm that this rule (one diagram should not have several described objects) still applies.

This a good practise for modeling data.
Standard platform tools and standard metamodel should be designed to follow this rule.

As far as we know, they do follow it. If you can describe a case where they do not please create a case and report this in detail

Customization and modelled data should also follow this rule. We do not recommend to break it.

[dvanhoegaerden]

Update:
The behaviour described in the post above, is the behaviour after migrating our repository from Mega2009 to Hopex.

A Standard (out-of-the-box) created environment and repository only allows 1 described-element (no matter what the object-type is).

So it seems that -when migrating- we inherit some metamodel-changes (multiplicity?) from Mega2009, that make this possible.

The question now is : can we leave this like it is, or does this metamodel-change has to be undone?

Please advice.