Showing results for 
Show  only  | Search instead for 
Did you mean: 

Hopex Unicity Constraint question


Hopex Unicity Constraint question



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.




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.






3 Replies

Re: Hopex Unicity Constraint question

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.


Re: Hopex Unicity Constraint question



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.


Re: Hopex Unicity Constraint question

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.