Bug 404282

Comment 1 Camille Letavernier 2013-03-25 13:25:47 EDT

This is a critical issue in the validation process.

A profile containing a Property without a type is valid for UML (A UML::Property doesn't need a Type). However, once defined, this produces an invalid Ecore (An Ecore::EStructuralFeature needs a Type). The problem is that we validate the profile (Although it is not meaningful), and the previous Ecore definitions (Which we cannot fix anyway; it is already too late), while we should only validate the new Ecore definition (And discard it when invalid)

Current validation algorithm:

First step:

- Validate the profile: OK
- Define the profile -> Produces an invalid Ecore definition

Second step:

- Validate the profile: Errors detected on the Ecore definition
- The profile cannot be defined

Expected validation algorithm:

First step:

- Define the profile
- Validate the definition: Not OK
- Revert the definition

Second step:

- Define the profile (e.g. after fixing the property type)
- Validate the definition: OK


Current workaround:

- Open the UML file with the UML Model Editor
- Unfold the UML Annotation (Under the root Profile)
- Delete the invalid EPackage definition


Raise the severity to critical

Comment 2 Ronan Bar 2013-03-26 05:38:45 EDT

Hi,
A Stereotype with a property which has no type is not valid in my view. I don't see how such a property could ever be used. Perhaps this is a lack of validation logic in the UML2 project rather than Papyrus?

It should be possible to have validation of the profile performed before the definition occurs. Perhaps this is a result of OCL not be properly supported on UML2 models at the moment? It would be trivial to have such constraints define in OCL.

So in my view the process needs a stronger validation at the UML level before a validation is performed on the Ecore at definition time.

Comment 3 Camille Letavernier 2013-04-15 04:44:39 EDT

Hi,

I think the idea in UML in general is that a Model doesn't need to be complete to be valid. We may for example consider that "no type" corresponds to a generic "Object" type. UML, as a generic language, tries to avoid such restrictions.

In the UML Specification:

> Semantics
> Values represented by the element are constrained to be instances of the type. A typed element with no associated type
> may represent values of any type.

Of course, when we apply a transformation (Such as the Profile definition, which is actually a transformation from a UML Profile to an Ecore Metamodel), we add new semantics, which may require additional constraints. So, what appears to be a valid Generic UML Model may not be valid in a specific context (Such as an Eclipse UML2 Profile)

Then, we can have at least three different approaches:

- Add validation constraints for our specific case (Eclipse UML2/Papyrus profile), e.g. "Properties must be typed", and forbid definition of an invalid Profile
- Make transformation choices, in this specific case, e.g. "Properties with no type correspond to Ecore EReferences typed with EObject" [However, there's a distinction in Ecore between EAttributes and EReferences, which doesn't exist in UML Properties, so the semantic is not fully preserved]
- Add post-transformation validation, e.g. "A UML Profile must be defined as a valid Ecore metamodel"

The first and second approaches are probably cleaner, while the third one is the safest. And, of course, we can combine them. In the end, to avoid crashing the models because of an invalid Ecore Metamodel, we need to have the third approach.

Comment 4 Camille Letavernier 2013-05-03 03:56:54 EDT

*** Bug 407122 has been marked as a duplicate of this bug. ***

Comment 5 Toni Siljamäki 2013-05-20 05:34:45 EDT

I just checked this.
Here is the analysis of the error, and the reasons.
Its simply one or several bugs in Papyrus.

There are garbage annotations left in the model .uml file after the stereotype property have been renamed and given a type.
The visual result of this is that there are model validation markers left in the model which cannot be removed, not even from the menu for it.

Here are two garbage annotations:

      <eClassifiers xmi:type="ecore:EClass" xmi:id="_wZkwnsEsEeKqqe9ZVUF4kw" name="myStereotype">
        <eAnnotations xmi:type="ecore:EAnnotation" xmi:id="_wZkwn8EsEeKqqe9ZVUF4kw" source="http://www.eclipse.org/uml2/2.0.0/UML" references="_ed7C4MEsEeKqqe9ZVUF4kw"/>
        <eStructuralFeatures xmi:type="ecore:EAttribute" xmi:id="_wZkwoMEsEeKqqe9ZVUF4kw" name="Attribute2" ordered="false" lowerBound="1"/>
      </eClassifiers>

      <eClassifiers xmi:type="ecore:EClass" xmi:id="_mokwnsEsEeKqqe9ZVUF4kw" name="myStereotype">
        <eAnnotations xmi:type="ecore:EAnnotation" xmi:id="_mokwn8EsEeKqqe9ZVUF4kw" source="http://www.eclipse.org/uml2/2.0.0/UML" references="_ed7C4MEsEeKqqe9ZVUF4kw"/>
      </eClassifiers>

Here is the stereotype, its renamed tagged value, with its type:

  <packagedElement xmi:type="uml:Stereotype" xmi:id="_ed7C4MEsEeKqqe9ZVUF4kw" name="myStereotype">
    <ownedAttribute xmi:type="uml:Property" xmi:id="_tDovEMEsEeKqqe9ZVUF4kw" name="myAttribute">
      <type xmi:type="uml:PrimitiveType" href="pathmap://UML_LIBRARIES/UMLPrimitiveTypes.library.uml#String"/>
    </ownedAttribute>
  </packagedElement>

The garbage annotations seem to be the reason that the profile having such "errors" will continue to be invalid forever.

My guess is that Papyrus have lost the track of them.

Comment 6 Toni Siljamäki 2013-05-20 06:46:26 EDT

When deleting the stereotype for which validation errors just was reported, the garbage annotations for the stereotype still remain in the .uml file.

Comment 7 Camille Letavernier 2013-05-20 08:06:09 EDT

The EAnnotations are not "garbage"; they are used for profile versionning and migration. Otherwise, you would not be able to open a model for which the profile has been redefined (= new version).

But indeed, the problem comes from the definition. We are able to produce invalid definitions (This is a UML2 bug, see Comment 3), and Papyrus checks too thoroughly the validity of the whole profile model. Which means that once an invalid definition has been produced, it remains forever and Papyrus keeps saying it is invalid (Which is true, by the way). And we don't allow invalid profile application because they can lead to corrupted models.

So there are actually two things here:

- The UML2 Profile Definition may produce an invalid Ecore metamodel from a valid UML2 profile
- Papyrus validation is too strict, as it always checks unchangeable, older definitions (Without any way to clean or repair them)

Comment 8 Toni Siljamäki 2013-05-20 17:53:34 EDT

01) We have a defined profile as a Papyrus "profile model" with no errors in it.
02) We add a new stereotype and rename it.
03) Right-click on the profile model in Model Explorer and run ->Validation->Validate model  (NOTE: takes a loooong time)
04) There were no errors in the "Model Validation" tab.
05) We save-and-define the profile (...and click Yes and OK to define the profile)
06) Then right-click on the profile model and run ->Validation->Validate model again.
07) Again, there were no errors in the "Model Validation" tab.
08) Then we add a new Child->Property/Attribute/Tagged Value to this new stereotype, added in 2) above.
09) Right-click on the profile model in Model Explorer and run ->Validation->Validate model.
10) No errors appears in the "Model Validation" tab.
11) We save-and-define the profile (...and click Yes and OK to define the profile)
12) No errors appears in the "Model Validation" tab.

