Home » Modeling » OCL » OCL and strings
| OCL and strings [message #720018] |
Mon, 29 August 2011 17:13  |
 fafanellu 
Messages: 37
Registered: July 2011 |
Member |
|
|
Hello,
I've got a problem when trying to make a comparison between a class name and the result of an OCL evaluation. I'm using the following classes (I simplified them).
abstract class Type;
class _'String' extends Type;
class _'Integer' extends Type;
abstract class Xpression
{
property is_always_typed : Types::Type[1] { ordered };
}
abstract class LitteralBasicValue extends Xpression;
class StringValue extends LitteralBasicValue
{
attribute str_val : String[1] { ordered };
}
class IntValue extends LitteralBasicValue
{
attribute int_val : ecore::EInt[1] { ordered };
}
What I would like to do is to check that when a LitteralBasicValue is created, both of its attributes match, because if I don't use OCL it would possible, for instance, to create a StringValue with the field is_always_typed set to "Integer". Or an IntValue with the attribute String. And I don't want that.
So, I tried, in the context of an instance of StringValue, to evaluate the type. For instance, self.is_always_typed gives me "String".
But self.is_always_typed='String' or self.is_always_typed=String returns "false" !
How can I solve that ?? Any idea ? Many thanks
Regards
[Updated on: Mon, 29 August 2011 19:55] Report message to a moderator |
|
|
| Re: OCL and strings [message #720087 is a reply to message #720018] |
Mon, 29 August 2011 20:53  |
Ed Willink
Messages: 7655
Registered: July 2009 |
Senior Member |
|
|
Hi
I cannot understand your example; it seems wierd if not outright mad;
but perhaps if you provided more of it, it might make sense.
You give no examples of the (not-a-Boolean) is_always_typed field
initialization, so it is very difficult to diagnose your subsequent
'failures'.
I can just note that you have two different String classes, so that may
be the confusion. Use non-clashing names until you have debugged your
problem.
Regards
Ed Willink
On 29/08/2011 18:13, fafanellu wrote:
> Hello,
> I've got a problem when trying to make a comparison between a class
> name and the result of an OCL evaluation. I'm using the following
> classes (I simplified them).
>
> abstract class Type;
> class _'String' extends Type;
> class _'Integer' extends Type;
>
> abstract class Xpression
> {
> property is_always_typed : Types::Type[1] { ordered };
> }
>
> abstract class LitteralBasicValue extends Xpression;
> class StringValue extends LitteralBasicValue
> {
> attribute str_val : String[1] { ordered };
> }
> class IntValue extends LitteralBasicValue
> {
> attribute int_val : ecore::EInt[1] { ordered };
> }
>
> What I would like to do is to check that when a LitteralBasicValue is
> created, both of its attributes match, because if I don't use OCL it's
> possible, for instance, to create a StringValue with the field
> is_always_typed set to "String". And I don't want that.
>
> So, I tried, in the context of an instance of StringValue, to evaluate
> the type. For instance, self.is_always_typed gives me "String".
> But self.is_always_typed='String' or self.is_always_typed=String
> returns "false" !
>
> How can I solve that ?? Any idea ? Many thanks
>
> Regards
>
|
|
|
| Re: OCL and strings [message #720290 is a reply to message #720087] |
Tue, 30 August 2011 10:23 |
fafanellu
Messages: 37
Registered: July 2011 |
Member |
|
|
Hi, I tried to create another example following your advice about non-clashing names. It works, but just for my example !!! damn !!!! Here is my code :
module _'Help.ecore'
package Help : Help = 'Help'
{
abstract class Type;
class T1 extends Type;
class T2 extends Type;
abstract class Xpression
{
property is_always_typed : Type[1] { ordered };
}
abstract class LitteralBasicValue extends Xpression;
class T1Value extends LitteralBasicValue
{
attribute intitialT1Val : String[1] { ordered };
}
class T2Value extends LitteralBasicValue
{
attribute intitialT2Val : String[1] { ordered };
}
class ModelTest
{
property handles : LitteralBasicValue[+] { ordered composes };
property instanciates_T1 : T1[1] { ordered composes };
property instanciates_T2 : T2[1] { ordered composes };
}
}
First of all, I create a dynamic instance of the ModelTest class, then I instanciate from it T1 and T2 (which can be seen as singletons). After that, still from my instance of ModelTest, I create a LitteralBasicValue, let's say a T1 value. Finally, in the field is_always_typed, I choose T1. But I also could choose T2, so I want to check that the types are correct. That is the purpose of my constraint.
What I wanted to do, was to check if both of the types matched : self.is_always_typed.oclIsTypeOf(T1) must return true. And, damn, now, it does ! But only for my example above !!!
I thought about it, and the only remaining difference with my metamodel is that the singletons T1 and T2 are not instanciated in the ModelTest class...and not located in the same package. But I still can create my LitteraBasicValues and I still can give them a Type with the eReference "is_always_typed".
The OCL interpreter behaves just as if it didn't know the T1 and T2 classes...although I made sure of changing the class names in order to avoid confusion.
self.is_always_typed returns T1
while self.is_always_typed.oclIsTypeOf(T1) returns Unrecognized variable: (T1)
Is there a way to navigate in the hierarchy (above) ? My problem obviously comes from the location and the hierarchy of the classes...how could I solve this ?
Thanks for your help, Edward
[Updated on: Tue, 30 August 2011 11:55] Report message to a moderator |
|
|
| Re: OCL and strings [message #720472 is a reply to message #720290] |
Tue, 30 August 2011 16:36 |
Ed Willink
Messages: 7655
Registered: July 2009 |
Senior Member |
|
|
Hi
You still provide incomplete examples that require much too mucxhj of my
time to redevelop. e.g you provide no code to initialize is_always_typed.
If the problem went away with non-clashing names, that seems to confirm
that you were using the wrong String.
There are lots of ways to navigate the hierarchy, but I'm not sure what
you want to do. Try providing a complete executable example that
demonstrates your best idea.
You may find the Xtext OCL Console more accurate. It also has hover text
feedback.
Regards
Ed Willink
On 30/08/2011 11:23, fafanellu wrote:
> Hi, I tried to create another example following your advice about
> non-clashing names. It works, but just for my example !!! damn !!!!
> Here is my code :
>
> module _'Help.ecore'
> package Help : Help = 'Help'
> {
> abstract class Type;
> class T1 extends Type;
> class T2 extends Type;
> abstract class Xpression
> {
> property is_always_typed : Type[1] { ordered };
> }
> abstract class LitteralBasicValue extends Xpression;
> class T1Value extends LitteralBasicValue
> {
> attribute intitialT1Val : String[1] { ordered };
> }
> class T2Value extends LitteralBasicValue
> {
> attribute intitialT2Val : String[1] { ordered };
> }
> class ModelTest
> {
> property handles : LitteralBasicValue[+] { ordered composes };
> property instanciates_T1 : T1[1] { ordered composes };
> property instanciates_T2 : T2[1] { ordered composes };
> }
> }
>
> First of all, I create a dynamic instance of the ModelTest class, then
> I instanciate from it T1 and T2 (which can be seen as singletons).
> Then, still from my instance of ModelTest, I create a
> LitteralBasicValue, let's say a T1 value. In the field
> is_always_typed, I choose T1. But I also could choose T2, so I want to
> check that the types are correct. THat is the purpose of my constraint.
>
> What I wanted to do, was to check if both of the types matched :
> self.is_always_typed.oclIsTypeOf(T1) must return true. And, damn, now,
> it does ! But only for my example above !!!
>
> I thought about it, and the only difference with my metamodel is that
> the singletons T1 and T2 are not instanciated in the ModelTest
> class...and not located in the same package. But I still can create my
> LitteraBasicValues and I still can give them a Type with the
> eReference "is_always_typed".
> The OCL interpreter behaves just as if it didn't know the T1 and T2
> classes...
> self.is_always_typed returns T1
> while self.is_always_typed.oclIsTypeOf(T1) returns Unrecognized
> variable: (T1)
>
> Is there a way to navigate in the hierarchy, but above ?Thanks for
> your help
|
|
|
| Re: OCL and strings [message #720512 is a reply to message #720472] |
Tue, 30 August 2011 18:21 |
fafanellu
Messages: 37
Registered: July 2011 |
Member |
|
|
In fact, is_always_typed is used to handle the type.
I tried to create another example where my problem appears. I used packages. It works well when I copy paste it in a new folder.
module _'Help.ecore'
package Help : Help = 'Help'
{
package Types : Types = 'Help/Types'
{
abstract class Type;
class T1 extends Type;
class T2 extends Type;
}
package Xpressions : Xpressions = 'Help/Xpressions'
{
abstract class Xpression
{
property is_always_typed : Types::Type[1] { ordered };
}
abstract class LitteralBasicValue extends Xpression;
class T1Value extends LitteralBasicValue
{
attribute intitialT1Val : String[1] { ordered };
}
class T2Value extends LitteralBasicValue
{
attribute intitialT2Val : String[1] { ordered };
}
}
package Model : Model = 'Help/Model'
{
class ModelTest
{
property handles : Xpressions::LitteralBasicValue[+] { ordered composes };
property instanciates_once_T1 : Types::T1[1] { ordered composes };
property instanciates_once_T2 : Types::T2[1] { ordered composes };
}
}
}
The file in attachment shows it in a graphical way (help.jpg).
Here are the steps for creating the model :
1) Create a dynamic instance of ModelTest. It will be named ModelTest.xmi, that's perfect.
2) From this dynamic instance, right click, choose new child and instanciates_once_T1. A new child will be created : T1
3) Repeat the same operation for T2.
4) Now, right click again on the ModelTest instance, choose new child and click on handles_T1_value (for instance)
5) Left click on the new value created, give it a string as an initial value, then give it a T2 type (the proposed types are T1 and T2)
6) The file help_dynamic_instance.jpg shows what we have just done
7) Here we are ! I have an instance of T1 value which field is_always_typed is set to T2. That is a problem ! For further purpose, I need to add a constraint to the LitteralBasicValues I create, in order to check :
- If I instanciate a T1 value, I want to check if its fiels is_always_typed is set to T1
- If I instanciate a T2 value, I want to check if its fiels is_always_typed is set to T2
In the OCL editor, when I am in the T1_value context, I get this :
Evaluating:
self.is_always_typed
Results:
T2
and that :
Evaluating:
self.is_always_typed.oclIsTypeOf(T2)
Results:
Unrecognized variable: (T2)
Evaluating:
self.is_always_typed.oclIsTypeOf(T1)
Results:
Unrecognized variable: (T1)
So, I can't check anything ...
If I didn't use packages, it would have worked, as I said in my previous post. But now, T2 seems to be unknown. What can I do to solve this ?
I hope it was more clear, and you could understand what I meant. Thanks for your help !
[Updated on: Tue, 30 August 2011 18:27] Report message to a moderator |
|
|
| Re: OCL and strings [message #720554 is a reply to message #720512] |
Tue, 30 August 2011 19:45 |
Ed Willink
Messages: 7655
Registered: July 2009 |
Senior Member |
|
|
Hi
> 6) The file help_dynamic_instance.jpg shows what we have just done
Providing ModelTest.xmi would have save me some time and you some
typing. A jpg is large and very limiting.
> 7) Here we are ! I have an instance of T1 value which field is_always_typed is set to T2. That is a problem ! For further purpose, I need to add a constraint to the LitteralBasicValues I create, in order to check :
> - If I instanciate a T1 value, I want to check if its fiels is_always_typed is set to T1
> - If I instanciate a T2 value, I want to check if its fiels is_always_typed is set to T2
This is mad. Why force duplication when a derived property can compute
it right in the first place?
Because it doesn't work.
a) you have confused meta-levels. T1 is a type-valued expression;
is_always_typed : Types::Type[1] requires a type instance.
b) OMG OCL does not support type-valued expressions in general contexts
c) Eclipse OCL should support this but it doesn't seem to work yet
- M1 has a fix that allows Types::T1 to be persisted but
Bug 356243 provides some things for me to solve in
property is_always_typed : Classifier<Types::Type> { ordered }
{
derivation: Types::T1;
}
should work
> 8) In the OCL editor, when I am in the T1_value context, I get this :
No. In the OCL Console after selecting Model Test/T1 Value.
>
> Evaluating:
> self.is_always_typed
> Results:
> T2
>
> and that :
>
> Evaluating:
> self.is_always_typed.oclIsTypeOf(T2)
> Results:
> Unrecognized variable: (T2)
As I wrote before, the Xtext OCL Console is more accurate.
Evaluating:
self.is_always_typed.oclIsTypeOf(T2)
Results:
Parsing failure
null
Unresolved property 'T2' for 'help.ecore::Help::Types::Type'
> If I didn't use packages, it would have worked, as shown in my previous post. But now, T2 seems to be unknown. What can I do to solve this ?
No. If you use packages consistently it does work.
Evaluating:
self.is_always_typed.oclIsTypeOf(Types::T2)
Results:
true
>
> I hope it was more clear, and you could understand what I meant. Thanks for your help !
You have moved from having trouble with the built-in 'String' name to
the built-in 'T2' name.
The old OCL code uses T, T1 and T2 values as magic types as indicated by
the OCL 2.3 specification.
The new OCL code for the Xtext-based editors implements generics so
there is no built-in T, T1, T2; just template parameters like Java. This
prototypes what might be in OCL 2.4.
Regards
Ed Willink
|
|
|
| Re: OCL and strings [message #720878 is a reply to message #720554] |
Wed, 31 August 2011 12:29 |
fafanellu
Messages: 37
Registered: July 2011 |
Member |
|
|
>Providing ModelTest.xmi would have save me some time and you some
>typing. A jpg is large and very limiting.
I'm sorry, I should have sent the .xmi too!
>This is mad. Why force duplication when a derived property can compute
>it right in the first place?
Because the Xpression abstract class has other sub-classes which are not represented in my example, and I don't have any method in my metamodel. I avoid using them as I generate code...because they brought me some problems. But I've read that with OCL it was posible to specify derivated attributes. Maybe I should try this out anyway...with something like :
context Xpression::is_always_typed: Type
derive : self .is_always_typed = ??
It's not easy for me to chose the context...maybe I must ust the TxValues context in order to specify for each one a derived attribute ?
>Because it doesn't work.
>a) you have confused meta-levels. T1 is a type-valued expression;
I'm sorry, I don't understand...What do you mean by type-valued expression ?
>is_always_typed : Types::Type[1] requires a type instance.
Yes, a kind of singleton instanciated only one time (T1 and T2 are those singletons)
>property is_always_typed : Classifier<Types::Type> { ordered }
>{
>derivation: Types::T1;
>}
>should work
It doesn't, Classifier is an "unresolved type". Strange !!
What's the purpose of derivation: Types::T1; in the abstract class Xpression? Is it the same thing I tried to do above (derivation of is_always_typed)?
>As I wrote before, the Xtext OCL Console is more accurate.
Yes, I'll use it, even if it doesn't provide self completion yet, it gives more information on the problem, but...
>Evaluating:
>self.is_always_typed.oclIsTypeOf(Types::T2)
>Results:
>true
It works for me too, but only in the OCL Console, not in the OCL Xtext Console...I don't know what happened, but here is what I get with the Xtext Console :
Evaluating:
self.is_always_typed.oclIsTypeOf(Types::T2)
Results:
Parsing failure
null
Unresolved Namespace 'Types'
Unresolved property 'is_always_typed' for 'unknown-type'
Unresolved operation 'oclIsTypeOf' for 'unknown-type' and 'Types::T2'
Unresolved property 'T2' for 'unknown-type'
I'm though trying to integrate it as a constraint in the metamodel, of the type :
class T1Value extends LitteralBasicValue
{
invariant T1Constraint : self.is_always_typed.oclIsTypeOf(Types::T1);
attribute intitialT1Val : String[1] { ordered };
}
but when trying to validate the ModelTest.xmi, I'm sent an error :
An exception occurred while delegating evaluation of the 'T1Constraint' constraint on 'T1 Value blablabla': Errors in 'self.is_always_typed.oclIsTypeOf(T1)' Unresolved property 'T1' for 'Help.ecore::Help::Types::Type' ModelTest.xmi /Help/model Unknown EMF Problem
Strange...!
Anyway, thank you very much for your kind help, I really appreciate it. Here is the .xmi file I'm using :
<?xml version="1.0" encoding="ASCII"?>
<Model:ModelTest xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:Model="Help/Model" xmlns:Xpressions="Help/Xpressions" xsi:schemaLocation="Help/Model Help.ecore#//Model Help/Xpressions Help.ecore#//Xpressions">
<handles xsi:type="Xpressions:T1Value" is_always_typed="//@instanciates_once_T1" intitialT1Val="blablabla"/>
<instanciates_once_T1/>
<instanciates_once_T2/>
</Model:ModelTest>
[Updated on: Wed, 31 August 2011 13:28] Report message to a moderator |
|
|
| Re: OCL and strings [message #721009 is a reply to message #720878] |
Wed, 31 August 2011 16:31 |
Ed Willink
Messages: 7655
Registered: July 2009 |
Senior Member |
|
|
Hi
> Because the Xpression abstract class has other sub-classes which are
> not represented in my example, and I don't have any method in my
> metamodel. I avoid using them as I generate code...because they
> brought me some problems. A derived attribute is usually computed
> using a method, right? Maybe I should try this out anyway
Overloaded derived attributes are a bit suspect. Overloaded operations
are much more conventional.
>> property is_always_typed : Classifier<Types::Type> { ordered }
>> {
>> derivation: Types::T1;
>> }
>> should work
> It doesn't, Classifier is an "unresolved type". Strange !!
Which is what I wrote. I need to fix it.
Classifier<T> is the type preserving replacement for the return from
oclType().
> What's the purpose of derivation: Types::T1; in the abstract class
> Xpression? How does it work ?
Types::T1 is a type expression whose value is the Types::T1 class.
derivation: Types::T1 defines the derived value of the derived property.
>
>> As I wrote before, the Xtext OCL Console is more accurate.
> Yes, I'll use it, even if it doesn't provide self completion yet, it
> gives more information on the problem
>
>> Evaluating:
>> self.is_always_typed.oclIsTypeOf(Types::T2)
>> Results:
>> true
> It works for me too, but only in the OCL Console, not in the OCL Xtext
> Console...I don't know what happened, but here is what I get with the
> Xtext Console :
>
> Evaluating:
> self.is_always_typed.oclIsTypeOf(Types::T2)
> Results:
> Parsing failure
> null
> Unresolved Namespace 'Types'
> Unresolved property 'is_always_typed' for 'unknown-type'
> Unresolved operation 'oclIsTypeOf' for 'unknown-type' and 'Types::T2'
> Unresolved property 'T2' for 'unknown-type'
>
This is the bug fixed in M1 that I referred to.
Regards
Ed Willink
|
|
|
| Re: OCL and strings [message #721188 is a reply to message #721009] |
Thu, 01 September 2011 06:59 |
fafanellu
Messages: 37
Registered: July 2011 |
Member |
|
|
I'm sorry if my examples were not very clear, but I try to simplify as much as I can the metamodel I'm working on, which has about 30 classes. I needed to redefine basic types, because in my metamodel there are litteral and also complex expressions which both inheritate from Xpression, and even complex expressions have a type, so I found this solution to keep control on the types.
>Overloaded derived attributes are a bit suspect. Overloaded operations
>are much more conventional.
I agree !
>Types::T1 is a type expression whose value is the Types::T1 class.
>derivation: Types::T1 defines the derived value of the derived property.
Thank you for your explanation, I understand now
>This is the bug fixed in M1 that I referred to
What is M1? Do you mean M1 level (model level, with OCL console)?
So, when trying to add to my example metamodel constraints like :
invariant : self.is_always_typed.oclType()=Types::T1;
invariant : self.is_always_typed.oclIsTypeOf(Types::T1); ,
I always manage to validate the dynamic instance, I never get any error, even if I create a LitteralBasicValue T1Value which is_always_typed T2.
The constaints don't seem to be evaluated at all. I don't know what to do, maybe using classic attributes instead of eReferences...
In your opinion what should I do to solve my problem ?
Thank you again for yourhelp and your explanations !
[Updated on: Thu, 01 September 2011 07:00] Report message to a moderator |
|
|
| Re: OCL and strings [message #721232 is a reply to message #721188] |
Thu, 01 September 2011 08:34 |
Ed Willink
Messages: 7655
Registered: July 2009 |
Senior Member |
|
|
Hi
>> This is the bug fixed in M1 that I referred to
> What is M1? Do you mean M1 level (model level, with OCL console)?
Sorry, that could be confusing.
Eclipse development proceeds based on milestones M1,2,3,4,5,6,7 then
Release candidates RC1,2,3,4,5 the Release then Servive Releases.
So the bug is fixed on Eclipse OCL 3.2.0M1.
>
> So, when trying to add to my example metamodel constraints like :
> invariant : self.is_always_typed.oclType()=Types::T1;
> invariant : self.is_always_typed.oclIsTypeOf(Types::T1); ,
> I always manage to validate the dynamic instance, I never get any
> error, even if I create a LitteralBasicValue T1Value which
> is_always_typed T2.
>
> The constaints don't seem to be evaluated at all. I don't know what to
> do, maybe using classic attributes instead of eReferences... In your
> opinion what should I do to solve my problem ?
>
> Thank you again for yourhelp and your explanations !
Because of the bug, I don't think it can work.
You may have to resort to do what the specification does
self.is_always_typed.oclType().name='T1'
Regards
Ed Willink
|
|
|
| Re: OCL and strings [message #721308 is a reply to message #721232] |
Thu, 01 September 2011 12:20 |
fafanellu
Messages: 37
Registered: July 2011 |
Member |
|
|
>Sorry, that could be confusing.
>Eclipse development proceeds based on milestones M1,2,3,4,5,6,7 then
>Release candidates RC1,2,3,4,5 the Release then Servive Releases.
>So the bug is fixed on Eclipse OCL 3.2.0M1.
wow, I didn't know that ! So, I'll try to get the latest version. Is it available as usual, as explained in the OCLinEcore tutorial ?
>You may have to resort to do what the specification does
>self.is_always_typed.oclType().name='T1'
With this constraint added to the metamodel, I always manage to validate the dynamic instance whithout any error (as I did for self.is_always_typed.oclType()=Types::T1 and self.is_always_typed.oclIsTypeOf(Types::T2)).
But when I test it with the OCL Xtext Console, I always get "false" !
I created a T1Value, here is what I get :
Evaluating:
self.is_always_typed.oclType().name='T1'
Results:
false
Evaluating:
self.is_always_typed.oclType().name='T2'
Results:
false
I tried this, in order to show what type was returned !
Evaluating:
self.is_always_typed.oclType()
Results:
Classifier<T>
So, I understood why it always returned false. Classifier<T> can be seen here as you said as the type preserving replacement for the return from oclType(), which means a kind of generic type returned in order to avoid errors?
I also tried this :
Evaluating:
self.is_always_typed.oclType().name
Results:
'T'
That is weird ! Maybe an error due to the numbers in my class names (with nbumbers) ?
Nope, I've just tried to change the names "TOne" and "TTwo", the dynamic instance is still validated in all cases, and I still get :
Evaluating:
self.is_always_typed.oclType().name
Results:
'T'
I'll try to find another way to solve this, maybe downloading the latest version as you told me 
I'm now trying to perform a M2M mapping, maybe I'll re-post a message here very soon to fix some troobleshooting =)
Thanks again Ed, have a good day !
Stéphane
[Updated on: Thu, 01 September 2011 14:42] Report message to a moderator |
|
|
| Re: OCL and strings [message #721423 is a reply to message #721308] |
Thu, 01 September 2011 17:41 |
Ed Willink
Messages: 7655
Registered: July 2009 |
Senior Member |
|
|
Hi
>> So the bug is fixed on Eclipse OCL 3.2.0M1.
> wow, I didn't know that ! So, I'll try to get the latest version. Is
> it available as usual, as explained in the OCLinEcore tutorial ?
>
The milestone builds are for enthusiasts and developers. M1,2,3 can be a
little unstable before discipline gradually improves towards the
release. New APIs may change up until M6. If you want a stable
oroduction environment don't touch them. If you are happy to assist in
testing and provide feedback then go for it.
Beware that the build system imposes some unwanted minimum versions so
OCL 3.2.0M1 won't install on Indigo. You need to start by downloading
the Juno platform, then you can use the M1 updates.
>> You may have to resort to do what the specification does
>> self.is_always_typed.oclType().name='T1'
>
> With this constraint added to the metamodel, I always manage to
> validate the dynamic instance whithout any error (as I did for
> self.is_always_typed.oclType()=Types::T1 and
> self.is_always_typed.oclIsTypeOf(Types::T1)).
> But when I test it with the OCL Xtext Console, I always get "false" !
> I created a T1Value, here is what I get :
>
> Evaluating:
> self.is_always_typed.oclType().name='T1'
> Results:
> false
>
> Evaluating:
> self.is_always_typed.oclType().name='T2'
> Results:
> false
>
> That is weird ! I'll try to find another way to solve this, maybe
> downloading the latest version as you told me :)
Wierd. What does self.is_always_typed.oclType().name give?
Regards
Ed Willink
|
|
| | | | |
Goto Forum:
Current Time: Thu Apr 25 16:18:29 GMT 2024
Powered by FUDForum. Page generated in 0.03968 seconds |
] 
Search
Help
Register
Login
Home
