search

eclipse-uml2 / uml2

An EMF-based implementation of the UML 2.x metamodel for the Eclipse platform.
Eclipse Public License 2.0
5 stars 4 forks source link

Inconsistent Profile URIs #71

Open eclipse-uml2-bot opened 1 week ago

eclipse-uml2-bot commented 1 week ago

| --- | --- | | Bugzilla Link | 459606 | | Status | NEW | | Importance | P3 normal | | Reported | Feb 10, 2015 15:53 EDT | | Modified | Sep 14, 2017 04:09 EDT | | Blocks | 459520 | | See also | 522257, 522256 | | Reporter | Ed Willink |

Description

OMG UML used not to have Package URIs.

Ecore GenModel has always mandated a well-formed nsURI.

OMG has gradually acquired Package URIs, first as a Tag then as a property.

Eclipse UML is a bit of a mess.

The UML model is permitted to have no URI in accordance with the UML 2.5 multiplicity, but a URI is auto-generated when defining a profile. Confusingly if the URI is null/blank, each autogenerated nsURI is distinct. But if the URI is defined each nsURI is the same.

This practice is particularly bad in the case of Bug 459605 where profile definitions erroneously creoss-reference.

Suggest: Package with null/blank URI is a validation warning.

Suggest: Profile with distinct Package URI / EPackage nsURI is a validation error.

eclipse-uml2-bot commented 1 week ago

By Kenn Hussey on Feb 17, 2015 09:36

(In reply to Ed Willink from comment #0)

OMG UML used not to have Package URIs.

Ecore GenModel has always mandated a well-formed nsURI.

OMG has gradually acquired Package URIs, first as a Tag then as a property.

Eclipse UML is a bit of a mess.

The UML model is permitted to have no URI in accordance with the UML 2.5 multiplicity, but a URI is auto-generated when defining a profile.

The nsURI is auto-generated because the (EMF) package is auto-generated and the result must conform to EMF constraints.

Confusingly if the URI is null/blank, each autogenerated nsURI is distinct.

The nsURI must be distinct for each new profile version to support migration of profile/stereotype data.

But if the URI is defined each nsURI is the same.

If a URI has been specified by the user, the expecation is that the user will change the URI appropriately if/when necessary based on what’s changed in the profile - just as we do with other EMG-generated models.

This practice is particularly bad in the case of Bug 459605 where profile definitions erroneously creoss-reference.

Suggest: Package with null/blank URI is a validation warning.

I hesitate to introduce such a warning when it’s not a required property in UML.

Suggest: Profile with distinct Package URI / EPackage nsURI is a validation error.

What do you mean by this?

eclipse-uml2-bot commented 1 week ago

By Ed Willink on Feb 17, 2015 10:49

(In reply to Kenn Hussey from comment #1)

Suggest: Package with null/blank URI is a validation warning.

I hesitate to introduce such a warning when it’s not a required property in UML.

If Eclipse UML was 100% OMG compliant then I would agree, but in practice Eclipse UML is distorted by the use of Ecore, so a model that fails to fulfill the Ecore compatibility requirements merits a warning.

Suggest: Profile with distinct Package URI / EPackage nsURI is a validation error.

What do you mean by this?

If the UML Package uri or nsURI Tag is "x" and the EPackage nsURI is "y" then I consider this to be an error that the user would like to know about rather than have to debug the downstream consequences of incompatible UML/Ecore representations.

(These problems arise now because the Pivot-based Eclipse OCL now uses the UML model wherever possible ignoring the Ecore-isms. The Ecore-based Eclipse OCL used the Ecore and largely ignored the UML.)

eclipse-uml2-bot commented 1 week ago

By Kenn Hussey on Feb 17, 2015 11:19

(In reply to Ed Willink from comment #2)

(In reply to Kenn Hussey from comment #1)

Suggest: Package with null/blank URI is a validation warning.

I hesitate to introduce such a warning when it’s not a required property in UML.

If Eclipse UML was 100% OMG compliant then I would agree, but in practice Eclipse UML is distorted by the use of Ecore, so a model that fails to fulfill the Ecore compatibility requirements merits a warning.

Ah, but not every UML model gets converted to Ecore...

Suggest: Profile with distinct Package URI / EPackage nsURI is a validation error.

What do you mean by this?

If the UML Package uri or nsURI Tag is "x" and the EPackage nsURI is "y" then I consider this to be an error that the user would like to know about rather than have to debug the downstream consequences of incompatible UML/Ecore representations.

This is actually an expected condition until the Ecore package is regenerated - the user could be in the process of editing the profile…

eclipse-uml2-bot commented 1 week ago

By Ed Willink on Feb 17, 2015 12:13

(In reply to Kenn Hussey from comment #3)

Ah, but not every UML model gets converted to Ecore...

Hence a warning rather than an error. Really easy to make the warning go away.

This is actually an expected condition until the Ecore package is regenerated - the user could be in the process of editing the profile…

While I edit Java I have errors. No surprise. Why no diagnostic while editing UML?

eclipse-uml2-bot commented 1 week ago

By Kenn Hussey on Feb 17, 2015 13:13

(In reply to Ed Willink from comment #4)

(In reply to Kenn Hussey from comment #3)

Ah, but not every UML model gets converted to Ecore...

Hence a warning rather than an error. Really easy to make the warning go away.

I think this would be an annoyance for modelers that never have the intention of ever converting to Ecore.

This is actually an expected condition until the Ecore package is regenerated - the user could be in the process of editing the profile…

While I edit Java I have errors. No surprise. Why no diagnostic while editing UML?

Validation in UML2 is currently only based on constraints defined in UML, and those are processed in batch, on demand. Changing this would be a non-trivial undertaking and would provide questionable ROI in UML2 when the more appropriate place for such conveniences is at the application level.