After this, weird things begin to happen.
We can run any new or additional step after the above,
after which we need to save a new version, or just:

13) Right-click on the profile model in Model Explorer and run ->Validation->Validate model.

Then we suddenly get an error in the "Model Validation" tab, saying:  (textual error copy below)

Severity	Description	Element	Parent	Type
Error	The required feature 'eAttributeType' of 'Attribute2' must be set	Attribute2	<Profile> HiveProfile::UML::HiveProfile::myStereotype	EMF Problem

After this the problems just goes on... (just as RonanB described in the initial bug report)

NOTE 1:
Any model/profile validated & saved without errors must be possible to _trust_ as valid & correct, right?

NOTE 2:
Any meta-info persisted into the current Papyrus-3-file-model / controlled part (see old bug reports on this),
either into the in-memory-runtime model or into the persisted model files, or both, causing the very same model to
crash or fail in runtime, or when opening it again, which has not been properly informed to the user as
"validated as definitely correct" but is rather crashing in user-time, must be considered as incorrect, right?

NOTE 3:
Any invalid meta-data persisted into a Papyrus model causing it to crash the next time a user tries to
open it must be considered as garbage-meta-data, right? ...from a user point of view?

Comment 9 Remi Schnekenburger 2013-05-21 11:28:31 EDT

