Home » Modeling » OCL » Using 'literal value' elements in OCL expressions
| | |
Re: Using 'literal value' elements in OCL expressions [message #1327615 is a reply to message #1283586] |
Fri, 02 May 2014 08:43 |
Felix Dorner Messages: 295 Registered: March 2012 |
Senior Member |
|
|
Hey Ed,
On 03/04/2014 17:39, Ed Willink wrote:
> Hi
>
> 'somewhere in my model ' is not a good place.
>
> UML models use Properties to host values by name within a Namespace
> hierarchy, so you should probably create a Class called e.g.
> GlobalConstants with a read-only (static) Property called MY_LITERAL.
>
If the user doesn't want to modify the model (let's not talk about that
...), do you think this would work:
I inject classifiers/static properties into the pivot representation:
For a given value defined in namespace some::prefix::MY_VALUE, I inject
a classifier 'some::prefix', with a static property 'MY_VALUE'. If
there's already a classifier with that qualified name, I just add the
property. If the property already exists, there's a conflict but I'll
just diss that case.
Objections?
In general, we were a bit surprised that UML offers a way to model a
value, yet there's no way to access that value in an OCL expression.
Felix
|
|
|
Re: Using 'literal value' elements in OCL expressions [message #1327683 is a reply to message #1327615] |
Fri, 02 May 2014 09:25 |
Ed Willink Messages: 7670 Registered: July 2009 |
Senior Member |
|
|
Hi
You have not yet explained where in your model you have a literal that
should be accessible but is not accessible.
You don't want to change your model but you are prepared to inject
things into it.
You seem to ignore my suggestion for static properties.
I'm very confused and so obviously cannot help.
Regards
Ed
On 02/05/2014 09:43, Felix Dorner wrote:
> Hey Ed,
>
> On 03/04/2014 17:39, Ed Willink wrote:
>> Hi
>>
>> 'somewhere in my model ' is not a good place.
>>
>> UML models use Properties to host values by name within a Namespace
>> hierarchy, so you should probably create a Class called e.g.
>> GlobalConstants with a read-only (static) Property called MY_LITERAL.
>>
>
> If the user doesn't want to modify the model (let's not talk about
> that ...), do you think this would work:
>
> I inject classifiers/static properties into the pivot representation:
>
> For a given value defined in namespace some::prefix::MY_VALUE, I
> inject a classifier 'some::prefix', with a static property 'MY_VALUE'.
> If there's already a classifier with that qualified name, I just add
> the property. If the property already exists, there's a conflict but
> I'll just diss that case.
>
> Objections?
>
> In general, we were a bit surprised that UML offers a way to model a
> value, yet there's no way to access that value in an OCL expression.
>
>
>
> Felix
|
|
|
Re: Using 'literal value' elements in OCL expressions [message #1327747 is a reply to message #1327683] |
Fri, 02 May 2014 10:10 |
Felix Dorner Messages: 295 Registered: March 2012 |
Senior Member |
|
|
On 02/05/2014 11:25, Ed Willink wrote:
> You have not yet explained where in your model you have a literal that
> should be accessible but is not accessible.
Yes, sorry. I attached a papyrus screenshot with a trivial example.
Package A contains a 'LiteralInteger' element. Sibling package B
contains a class 'Adult' with an Integer typed property 'age'. I would
like to say in OCL:
context Adult
self.age > A::MIN_AGE
From your first reply, I understand that this is not possible.
> You don't want to change your model but you are prepared to inject
> things into it.
Only into the pivot presentation. The source model will stay untouched.
> You seem to ignore my suggestion for static properties.
I love your suggestion, but the client doesn't want to change its
models. I don't want to bite the feeding hand and look for a 'workaround'.
That's why I want to add these fake classifiers with static properties
into the pivot representation. LiteralValues in the UML model would then
be accessible using static classifier property syntax, like the one above.
Hope things are more clear now.
Felix
>
>
> On 02/05/2014 09:43, Felix Dorner wrote:
>> Hey Ed,
>>
>> On 03/04/2014 17:39, Ed Willink wrote:
>>> Hi
>>>
>>> 'somewhere in my model ' is not a good place.
>>>
>>> UML models use Properties to host values by name within a Namespace
>>> hierarchy, so you should probably create a Class called e.g.
>>> GlobalConstants with a read-only (static) Property called MY_LITERAL.
>>>
>>
>> If the user doesn't want to modify the model (let's not talk about
>> that ...), do you think this would work:
>>
>> I inject classifiers/static properties into the pivot representation:
>>
>> For a given value defined in namespace some::prefix::MY_VALUE, I
>> inject a classifier 'some::prefix', with a static property 'MY_VALUE'.
>> If there's already a classifier with that qualified name, I just add
>> the property. If the property already exists, there's a conflict but
>> I'll just diss that case.
>>
>> Objections?
>>
>> In general, we were a bit surprised that UML offers a way to model a
>> value, yet there's no way to access that value in an OCL expression.
>>
>>
>>
>> Felix
>
-
Attachment: literal.png
(Size: 4.58KB, Downloaded 200 times)
|
|
|
Re: Using 'literal value' elements in OCL expressions [message #1327803 is a reply to message #1327747] |
Fri, 02 May 2014 10:46 |
Ed Willink Messages: 7670 Registered: July 2009 |
Senior Member |
|
|
Hi
For a name to be visible it must be in a namespace, such as a property
in a class or a class in a package. You can't just put junk anywhere and
expect that the 'name' property has your semantics.
Why can't you put your global constrants in a global package in a global
model. No need to chnage anything?
Regards
Ed Willink
On 02/05/2014 11:10, Felix Dorner wrote:
> On 02/05/2014 11:25, Ed Willink wrote:
>
>> You have not yet explained where in your model you have a literal that
>> should be accessible but is not accessible.
>
> Yes, sorry. I attached a papyrus screenshot with a trivial example.
> Package A contains a 'LiteralInteger' element. Sibling package B
> contains a class 'Adult' with an Integer typed property 'age'. I would
> like to say in OCL:
>
> context Adult
> self.age > A::MIN_AGE
>
> From your first reply, I understand that this is not possible.
>
>> You don't want to change your model but you are prepared to inject
>> things into it.
>
> Only into the pivot presentation. The source model will stay untouched.
>
>> You seem to ignore my suggestion for static properties.
>
> I love your suggestion, but the client doesn't want to change its
> models. I don't want to bite the feeding hand and look for a
> 'workaround'.
>
> That's why I want to add these fake classifiers with static properties
> into the pivot representation. LiteralValues in the UML model would
> then be accessible using static classifier property syntax, like the
> one above.
>
> Hope things are more clear now.
>
> Felix
>>
>>
>> On 02/05/2014 09:43, Felix Dorner wrote:
>>> Hey Ed,
>>>
>>> On 03/04/2014 17:39, Ed Willink wrote:
>>>> Hi
>>>>
>>>> 'somewhere in my model ' is not a good place.
>>>>
>>>> UML models use Properties to host values by name within a Namespace
>>>> hierarchy, so you should probably create a Class called e.g.
>>>> GlobalConstants with a read-only (static) Property called MY_LITERAL.
>>>>
>>>
>>> If the user doesn't want to modify the model (let's not talk about
>>> that ...), do you think this would work:
>>>
>>> I inject classifiers/static properties into the pivot representation:
>>>
>>> For a given value defined in namespace some::prefix::MY_VALUE, I
>>> inject a classifier 'some::prefix', with a static property 'MY_VALUE'.
>>> If there's already a classifier with that qualified name, I just add
>>> the property. If the property already exists, there's a conflict but
>>> I'll just diss that case.
>>>
>>> Objections?
>>>
>>> In general, we were a bit surprised that UML offers a way to model a
>>> value, yet there's no way to access that value in an OCL expression.
>>>
>>>
>>>
>>> Felix
>>
>
|
|
|
Goto Forum:
Current Time: Tue Sep 24 12:18:45 GMT 2024
Powered by FUDForum. Page generated in 0.03651 seconds
|