Home » Modeling » Papyrus » Static profile OCL expressions referring to enumeration literals cause "contains a bad value&qu(Papyrus static profile issue)
| | |
| Re: Static profile OCL expressions referring to enumeration literals cause "contains a bad valu [message #1837382 is a reply to message #1837366] |
Fri, 29 January 2021 02:59   |
 Deniz Eren
Messages: 68
Registered: March 2014 |
Member |
|
|
Hi Ed,
Much appreciated thank you! I've learnt quite a few things from you now, and thank you for raising the bug ticket also.
After downloading your modifications, here is my breakdown.
Initially I had a missing bundle org.eclipse.ocl.examples.codegen; resolved by installing all OCL packages, perhaps some where missing (later discovered this is added to the META-INF/MANIFEST.MF during code generation when "Use Delegates" is enabled):
- OCL Build Support
- OCL Build Support Developer Resources
- OCL Classic SDK: Ecore/UML Parsers, Evaluator, Edit
- OCL Classic SDK: Ecore/UML Parsers, Evaluator, Edit Developer Resources
- OCL Examples and Editors SDK
- OCL Examples and Editors SDK Developer Resources
There was a missing file com.validationproblem.profile.validationproblem.ValidationProblemTables; this is a generated file also (only when "Use Delegates" is enabled) and is missing from my generated code because I was still using the interpreted execution rather than the Java. Well only because I didn't know how to make it generate the Java one until I reverse engineered the changes you did in your posted version!
It seems your version of the genmodel has the following, which I suspect is how we specify we want to generate Java code from OCL rather than use interpreted OCL:
<genAnnotations source="http://www.eclipse.org/OCL/GenModel">
<details key="Use Delegates" value="false"/>
</genAnnotations>
I then opened the file "ValidationProblem.profile.genmodel in the Eclipse editor (I even opened the previous version side-by-side to see if I am failing to see the option), but I could not see any of the options showing "Use Delegates". So the Eclipse genmodel editor UI does not show this option! Is it an invisible option? To help future people, in hindsight, where should I have looked to see this is even an option?!? Looking at the other genAnnotations in the genmodel file I'm inclined to believe it should be one of the options you tick when ReLoading the model importer (same location where the "Camel Case Names" option is) but even there I cannot see "Use Delegates" option. This is definitely something that will plague future people. Currently the only way to enable it as far as I can tell is to manually edit the genmodel file and add the above snippet!
Quote:
You seem to have been badly influenced by the UML spec
YES I have been, here is the specific item in the OMG UML version 2.5.1 specification formal/2017-12-05 states:
Quote:
Derivation: where an Attribute or Association End is marked as derived and is not a derived union, the derivation is specified by an Operation with the same name and type as the derived Attribute or Association End.
Another thing I learnt... Looking at your code and how you have speficied a UML OpaqueExpression (with OCL expression body) for the defaultValue of an ownedAttribute of a Property is something I did not know was possible! However, the defaultValue is a UML ValueSpecification element, so nothing stops it from being specified with an OpaqueExpression! Brilliant and it seems to be compliant with UML spec also; however I'm a little worried with the UML specification wording implying the defaultValue is only for the initial value of the Property "The evaluated default then becomes the initial value (or values) of the Property" it does however also say "The derivation for a derived Property may be specified by a constraint" however that doesn't say it's the defaultValue attribute of the property, but since it was talking about the defaultValue attribute just in the previous paragraph and I cannot see any other way of specifing a derived property with a constraint other than the defaultValue! OMG UML version 2.5.1 specification formal/2017-12-05 states:
Quote:
If there is a defaultValue specified for a Property, this default is evaluated when an instance of the Property is created in the absence of a specific setting for the Property or a constraint in the model that requires the Property to have a specificvalue. The evaluated default then becomes the initial value (or values) of the Property.
If a Property has isDerived = true, it is derived and its value or values may be computed from other information. Actions involving a derived Property behave the same as for a nonderived Property. Derived Properties are often specified to be read-only (i.e., clients may not directly change values). But where a derived Property is changeable, an implementation is expected to make appropriate changes to the model in order for all the constraints to be met, in particular the derivation constraint for the derived Property. The derivation for a derived Property may be specified by a constraint.
Thus quasi-uneasily I accept OCL in defaultValue for derived properties as a better way forward over same name operations after consulting the gospels of OMG :)
Quote:
There is no need for a "x" to redirect to "x()" to a Constraint.
I agree, however I often get worried if OCL will refer to the correct object (trust issues), for example, given StereotypeX extends NamedElement and self is a Stereotype that extends Dependency, if I have an OCL expression:
self.base_Dependency->forAll(StereotypeX.allInstances()->select(base_NamedElement = client)->notEmpty())
OCL must therefore know that within the "select" scope, the "base_NamedElement" refers to the StereotypeX iterator element and the "client" refers to the "base_Dependency" iterator element from the "forAll". What if both those iterators contained something that is called "client" or "base_NamedElement"?? Thus my insecurities and comfort in being explicit:
self.base_Dependency.client->forAll(aNamedElement : UML::NamedElement | StereotypeX.allInstances()->select(base_NamedElement = aNamedElement)->notEmpty())
I guess if there was a clash, then OCL would detect that ambiguity I am worried about?
After importing your posted changes my model generated the following Java code:
/**
* <!-- begin-user-doc -->
* <!-- end-user-doc -->
* @generated
*/
@Override
public EList<Enumeration1> getEnum1() {
/**
* Set{Enumeration1::EnumerationLiteral2}
*/
final /*@NonInvalid*/ Executor executor = PivotUtil.getExecutor(this);
final /*@NonInvalid*/ IdResolver idResolver = executor.getIdResolver();
final /*@NonInvalid*/ List<EnumerationLiteralId> ECORE_Set = ((IdResolverExtension)idResolver).ecoreValueOfAll(Enumeration1.class, ValidationProblemTables.Set);
return (EList<EnumerationLiteralId>)ECORE_Set;
}
Looks like the returned "EnumerationLiteralId" should be a "Enumeration1" as per your description of the problem in the Bug 570717 ticket?
After I generate the code gives Java Problems in Stereotype1Impl.java as expected and apparent from your bug report:
Type mismatch: cannot convert from EList<Enumeration1> to List<EnumerationLiteralId> Stereotype1Impl.java
Type mismatch: cannot convert from EList<EnumerationLiteralId> to EList<Enumeration1>
Your posted code changes looks to have been manually edited as follows (I guess this is your workaround for the bug you have reported?):
/**
* <!-- begin-user-doc -->
* <!-- end-user-doc -->
* @generated
*/
@Override
public EList<Enumeration1> getEnum1() {
/**
* Set{Enumeration1::EnumerationLiteral2}
*/
final /*@NonInvalid*/ Executor executor = PivotUtil.getExecutor(this);
final /*@NonInvalid*/ IdResolver idResolver = executor.getIdResolver();
// final /*@NonInvalid*/ List<EnumerationLiteralId> ECORE_Set = ((IdResolverExtension)idResolver).ecoreValueOfAll(Enumeration1.class, ValidationProblemTables.Set);
// return (EList<EnumerationLiteralId>)ECORE_Set;
final /*@NonInvalid*/ List<Enumeration1> ECORE_Set = ((IdResolverExtension)idResolver).ecoreValueOfAll(Enumeration1.class, ValidationProblemTables.Set);
return (EList<Enumeration1>)ECORE_Set;
}
When I replace my generated getEnum1 function with this one (seeming to be a manually edited workaround) the Validation checks and all other OCL expressions work!
Once again thank you for all your help!
Best regards,
Deniz
|
|
| | |
| Re: Static profile OCL expressions referring to enumeration literals cause "contains a bad valu [message #1837397 is a reply to message #1837394] |
Fri, 29 January 2021 10:22 |
Deniz Eren
Messages: 68
Registered: March 2014 |
Member |
|
|
Hi Ed,
Nice! There you are! -> OMG UML spec 6.5.2 Technical Support:
Quote:
The following people provided technical support for this specification, including writing tools to generate portions of the document and to validate the OCL:Peter Denno, Maged Elaasar, Nicolas Rouquette, Ed Willink
I definitely noticed some issues in the UML metamodel also, but I wasn't sure if I'm wrong - I was wondering how I can report it back to OMG but never looked into it yet - perhaps you have pointers? For example in UML machine consumable xmi 2.5.1 xmi-id "Namespace-excludeCollisions" has OCL:
result = (imps->reject(imp1 | imps->exists(imp2 | not imp1.isDistinguishableFrom(imp2, self))))
But it should have "imp1 <> imp2" like this:
result = (imps->reject(imp1 | imps->exists(imp2 | imp1 <> imp2 and not imp1.isDistinguishableFrom(imp2, self))))
There was a couple others I noticed, can't seem to remember at the moment.
Anyway, regarding this new problem, from what I can tell the stereotype "Depends" constraints supplier_is_Stereotype1 and client_is_Stereotype1 do not get called at all when you right-click the test application model and select Validation -> Validate model.
I'm uploading the updated Git ValidationProblem2.tar.gz (containing also your changes) and I've added some System.out.println to show that these constraint functions are not called by the Papyrus framework during model validation!
I have also checked that genmodel contains the "Model Plug-in Class" - if that makes a difference?
Otherwise, all the other OCL functions such as derived properties are working much better with the Java version as you have indicated. As per your earlier comments, the Java version is far more responsive and clearly faster to execute when navigating the Papyrus model - very happy with this decision to move to Java.
I know you are busy with the previous bugs, any quick pointers you have for me to try to get the validation calls working?
Best regards,
Deniz
|
|
|
| Re: Static profile OCL expressions referring to enumeration literals cause "contains a bad valu [message #1837403 is a reply to message #1837397] |
Fri, 29 January 2021 12:12 |
Ed Willink
Messages: 7655
Registered: July 2009 |
Senior Member |
|
|
Hi
The direct Java code, although a bit verbose and only 'half-readable' is also much better for debugging. Many optimisation opportunities remain for my next model-driven rewrite.
I'm not 100% sure what the Model Plug-in Class is; probably its just the Activator that you don't need for a boring model but may need if you start elaborating with manual code that uses the ResourceLoader to intemationalize error messages.
OMG bugs may be reported at https://issues.omg.org/issues/create-new-issue
Prior to UML 2.5, the OCL in the UML specification was open loop best endeavours and had many hundreds of errors since it had never been though a tool that checked syntax. How good would your coding be in a new language without any tooling support? For UML 2.5, I fixed all syntax errors and all semantic errors, but when I improved Eclipse OCL tooling four new semantic errors were detected just too late to go into 2.5. AFAIAA there has never been any comprehensive execution of the OCL so there are no doubt hundreds of functional errors to be resolved. Sadly no implementer, such as the Eclipse UML2, fed back the discrepancies they uncovered when transcribing from specification OCL to their preferred implementation language (Java for Eclipse UML2). While developing the Validity View I accidentally found that I was executing the OCL for the UML and it was really really slow so I guess the main class structure constraints are right, but direct use needs some significant optimization in regard to rewriting allInstances as package constraints and avoiding naive cascaded collections.
What Papyrus calls during model validation doesn't particularly interest me. When investigating defective tooling, you should load your model in the UML Model Editor and (EMF->)Validate there and if you're not happy try OCL->Validate. Anything that works in the UML Model Editor but doesn't work in Papyrus is a Papyrus bug.
(EMF has a clear validate API that applies to all EObjects in a model. Unfortunately the OMG specification decided that a Stereotype application did not merit a StereotypeApplication class and so there is XMI magic for some dynamic/reflective content. The UML2 representation is faithfully irregular and outwits the EMF API. The better OCL->Validate remedies the missing UML validation, and Papyrus picked up the OCL fix, but the developers forgot why they had one bit of irregular code and yet another for the wierd EMFv Constraint capability; the OCL validation got lost for a while. Meanwhile UML2 improved its validation and Papyrus changed. Just remember that OCL->Validate is there in case the other tools are not doing their job properly.)
Regards
Ed Willink
|
|
| | | |
| Re: Static profile OCL expressions referring to enumeration literals cause "contains a bad valu [message #1837443 is a reply to message #1837442] |
Sat, 30 January 2021 02:55 |
Deniz Eren
Messages: 68
Registered: March 2014 |
Member |
|
|
Hi Ed,
I posted another Papyrus bug I came across when I was creating a single Integer typed Property, Bug #570772: https://bugs.eclipse.org/bugs/show_bug.cgi?id=570772
Attached updated profile with the Integer issue ValidationProblem4.tar.gz
Anyway, the actual problem I was replicating is this Integer Set issue when generating Java static profile "EList<IntegerValue> -> EList<Integer>" problem.
Perhaps I'm hitting my Java knowledge limit as it now seems to deal with a literal int value using ValueUtil.intValueOf but we need to somehow turn that back into EList<Integer> - I tried seemed to have fixed it, but can you please verify that fix is OK?
Anyway, it's definitely a special case of the previous problem we identified:
/**
* <!-- begin-user-doc -->
* <!-- end-user-doc -->
* @generated
*/
@Override
public EList<Integer> getIntegerSet() {
/**
* Set{101}
*/
final /*@NonInvalid*/ Executor executor = PivotUtil.getExecutor(this);
final /*@NonInvalid*/ IdResolver idResolver = executor.getIdResolver();
final int ECORE_Set_0 = ValueUtil.intValueOf(ValidationProblemTables.Set_0);
return (EList<IntegerValue>)ECORE_Set_0;
}
Here is my manual workaround fix:
/**
* <!-- begin-user-doc -->
* <!-- end-user-doc -->
* @generated
*/
@Override
public EList<Integer> getIntegerSet() {
/**
* Set{101}
*/
final /*@NonInvalid*/ Executor executor = PivotUtil.getExecutor(this);
final /*@NonInvalid*/ IdResolver idResolver = executor.getIdResolver();
// final int ECORE_Set_0 = ValueUtil.intValueOf(ValidationProblemTables.Set_0);
// return (EList<IntegerValue>)ECORE_Set_0;
final /*@NonInvalid*/ List<Integer> ECORE_Set_0 = ((IdResolverExtension)idResolver).ecoreValueOfAll(Integer.class, ValidationProblemTables.Set_0);
return (EList<Integer>)ECORE_Set_0;
}
Should I create another Bugzilla ticket for this case or will you handle it as part of the previous generator issue?
Best regards,
Deniz
[Updated on: Sat, 30 January 2021 03:06] Report message to a moderator |
|
| | |
| Re: Static profile OCL expressions referring to enumeration literals cause "contains a bad valu [message #1837451 is a reply to message #1837448] |
Sat, 30 January 2021 09:08 |
Deniz Eren
Messages: 68
Registered: March 2014 |
Member |
|
|
Hi Ed,
I've again attached the replication profile/application projects.
I'm getting another Java generation error that is different to ones we've discussed. This time an exception is thrown:
org.eclipse.ocl.pivot.values.InvalidValueException: Unknown enumeration EnumerationLiteral1
at org.eclipse.ocl.pivot.internal.library.executor.AbstractIdResolver.boxedValueOfEnumerator(AbstractIdResolver.java:516)
at org.eclipse.ocl.pivot.internal.library.executor.AbstractIdResolver.boxedValueOf(AbstractIdResolver.java:439)
at org.eclipse.ocl.pivot.internal.library.executor.AbstractIdResolver.createSetOfAll(AbstractIdResolver.java:653)
at com.validationproblem.profile.validationproblem.impl.Stereotype1Impl.getVal1(Stereotype1Impl.java:464)
at com.validationproblem.profile.validationproblem.impl.Stereotype1Impl.eGet(Stereotype1Impl.java:508)
So basically I added 2 properties to the Steroetype1 stereotype called "pin" and "val1". "val1" is a derived property that is set to "pin" if "pin" (which is of type Enumeration1) is not set to enumeration literal "unrestricted", or if it's set to "unrestricted" it takes the value of the parent Class that has the stereotype applied, or else the default value of "EnumerationLiteral1".
In OCL the property defaultValue looks like this:
let allStereotype1 : Set(Stereotype1) = Stereotype1.allInstances() in if self.pin <> Enumeration1::unrestricted then Set(Enumeration1){self.pin} else if self.base_NamedElement.owner.oclIsKindOf(UML::Class) then allStereotype1->select(self.base_NamedElement.owner.oclAsType(UML::Class)->includes(base_NamedElement)).val1->asSet() else Set(Enumeration1){Enumeration1::EnumerationLiteral1} endif endif
I had to put a "let" expression to house the "Stereotype2.allInstances()" because when I use that value as an expression I get another problem - which I intend to demonstrate with "val2" property implemented in that way soon.
So looking at the source of the exception Stereotype1Impl.java:464 where the exception is thrown looks like this:
final /*@NonInvalid*/ SetValue BOXED_val1 = idResolver.createSetOfAll(ValidationProblemTables.SET_ENUMid_Enumeration1, val1);
Since the exception said "Unknown enumeration EnumerationLiteral1" it seems the instance is being searched from the name, so I changed it to the following and it seems to work now:
final /*@NonInvalid*/ SetValue BOXED_val1 = ValueUtil.createSetOfEach(ValidationProblemTables.SET_ENUMid_Enumeration1, val1.get(0).toString());
However I'm not happy that the string value is used to look up the instance; I mean it works, but there clearly is a Java generation bug here and I'm not sure if my workaround fix is good enough?
Here is the full function showing comments where I modified it with the workaround:
/**
* <!-- begin-user-doc -->
* <!-- end-user-doc -->
* @generated
*/
@Override
public EList<Enumeration1> getVal1() {
/**
*
* let
* allStereotype1 : Set(ValidationProblem::Stereotype1) = Stereotype1.allInstances()
* in
* if self.pin <> Enumeration1::unrestricted
* then Set{self.pin}
* else
* if self.base_NamedElement.owner.oclIsKindOf(UML::Class)
* then
* allStereotype1->select(
* self.base_NamedElement.owner.oclAsType(UML::Class)
* ->includes(base_NamedElement))
* .val1->asSet()
* else Set{Enumeration1::EnumerationLiteral1}
* endif
* endif
*/
final /*@NonInvalid*/ Executor executor = PivotUtil.getExecutor(this);
final /*@NonInvalid*/ IdResolver idResolver = executor.getIdResolver();
final /*@NonInvalid*/ org.eclipse.ocl.pivot.Class TYP_ValidationProblem_c_c_Stereotype1_0 = idResolver.getClass(ValidationProblemTables.CLSSid_Stereotype1, null);
final /*@NonInvalid*/ SetValue allStereotype1 = ClassifierAllInstancesOperation.INSTANCE.evaluate(executor, ValidationProblemTables.SET_CLSSid_Stereotype1, TYP_ValidationProblem_c_c_Stereotype1_0);
final /*@NonInvalid*/ Enumeration1 pin_0 = this.getPin();
final /*@NonInvalid*/ EnumerationLiteralId BOXED_pin = ValidationProblemTables.ENUMid_Enumeration1.getEnumerationLiteralId(ClassUtil.nonNullState(pin_0.getName()));
final /*@NonInvalid*/ boolean ne = BOXED_pin != ValidationProblemTables.ELITid_unrestricted;
/*@Thrown*/ SetValue symbol_1;
if (ne) {
final /*@NonInvalid*/ SetValue Set = ValueUtil.createSetOfEach(ValidationProblemTables.SET_ENUMid_Enumeration1, pin_0);
symbol_1 = Set;
}
else {
final /*@NonInvalid*/ org.eclipse.ocl.pivot.Class TYP_UML_c_c_Class_0 = idResolver.getClass(ValidationProblemTables.CLSSid_Class_0, null);
final /*@NonInvalid*/ NamedElement base_NamedElement = this.getBase_NamedElement();
if (base_NamedElement == null) {
throw new InvalidValueException("Null source for \'\'http://www.eclipse.org/uml2/5.0.0/UML\'::Element::owner\'");
}
final /*@Thrown*/ Element owner = base_NamedElement.getOwner();
final /*@Thrown*/ boolean oclIsKindOf = OclAnyOclIsKindOfOperation.INSTANCE.evaluate(executor, owner, TYP_UML_c_c_Class_0).booleanValue();
/*@Thrown*/ SetValue symbol_0;
if (oclIsKindOf) {
/*@Thrown*/ Accumulator accumulator = ValueUtil.createSetAccumulatorValue(ValidationProblemTables.SET_CLSSid_Stereotype1);
Iterator<Object> ITERATOR__1 = allStereotype1.iterator();
/*@Thrown*/ SetValue select;
while (true) {
if (!ITERATOR__1.hasNext()) {
select = accumulator;
break;
}
/*@NonInvalid*/ Stereotype1 _1 = (Stereotype1)ITERATOR__1.next();
/**
*
* self.base_NamedElement.owner.oclAsType(UML::Class)
* ->includes(base_NamedElement)
*/
final /*@Thrown*/ org.eclipse.uml2.uml.Class oclAsType = (org.eclipse.uml2.uml.Class)OclAnyOclAsTypeOperation.INSTANCE.evaluate(executor, owner, TYP_UML_c_c_Class_0);
final /*@Thrown*/ SetValue oclAsSet = OclAnyOclAsSetOperation.INSTANCE.evaluate(executor, ValidationProblemTables.SET_CLSSid_Class, oclAsType);
final /*@NonInvalid*/ NamedElement base_NamedElement_1 = _1.getBase_NamedElement();
final /*@Thrown*/ boolean includes = CollectionIncludesOperation.INSTANCE.evaluate(oclAsSet, base_NamedElement_1).booleanValue();
//
if (includes == ValueUtil.TRUE_VALUE) {
accumulator.add(_1);
}
}
/*@Thrown*/ org.eclipse.ocl.pivot.values.BagValue.Accumulator accumulator_0 = ValueUtil.createBagAccumulatorValue(ValidationProblemTables.BAG_ENUMid_Enumeration1);
Iterator<Object> ITERATOR__1_0 = select.iterator();
/*@Thrown*/ BagValue collect;
while (true) {
if (!ITERATOR__1_0.hasNext()) {
collect = accumulator_0;
break;
}
/*@NonInvalid*/ Stereotype1 _1_0 = (Stereotype1)ITERATOR__1_0.next();
/**
* val1
*/
// Build Error -> final /*@NonInvalid*/ List<EnumerationLiteralId> val1 = _1_0.getVal1();
final /*@NonInvalid*/ List<Enumeration1> val1 = _1_0.getVal1();
// Exception thrown -> final /*@NonInvalid*/ SetValue BOXED_val1 = idResolver.createSetOfAll(ValidationProblemTables.SET_ENUMid_Enumeration1, val1);
final /*@NonInvalid*/ SetValue BOXED_val1 = ValueUtil.createSetOfEach(ValidationProblemTables.SET_ENUMid_Enumeration1, val1.get(0).toString());
//
for (Object value : BOXED_val1.flatten().getElements()) {
accumulator_0.add(value);
}
}
final /*@Thrown*/ SetValue asSet = CollectionAsSetOperation.INSTANCE.evaluate(collect);
symbol_0 = asSet;
}
else {
symbol_0 = ValidationProblemTables.Set_1;
}
symbol_1 = symbol_0;
}
// Build Error -> final /*@Thrown*/ List<EnumerationLiteralId> ECORE_symbol_1 = ((IdResolverExtension)idResolver).ecoreValueOfAll(Enumeration1.class, symbol_1);
// Build Error -> return (EList<EnumerationLiteralId>)ECORE_symbol_1;
final /*@Thrown*/ List<Enumeration1> ECORE_symbol_1 = ((IdResolverExtension)idResolver).ecoreValueOfAll(Enumeration1.class, symbol_1);
return (EList<Enumeration1>)ECORE_symbol_1;
}
|
|
| | | | | | |
| Re: Static profile OCL expressions referring to enumeration literals cause "contains a bad valu [message #1837511 is a reply to message #1837508] |
Mon, 01 February 2021 12:05 |
Deniz Eren
Messages: 68
Registered: March 2014 |
Member |
|
|
Hi Edi,
Looking good, the collection issue is fixed!
However, I still get this exception thrown as I've described in this message earlier:
https://www.eclipse.org/forums/index.php?t=msg&th=1106761&goto=1837451&#msg_1837451
The code that throws the exception is this one as outlined in the above message:
/**
* val1
*/
final /*@NonInvalid*/ List<Enumeration1> val1 = _1_0.getVal1();
final /*@NonInvalid*/ SetValue BOXED_val1 = idResolver.createSetOfAll(ValidationProblemTables.SET_ENUMid_Enumeration1, val1);
If I manually change this to the following code it all works:
/**
* val1
*/
final /*@NonInvalid*/ List<Enumeration1> val1 = _1_0.getVal1();
final /*@NonInvalid*/ SetValue BOXED_val1 = ValueUtil.createSetOfEach(ValidationProblemTables.SET_ENUMid_Enumeration1, val1.get(0));
This one is clearly a different bug to the collection issue.
As a side note, I've been using your OCL Java generator with quite complex OCL expression lately and I am quite impressed how well it works! When it comes to this collection issue, I can verify it is now fixed in this version you present. When it comes to this enumeration exception throwing issue, I fix those by hand, and the UnlimitedNatural issue I avoid altogether. Besides these, really complex OCL expressions are working nicely!
What's your view about why this enumeration exception is happening?
Best regards,
Deniz
|
|
| |
| Re: Static profile OCL expressions referring to enumeration literals cause "contains a bad valu [message #1837544 is a reply to message #1837516] |
Tue, 02 February 2021 06:04 |
Deniz Eren
Messages: 68
Registered: March 2014 |
Member |
|
|
Hi Ed,
The generator you have developed is truly brilliant!
It's only human nature to focus on a couple of issue, as they draw the attention of the user upon themselves, however the silent mammoths of working features seamlessly operate and make no noise for us to hear them. Now that I am getting more experience playing with your generator via some really complex OCL expressions, I can really appreciate how truly powerful it is!
I really like Papyrus also, and to me it is the only true graphical modelling tool (being open-source is very important), however it seems to suffer from a handful of really unfortunate user interface issues, which I'm sure can be fixed really easily. What actions would you propose to at least get some Papyrus UI experts to check and comment on some of these sore spots that impact on model development effort?
Besides those Papyrus issues, the static profile development workflow you have recommended to me, using your generator, in the last few weeks is now really efficient. It involves designing the Papyrus profile with embedded OCL expressions inside derived property defaultValue fields, then save and click "No" on the "Would you like to define it?" question - always testing to see if I want to critically break my project :) Simple question to bypass but as you get more and more tired during the night...
Then I reload the genmodel and generate the Model Code - and now thanks to your latest fix I do not need to edit the generated code at all. The example code I gave has that enumeration issue but that was a special case I can develop around.
Another good thing, is that when generating the Model Code any OCL expression errors are reported nicely! Papyrus checks OCL expressions during editing also however with gliches such as:
- Often it says there is an error by giving red underling on the OCL expression, but when you click to other elements and then click back to the OCL expression editor box the error reporting is mysteriously gone!
- Of course when you click back to the OCL expression you need to scroll around horizontally trying to read the OCL expression in the editor because Papyrus loses the nice wrapped display of the OCL expression when you click out of the editor right after creating it!
Once again thank you for all your help and recent fixes, it's truly amazing software you are developing! Also worth mentioning, thanks to your pointers and mentoring, even though I started off as a fairly new user to Papyrus (although familiar with UML) within a couple of weeks only I am now able to design static profiles with serious power.
Best regards,
Deniz
[Updated on: Tue, 02 February 2021 06:05] Report message to a moderator |
|
| | | | | | | | | | | | | | |
Goto Forum:
Current Time: Thu Apr 25 16:46:19 GMT 2024
Powered by FUDForum. Page generated in 0.06562 seconds |
] 
Search
Help
Register
Login
Home