> NOTE 1:
> Any model/profile validated & saved without errors must be possible to trust as valid & correct, right?
Yes, it should. 
Thus, validation rules should be added and checked before defining a profile in Papyrus. This set of additional rules should check that the transformation UML Profile => Ecore model should be possible AND valid. In my opinion, this set of rules should even be implemented in Eclipse UML2 component.

>NOTE 2:
>Any meta-info persisted into the current Papyrus-3-file-model / controlled part (see old bug reports on this),
>either into the in-memory-runtime model or into the persisted model files, or both, causing the very same model to
>crash or fail in runtime, or when opening it again, which has not been properly informed to the user as
>"validated as definitely correct" but is rather crashing in user-time, must be considered as incorrect, right?
Yes. As Camille mentioned it before, the problem is that the checker verifies all definitions of profiles, not only the last one. so once it is corrupted, it remains corrupted unless the profile is cleaned.

>NOTE 3:
>Any invalid meta-data persisted into a Papyrus model causing it to crash the next time a user tries to
>open it must be considered as garbage-meta-data, right? ...from a user point of view?
Not really. In this case, these data are various version of the profile definition, and is required for profile migration from elder versions to the last one. This could be considered as garbage as soon as the developer of the profile decides it is obsolete. 


What I propose is the following solution:
1. We can develop a set of rules, that should be validated before defining a profile. This set of rule should check the consistency of the profile for the validation (=> So it would be impossible to generate an incorrect definition)
2. We can develop a tool to browse the different versions of definition for a given profile, and to delete some of this definitions.
3. We should investigate the possibility to check only last definition of the profile, instead of all versions, for compatibility reasons (profiles are already existing with wrong definitions)

Given the period (Feature/API freeze) and the time required for the developments, we can propose to release such features on 0.10.1 (SR1) in September, with developments starting at the beginning of July. Is this OK for you?

Comment 10 Camille Letavernier 2013-05-30 09:41:41 EDT

r11266:

- Pre- and Post- profile definition validations have been added (Validation of the profile -> definition -> validation of the profile definition).
- Pre-profile application validation has been added (Validation of the profile definition -> application)
- After each validation phase, a Diagnostic dialog is displayed (When errors occur)
- If a validation error occurs, the operation is rolled back (For definition or (re-)application)

The validation only applies to most recent definitions (i.e. the new definition when defining the profile, and the latest definition when apply the profile), which means that a profile which contains an (old) invalid definition can still be manipulated.

This should prevent most profile/model corruption errors. 

Note that it is still not recommended to manipulate a model with an old version of a profile (i.e. when the profile has been redefined)

Comment 11 Camille Letavernier 2013-05-30 10:34:02 EDT

r11267: The previous commit was incomplete

Comment 12 Toni Siljamäki 2013-08-15 09:23:31 EDT

Just tested this on an existing profile using steps 1-11) in Comment 8.
During step 12) there is now a pop-up error message saying that the
newly added attribute have no defined type.

According to Comment 10 this error means that the profile saving & definition
operation should be rolled back, but it is not, at least not etirely.

The final saving of the 3-file-model profile is not rolled back.
The profile files get saved and, consequently, get new time stamps,
but without stepping the profile version number.

The newly added attribute reported as incorrect is stored in the updated files.

Finally: The validation error reported in the pop-up message when
saving & defining the profile, why is that error not reported when
running the Validation -> Validate model on the profile in Model Explorer ?

Are there different types of validations?

This Bug 404282 should be reopened.  (but I cannot do it)

Comment 13 Camille Letavernier 2013-08-22 11:05:29 EDT

> The final saving of the 3-file-model profile is not rolled back.
> The profile files get saved and, consequently, get new time stamps,
> but without stepping the profile version number.

Saving and definition are (or should be) two distinct steps. There is definitely some improvement to be done here. But I'm pretty sure this is already being discussed somewhere else.

> Finally: The validation error reported in the pop-up message when
> saving & defining the profile, why is that error not reported when
> running the Validation -> Validate model on the profile in Model Explorer ?

The UML profile itself is valid. The profile definition, however, is a UML-to-Ecore transformation. It is the resulting Ecore metamodel which is invalid.

See Comment 1 and Comment 3 for details.