| Re: Specifying derived values in a UML model [message #1035009] |
Sat, 06 April 2013 07:00 |
 Ed Willink
Messages: 7655
Registered: July 2009 |
Senior Member |
|
|
Hi
[Apologies for the cross-post, but this is perhaps interesting to UML
and Papyrus users. Please reply only to the OCL newsgroup.]
I've just been checking out the use of OCL for Properties.
IMHO A derived property constraint is not semantically distinct from a
class invariant that constrains the member property, so derived
constraints are easily specified as class invariants; just make sure the
Constraint context is the class. (The constrainedElement collection is
potentially redundant and is ignored by MDT/OCL but might be used by
other tools since the specification is very vague here.)
An OCL initial value can be specified in the UML Model Editor by
creation an OCL-languaged OpaqueExpression as the Property's default value.
I've raised https://bugs.eclipse.org/bugs/show_bug.cgi?id=405065 to
remedy the loss of this expression during the UML to Ecore conversion.
I've added a note to
https://bugs.eclipse.org/bugs/show_bug.cgi?id=399249 about the missing
Papyrus support for adding an OpaqueExpression as a Property's default
value.
Currently in MDT/OCL there is complexity as to which of "derivation" or
"initial" settingDelegates should be used when both are present; the
"derivation" is given preference. "derivation" was a mistake and should
not exist, but I suppose for compatibility both will be tolerated
indefinitely.
Regards
Ed Willink
On 04/04/2013 09:13, Klaas Gadeyne wrote:
> Hi,
>
> [I didn't see an option to cross post on the papyrus forum, does it exist?]
>
> I am trying to use MDT/OCL to specify derivation rules for UML properties in a specific UML model. What I've tried so far (all using Kepler nightly build of papyrus and MDT/OCL):
>
> 1/ Specifying the derivation rule directly in the UML model.
> a/ By declaring the property to be read-only and derived, and setting the default value. I don't know whether this is semantically exactly the same as a derivation (bug [url=https://bugs.eclipse.org/bugs/show_bug.cgi?id=382784] has some information on that, which I didn't fully understand). This works fine, although
> * [minor, side note] It is quite cumbersome to do so in Papyrus. You can quite easily create the property value using the embedded "advanced property editor", but the default value is always a literal string. That means that, in order to get an OCL expression there, you need to go to the properties view, delete the LiteralString, create an OpaqueExpression, set the language to OCL. Unfortunately, when typing the OCL expression in there, it seems to get lost, and you need to use the advanced property editor to get the expression finally in there.
> * More interesting: when taking the (plain) UML model and transforming this via the UML2 model editor to ecore, this "default value expression" gets translated into something like this
>
>
> attribute attribute2 : types::Boolean = 'self.myprop = 2' { derived readonly transient volatile };
>
>
> Meaning that the opaque expression is translated into a default value literal in the ecore model, and the link with OCL got completely lost during translation. If setting the default value in UML to an OCL expression would be semantically equivalent to an OCL derivation, then I would guess this is a missing feature of the uml2ecore transformation, right?
>
> b/ By adding an OCL constraint to the UML model via a UML constraint and opaque expression. In this case, this gets translated into (as expected) something like
>
>
> attribute attribute3 : types::Integer { derived readonly transient volatile };
> callable invariant constraint1: self.attribute3 = self.myprop + self.attribute1;
>
>
> So again, no derivation although one could again argue this is a semantically equivalent way of representing things. The problem I see with this approach is that this works fine to express bijective (?) relationships like the sum, but it wouldn't work for an if/then/else derivation IMO?
>
> 2/ Specifying the derivation rule in a CompleteOCL document. Another approach which I tried was to specify the derivation rule in a separate completeOCL document. For this purpose, I tried to start from the completeocltutorial example project and wrote a completeOCL document that looks like
>
> import myumlmodel : 'PapyrusTestFile.uml#/'
>
> context myumlmodel::UPPERCASE::myprop : Integer
> derive: 0
>
> context myumlmodel::UPPERCASE
> inv : myprop = 1
>
>
> I get the exception which is attached to this post (both when loading the completeOCL resource in the graphical papyrus editor and the UML2 editor).
>
> So finally I didn't find a satisfying solution to specify the derived values yet :( Did I forget other possibilities to specify derived values? If not, what would be the best way to move on with this?
>
> TIA,
>
> Klaas
>
|
|
|
Powered by
FUDForum. Page generated in 0.02329 seconds
] 
Search
Help
Register
Login
Home
