Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » OCL » About adding new predefined propertys
About adding new predefined propertys [message #24171] Mon, 21 May 2007 08:42 Go to next message
Eclipse User
Originally posted by: alu2526.etsii.ull.es

Hi,

Im working in a Operational Mapping (QVT Standard) Parser and im extending
your work (LPG Grammars, Environments, etc), in order to avoid implementing
all OCL Expressions referred part,

Actually, im using ocl.ecore project (OCLEcore.ecore, EcoreEnvironments,
etc): my OM metamodel references OCLEcore metamodel, my OMEnvironments
extend EcoreEnvironment...

Well, im trying to support (in the sematic analisys) some new generic
operations in the same way that OCL supports generic operation as
oclIsKindOf, oclIsTypeOf. If im right, this operations are given by
oclOperations method of AnyType. I have realized that you use an
OCLStandardLibraryImpl (a final class :( ) and a oclstdlib.ecore metamodel
in order to manage this kind of things, but should i reimplement ( this
Library (creating a new OMStandardLibraryImpl) and create a new omstdlib
metamodel (with the new operations) to get this ?
Re: About adding new predefined propertys [message #24298 is a reply to message #24171] Tue, 22 May 2007 11:42 Go to previous messageGo to next message
Eclipse User
Originally posted by: cdamus.ca.ibm.com

Hi, Adolfo,

You shouldn't need to extend the standard library or to provide a
replacement for it. OCL already allows users to define additional
operations and attributes on any type, even the "standard" OCL types.

Have a look in the "Customizing the Environment" topic in the "Advanced
Topics" of the OCL help book (in the 1.1 M7 build) for a detailed example
of how to do this. The example actually adds an operation to the String
type, which is pre-defined by OCL. Since you already have a custom
OMEnvironment, it should be straight-forward.

Of course, if QVT actually specifies that the OCL Standard Library, as
defined in Chapter 11 of the OCL spec, is extended, then you would need to
provide your own QVT library model that replicates all of the OCL library.
If you were using UML as your meta-model, instead of Ecore, then UML's
package merge capability might have provided a solution ...

HTH,

Christian


Adolfo S�chez-Barbudo Herrera wrote:

> Hi,
>
> Im working in a Operational Mapping (QVT Standard) Parser and im extending
> your work (LPG Grammars, Environments, etc), in order to avoid
> implementing all OCL Expressions referred part,
>
> Actually, im using ocl.ecore project (OCLEcore.ecore, EcoreEnvironments,
> etc): my OM metamodel references OCLEcore metamodel, my OMEnvironments
> extend EcoreEnvironment...
>
> Well, im trying to support (in the sematic analisys) some new generic
> operations in the same way that OCL supports generic operation as
> oclIsKindOf, oclIsTypeOf. If im right, this operations are given by
> oclOperations method of AnyType. I have realized that you use an
> OCLStandardLibraryImpl (a final class :( ) and a oclstdlib.ecore metamodel
> in order to manage this kind of things, but should i reimplement ( this
> Library (creating a new OMStandardLibraryImpl) and create a new omstdlib
> metamodel (with the new operations) to get this ?
>
> I want to support the ocl operations and include some new one.
>
> Could you give me any guide or help?
Re: About adding new predefined propertys [message #24420 is a reply to message #24298] Wed, 23 May 2007 04:34 Go to previous messageGo to next message
Eclipse User
Originally posted by: alu2526.etsii.ull.es

Hi for the Help Christian,

I have taken a provisional solution, that consisted in adding dinamically
the operation to the oclAny shadow class (oclstdlib metamodel) when i create
my root Environment
EClassifier oclAny = getOCLStandardLibrary().getOclAny();
EClass shadowClass = (EClass)
oclAny.getEPackage().getEClassifier(oclAny.getName() + "_Class");
shadowClass.getEOperations().add(operation);

Anyway, I suppose that i'll finally implement Operational Mapping
StandardLibrary.

Some comments about types:

For example when lookingup operations, eventually you use
TypeUtil.getOperation() method who have to return the operations accesible
by the type. I dont understand why you have the anytype operations added at
the end of if-then sequence of type's verification. As i understand from
the OCL specification, all the types except collection and tuple types are
AnyTypes. So, for example, a StringType is a PrimitiveType (PredefinedType)
and a AnyType. Perhaps wouldn't it be better having at the end of the method
a verification that if its not Collection or Tuple Types, then you have to
add the oclAny operations?. Besides, you would only have olcXXXXX operations
defined in the AnyType shadowClass (in oclstdlib metamodel) and you wouldnt
need to define them in all the predefined types, as actually you have.



The semantic

"Christian W. Damus" <cdamus@ca.ibm.com> escribi
Re: About adding new predefined propertys [message #24502 is a reply to message #24420] Wed, 23 May 2007 12:15 Go to previous messageGo to next message
Eclipse User
Originally posted by: cdamus.ca.ibm.com

Hi, Adolfo,

See some replies, in-line, below.

Cheers,

Christian


Adolfo S�chez-Barbudo Herrera wrote:

> Hi for the Help Christian,
>
> I have taken a provisional solution, that consisted in adding dinamically
> the operation to the oclAny shadow class (oclstdlib metamodel) when i
> create my root Environment
> EClassifier oclAny = getOCLStandardLibrary().getOclAny();
> EClass shadowClass = (EClass)
> oclAny.getEPackage().getEClassifier(oclAny.getName() + "_Class");
> shadowClass.getEOperations().add(operation);

That sounds like it should work. The only concern I would have is that, in
the Ecore binding at least, *all* EcoreEnvironments will see the features
that you have added to OclAny. The oclstdlib.ecore model is only loaded
once (a singleton). If you take the approach that I suggested, then your
additional features will reside only in each distinct environment instance,
not in the shared standard library resource.


> Anyway, I suppose that i'll finally implement Operational Mapping
> StandardLibrary.
>
> Some comments about types:
>
> For example when lookingup operations, eventually you use
> TypeUtil.getOperation() method who have to return the operations accesible
> by the type. I dont understand why you have the anytype operations added
> at
> the end of if-then sequence of type's verification. As i understand from
> the OCL specification, all the types except collection and tuple types are
> AnyTypes. So, for example, a StringType is a PrimitiveType
> (PredefinedType) and a AnyType. Perhaps wouldn't it be better having at
> the end of the method a verification that if its not Collection or Tuple
> Types, then you have to add the oclAny operations?. Besides, you would
> only have olcXXXXX operations defined in the AnyType shadowClass (in
> oclstdlib metamodel) and you wouldnt need to define them in all the
> predefined types, as actually you have.

I think you may have misread the getOperations() method. It relies on the
OCL predefined types knowing all of their applicable operations, which is
why they are completely specified in the oclstdlib.ecore model. The OclAny
operations are only appended to the result for types in the user's model.
This is necessary because the OCL parser doesn't actually change the
inheritance relationships of these user types.


>
>
> The semantic

What were you going to say? ;-)


> "Christian W. Damus" <cdamus@ca.ibm.com> escribi en el mensaje
> news:f2v30d$qlg$1@build.eclipse.org...

<snip>
Re: About adding new predefined propertys [message #24852 is a reply to message #24502] Mon, 28 May 2007 03:50 Go to previous messageGo to next message
Eclipse User
Originally posted by: alu2526.etsii.ull.es

Hi Christian,

And thank you for your replies and patience ;)

'The semantic' was a missplaced word :-).

I'll write some more replies

> That sounds like it should work. The only concern I would have is that,
> in
> the Ecore binding at least, *all* EcoreEnvironments will see the features
> that you have added to OclAny. The oclstdlib.ecore model is only loaded
> once (a singleton). If you take the approach that I suggested, then your
> additional features will reside only in each distinct environment
> instance,
> not in the shared standard library resource.

Well, as i said you yesterday i 'll need to implement my own
OMStandardLibreary, because OM has some new predefined Types and new
operations referred to them or some considerations about the
OCLStandardLibrary.

> I think you may have misread the getOperations() method. It relies on the
> OCL predefined types knowing all of their applicable operations, which is
> why they are completely specified in the oclstdlib.ecore model. The
> OclAny
> operations are only appended to the result for types in the user's model.
> This is necessary because the OCL parser doesn't actually change the
> inheritance relationships of these user types.

Thanks for the aclaration, i was missing that predefinedType is the base of
all the oclTypes (including AnyType for example). Anyway, we are having the
same problem that i wanted to explain you. I'll try it with other words, but
as you might have noticed im not a good english language user :P.

Well, I was a little shocked when i saw that in all predefinedType's shadow
classes (Except CollectionTypes and TupleTypes as the specification says) of
oclstdlib metamodel, you had defined all the AnyType operations. So I
suppose that the only use in the AnyType predefinedType is adding AnyType
operations to the user model types. I think that you should also use AnyType
in order to avoid defining all these operations in every predefined type
(excluding collection and tupleType of course) we could have.

For example, in the method getOperations we are talking about:

if (TypeType) {
....
}
else
if (PredefinedType) {
.....
}
else {
// user model types
.....
}

if (!TupleType & !CollectionType) {
// add AnyType Operations
}

Another thing that i dont understand very much and i havent found anything
in OCL specification is the meaning of TypeType type (:?). I'll try to have
a look in the UML specification, but some times im confused when we are
talking about user Types, or TypeTypes which refer to user types.

Thank you very much for your attention :)

Greetings,
Adolfo
Re: About adding new predefined propertys [message #24883 is a reply to message #24502] Mon, 28 May 2007 05:03 Go to previous messageGo to next message
Eclipse User
Originally posted by: alu2526.etsii.ull.es

Hi Again Christian, more doubts/problems about types.

I'll try it to explain you as well as i can.

Firstly, i may comment that im taking another aproach when i want to adapt
QVT types with OCL types resolution mechanism. For example, i have an EClass
in QVT Metamodel called ModelType, and on the one side i have it inherited
from PredefinedType and on the other side i have defined all his valid
EOperations defined as well (ModelType is a EClass better than a
EClassifier).

So implenting the oclOperations (from PredefinedType interface) should let
access to all his EOperations in an OCLExpression that refers to this
ModelType . I'll show an example:

modeltype ECORE uses ecore('http://www.eclipse.org/emf/2002/Ecore')
where {self.objectsOfType(EClassifier)->size() >= 1};

When i have a instance of ModelType and a OCLExpression who refers it, self
variable(in this case) should can access to all predefined EOperations to
this kind of type (the operation objectsOfType for example), so
oclOperations (in ModelTypeImpl) could be simply implemented as follows:

puclic EList<EOperation> oclOperations() {
return eClass().getEOperations();
}

Well, when executing the parser the operations is found, but his argument is
not matched. Tracing the execution i hv found the following problem.

- The argument is named EClassifier. This name is resolved in SimpleNameCS
when lookingup Classifiers. I managed the environments to lookup classifiers
in all the EPackage defined in the transformation, and it s successfully
located, but it creates a TypeExpression associated with the famous TypeType
which finally refers to the real type (eType) of the element (EClassifier
has EClass as his eType in the Ecore Metamodel).
- I have defined objectOfType in ModelType as a Eoperation whose parameter
is a EClassifier. EClassifier in Ecore Metamodel is a EClassifier ( :) ) as
long as it is an EClass. So we should not have problems when matching the
argument with the operation parameter.
- But we have problems. The name EClassifier has typed as a TypeType and the
objectOfType EOperation is expecting an EClassifier, and unfortunately the
argument is not matched. I think thar you ar not having problems, because
you define your EOperations expecting a TypeType argument (oclType is
called), but this a problem for me.

I have thought that perhaps if i have and argument of TypeType i could try
to match his referred type in order to solve this issue. But im not sure if
this is the best way. Perhaps avoiding the use if the typeType when locating
EClassifiers in the expressions. As i commented in the previous post, im not
very familiar or known with this kind of Type.

I hope that i have explained well, but i could try it in again. If im
missing somethig, i hope that you can help me.

Thank you for the Help Christian.

Greetings,
Adolfo

"Christian W. Damus" <cdamus@ca.ibm.com> escribi
Re: About adding new predefined propertys [message #25032 is a reply to message #24852] Mon, 28 May 2007 13:54 Go to previous messageGo to next message
Eclipse User
Originally posted by: cdamus.ca.ibm.com

Hi, Adolfo,

The oclstdlib.ecore classes all replicate the OclAny-defined operations
because they don't actually specialize OclAny, but still need to be
completely defined. I'm not sure that this is a great situation; if you
raise a bugzilla, I'll see what can be done in the 1.2 release to share
these operation definitions. That would require some kind of compatibility
scheme in the resource implementation to map the URIs of operations that
are deleted to the instances that remain in the OclAny_Class, so it isn't a
change that can be tackled in the 1.1 release at this stage. The standard
library model was generated by code, and this didn't account for the fact
that it is awkward having multiple definitions of the same generic
operation, so that identity comparisons don't work ...

The TypeType isn't well defined in the OCL spec. In fact, it only appears
in the diagrams; there isn't any description of it, so I've had to
interpolate its meaning from a few references to OclType etc. AFAICS, it
is supposed to be the OCL metamodel's representation of a "metatype", whose
purpose is simply to be the type of TypeExp instances. The type of a
TypeExp cannot be the referred type, itself, because that is at the wrong
metalevel. However, I don't know why Classifier isn't the type of TypeExp.
The OCL spec does nothing to describe what the serialization of a TypeExp
(more specifically, its TypeType) should look like.

Cheers,

Christian


Adolfo S�chez-Barbudo Herrera wrote:

> Hi Christian,
>
> And thank you for your replies and patience ;)
>
> 'The semantic' was a missplaced word :-).
>
> I'll write some more replies
>
>> That sounds like it should work. The only concern I would have is that,
>> in
>> the Ecore binding at least, *all* EcoreEnvironments will see the features
>> that you have added to OclAny. The oclstdlib.ecore model is only loaded
>> once (a singleton). If you take the approach that I suggested, then your
>> additional features will reside only in each distinct environment
>> instance,
>> not in the shared standard library resource.
>
> Well, as i said you yesterday i 'll need to implement my own
> OMStandardLibreary, because OM has some new predefined Types and new
> operations referred to them or some considerations about the
> OCLStandardLibrary.
>
>> I think you may have misread the getOperations() method. It relies on
>> the OCL predefined types knowing all of their applicable operations,
>> which is
>> why they are completely specified in the oclstdlib.ecore model. The
>> OclAny
>> operations are only appended to the result for types in the user's model.
>> This is necessary because the OCL parser doesn't actually change the
>> inheritance relationships of these user types.
>
> Thanks for the aclaration, i was missing that predefinedType is the base
> of all the oclTypes (including AnyType for example). Anyway, we are having
> the same problem that i wanted to explain you. I'll try it with other
> words, but as you might have noticed im not a good english language user
> :P.
>
> Well, I was a little shocked when i saw that in all predefinedType's
> shadow classes (Except CollectionTypes and TupleTypes as the specification
> says) of oclstdlib metamodel, you had defined all the AnyType operations.
> So I suppose that the only use in the AnyType predefinedType is adding
> AnyType operations to the user model types. I think that you should also
> use AnyType
> in order to avoid defining all these operations in every predefined type
> (excluding collection and tupleType of course) we could have.
>
> For example, in the method getOperations we are talking about:
>
> if (TypeType) {
> ....
> }
> else
> if (PredefinedType) {
> .....
> }
> else {
> // user model types
> .....
> }
>
> if (!TupleType & !CollectionType) {
> // add AnyType Operations
> }
>
> Another thing that i dont understand very much and i havent found anything
> in OCL specification is the meaning of TypeType type (:?). I'll try to
> have a look in the UML specification, but some times im confused when we
> are talking about user Types, or TypeTypes which refer to user types.
>
> Thank you very much for your attention :)
>
> Greetings,
> Adolfo
Re: About adding new predefined propertys [message #25073 is a reply to message #24883] Mon, 28 May 2007 13:59 Go to previous messageGo to next message
Eclipse User
Originally posted by: cdamus.ca.ibm.com

Hi, Adolfo,

I understand, now. This seems to relate to the problem I remarked on in my
reply to your other post, that perhaps the type of TypeExp should have been
Classifier (EClassifier) instead of TypeType. TypeType shouldn't exist.

The parser extensibility doesn't account for clients adding operations that
accept TypeExps as arguments, and I agree that a client shouldn't have to
implement signatures with TypeType when EClassifier is more appropriate.

For now, your custom environment will have to work around this by having
special knowledge of your additional operations, and coercing TypeType to
EClassifier for those operations only. Please raise a feature request in
bugzilla, and we'll see whether this can be improved in the next OCL
release.

Cheers,

Christian


Adolfo S�chez-Barbudo Herrera wrote:

> Hi Again Christian, more doubts/problems about types.
>
> I'll try it to explain you as well as i can.
>
> Firstly, i may comment that im taking another aproach when i want to adapt
> QVT types with OCL types resolution mechanism. For example, i have an
> EClass in QVT Metamodel called ModelType, and on the one side i have it
> inherited from PredefinedType and on the other side i have defined all his
> valid EOperations defined as well (ModelType is a EClass better than a
> EClassifier).
>
> So implenting the oclOperations (from PredefinedType interface) should let
> access to all his EOperations in an OCLExpression that refers to this
> ModelType . I'll show an example:
>
> modeltype ECORE uses ecore('http://www.eclipse.org/emf/2002/Ecore')
> where {self.objectsOfType(EClassifier)->size() >= 1};
>
> When i have a instance of ModelType and a OCLExpression who refers it,
> self variable(in this case) should can access to all predefined
> EOperations to this kind of type (the operation objectsOfType for
> example), so oclOperations (in ModelTypeImpl) could be simply implemented
> as follows:
>
> puclic EList<EOperation> oclOperations() {
> return eClass().getEOperations();
> }
>
> Well, when executing the parser the operations is found, but his argument
> is not matched. Tracing the execution i hv found the following problem.
>
> - The argument is named EClassifier. This name is resolved in SimpleNameCS
> when lookingup Classifiers. I managed the environments to lookup
> classifiers in all the EPackage defined in the transformation, and it s
> successfully located, but it creates a TypeExpression associated with the
> famous TypeType which finally refers to the real type (eType) of the
> element (EClassifier has EClass as his eType in the Ecore Metamodel).
> - I have defined objectOfType in ModelType as a Eoperation whose parameter
> is a EClassifier. EClassifier in Ecore Metamodel is a EClassifier ( :) )
> as long as it is an EClass. So we should not have problems when matching
> the argument with the operation parameter.
> - But we have problems. The name EClassifier has typed as a TypeType and
> the objectOfType EOperation is expecting an EClassifier, and unfortunately
> the argument is not matched. I think thar you ar not having problems,
> because you define your EOperations expecting a TypeType argument (oclType
> is called), but this a problem for me.
>
> I have thought that perhaps if i have and argument of TypeType i could try
> to match his referred type in order to solve this issue. But im not sure
> if this is the best way. Perhaps avoiding the use if the typeType when
> locating EClassifiers in the expressions. As i commented in the previous
> post, im not
> very familiar or known with this kind of Type.
>
> I hope that i have explained well, but i could try it in again. If im
> missing somethig, i hope that you can help me.
>
> Thank you for the Help Christian.
>
> Greetings,
> Adolfo
>

<snip>
Re: About adding new predefined propertys [message #25237 is a reply to message #25073] Tue, 29 May 2007 09:35 Go to previous messageGo to next message
Eclipse User
Originally posted by: alu2526.etsii.ull.es

Hi Christian,

Before raising it, i wanted to have more comments about the issue. Look at
the following copy-paste ocl especification part

TypeExp
A TypeExp is an expression used to refer to an existing meta type within an
expression. It is used in particular to pass the reference of the meta type
when invoking the operations oclIsKindOf, oclIsTypeOf, and oclAsType.

Associations

referredType The type being referred.

Firstly, this association is missed in the ocl metamodel. If im not wrong,
you have established this association to the TypeType and this is the type
for a TypeExp.

Secondly, in the other post you hv commented that the type of the TypeExpr
couldnt be the referredType itself. I dont understand the reason why it
can't be. In this part of the especification doesnt say anything about the
type of a a typeExpr, but i suppose that might be the referredType of the
TypeExpression. In addon to this, the abstract syntax diagram of types
package show that the referredtype is actually an Classifier.
Re: About adding new predefined propertys [message #25397 is a reply to message #25237] Tue, 29 May 2007 10:06 Go to previous messageGo to next message
Eclipse User
Originally posted by: cdamus.ca.ibm.com

Hi, Adolfo,

See some replies in-line, below.

Cheers,

Christian


Adolfo S�chez-Barbudo Herrera wrote:

> Hi Christian,
>
> Before raising it, i wanted to have more comments about the issue. Look at
> the following copy-paste ocl especification part
>
> TypeExp
> A TypeExp is an expression used to refer to an existing meta type within
> an expression. It is used in particular to pass the reference of the meta
> type when invoking the operations oclIsKindOf, oclIsTypeOf, and oclAsType.
>
> Associations
>
> referredType The type being referred.
>
> Firstly, this association is missed in the ocl metamodel. If im not wrong,
> you have established this association to the TypeType and this is the type
> for a TypeExp.

The org.eclipse.ocl/model/OCL.ecore model has TypeExp::referredType and
TypeType::referredType. The latter is defined by MDT OCL to solve the
problem of how to serialize TypeTypes so that they know which metaclass
they reference.


> Secondly, in the other post you hv commented that the type of the TypeExpr
> couldnt be the referredType itself. I dont understand the reason why it
> can't be. In this part of the especification doesnt say anything about the
> type of a a typeExpr, but i suppose that might be the referredType of the
> TypeExpression. In addon to this, the abstract syntax diagram of types
> package show that the referredtype is actually an Classifier. Which other
> type could the TypeExpression's type be ?.

The type of a TypeExp, if it were the referred type, would mean that an
evaluation of the TypeExp results in an *instance* of the referred type.
But, that doesn't make sense, as it should result in the metaclass/TypeType
for the referred type. Unfortunately, in Chapter 10 of the OCL spec, there
is no specification of values of TypeTypes in the Values package nor
specification of the values of TypeExps in the Expressions package, so
there is no clue there :-( If it were up to me, the type of a TypeExp
would be Classifier and TypeType and OclType would not exist.

The implementations of TypeExp and TypeType in MDT OCL are essentially
unchanged from their first incarnation in 2003, which was based on the
interim draft of the OCL 2.0 specification from that same year. I think
that draft may have been more explicit about the relationship of these two
metaclasses. I'll see whether I can dig it up and found out more ...

>
> Greetings,
> Adolfo
>
>

>snip>
Re: About adding new predefined propertys [message #26084 is a reply to message #25397] Thu, 31 May 2007 05:38 Go to previous messageGo to next message
Eclipse User
Originally posted by: alu2526.etsii.ull.es

Hi Christian,

Some replies in-line, below

> The org.eclipse.ocl/model/OCL.ecore model has TypeExp::referredType and
> TypeType::referredType. The latter is defined by MDT OCL to solve the
> problem of how to serialize TypeTypes so that they know which metaclass
> they reference.

My mistake. I was looking OCLEcore metamodel and i forgot to have a look to
te OCL metamodel, which is extended by the first one.

> The type of a TypeExp, if it were the referred type, would mean that an
> evaluation of the TypeExp results in an *instance* of the referred type.
> But, that doesn't make sense, as it should result in the
> metaclass/TypeType
> for the referred type. Unfortunately, in Chapter 10 of the OCL spec,
> there
> is no specification of values of TypeTypes in the Values package nor
> specification of the values of TypeExps in the Expressions package, so
> there is no clue there :-( If it were up to me, the type of a TypeExp
> would be Classifier and TypeType and OclType would not exist.

> The implementations of TypeExp and TypeType in MDT OCL are essentially
> unchanged from their first incarnation in 2003, which was based on the
> interim draft of the OCL 2.0 specification from that same year. I think
> that draft may have been more explicit about the relationship of these two
> metaclasses. I'll see whether I can dig it up and found out more ...

What do you think about the following exposition:

If i have in the expression: self.objectsOfType(EClassifier), the type
expression represents our MetaType EClassifier, which is an EClass (an
EClassifier) in the Ecore metamodel.

if we have: self.objectsOfType(EBoolean), the type expression represents our
MetaType EBoolean, which is an EDataType (an EClassifier again) in the Ecore
Metamodel.

If we have another metamodel (OperationalMappings for example)
self.objectsOfType(OperationalTransformation), the type expression
representes our MetaType OperationalTransformation, which is a
Module->EClass (so an EClassifier) in the QVTOperational metamodel.

All examples are a valid expression if i have the my operation signature is
ModelType::objectsOfType(EClassifier), so when i find a name that
correspond toa EClassifier in the oclExpression i'll create TypeExpression
with the EClassifier found as his referredType, and his metaClassifier (M2)
as the type of the TypeExp.

TypeExp::referredType = classifierFound (M1). // In the first example:
EClassifier
TypeExp::type = classifierFonund.eClass (M2). // In the first example:
EClass

I dont know if i hv explained well or if im in the right way :S :S :S

Anyway I have raised the bug about the TypeExpression's type: #190150

ah, another comment:

When resolving simpleNameCS, and you have binded it to a classifier ( you
have to create TypeExp node) you could use the private method typeCS(C, env)
destinated to this task (OCLParser.java -> line 2507), and of course
redefine these method to get the behaviour we are talking about. I'll show
what i have done, taking in account that i'm working with Ecore Binding

private TypeExp typeCS(EClassifier type) {

TypeExp astNode = oclFactory.createTypeExp();
astNode.setReferredType(type);
astNode.setType(type.eClass());
return astNode;
}

P.D: We could be talking about more issues when trying to extend OCLParser
to parse operationalMappings (for example, why i have your ast building
methods reimplemented and binded to Ecore Metamodel) but this will be in
following posts ;).

Greetings,
Adolfo.
Re: About adding new predefined propertys [message #26168 is a reply to message #26084] Thu, 31 May 2007 11:32 Go to previous messageGo to next message
Eclipse User
Originally posted by: cdamus.ca.ibm.com

Hi, Adolfo,

More replies in-line.

Cheers,

Christian


Adolfo S�chez-Barbudo Herrera wrote:

> Hi Christian,
>
> Some replies in-line, below
>

<snip>

>> The implementations of TypeExp and TypeType in MDT OCL are essentially
>> unchanged from their first incarnation in 2003, which was based on the
>> interim draft of the OCL 2.0 specification from that same year. I think
>> that draft may have been more explicit about the relationship of these
>> two
>> metaclasses. I'll see whether I can dig it up and found out more ...
>
> What do you think about the following exposition:
>
> If i have in the expression: self.objectsOfType(EClassifier), the type
> expression represents our MetaType EClassifier, which is an EClass (an
> EClassifier) in the Ecore metamodel.
>
> if we have: self.objectsOfType(EBoolean), the type expression represents
> our MetaType EBoolean, which is an EDataType (an EClassifier again) in the
> Ecore Metamodel.

I have already understood that you're looking for the type of TypeExp to be
Classifier, not TypeType. I would prefer it that way, too, as I have
mentioned before. It's just that MDT OCL is trying to implement a (very)
imperfect specification, and this is one of the areas where it is likely
that either the specification is wrong, or the implementation is wrong, or
both. (probably the last :-)

I don't believe that either TypeType or OclType should exist.

In earlier drafts of the 2.0 spec, OclType was described as being retained
from OCL 1.4 but morphed to an enumeration, rather than an instance of the
1.4 OclMetaType metaclass. In the final 2.0 draft, however, TypeType made
an appearance in the Types package, but without any description. Likewise
TypeExp, which didn't exist at all in previous drafts. It is clear that
TypeExp is used for references to types, and that operations such as
OclAny::oclIsKindOf(t : OclType) still use this "OclType" concept.

Section 11 of the final 2.0 draft now describes OclType as the "singleton
instance of TypeType" but does not describe it as an enumeration, as in the
earlier drafts.

The earlier drafts also describe (in a "Design Rationale" section) the
intent of the OclType enumeration (rather than using Classifier) as
providing some kind of meta-level reflection, because UML does not provide
any reflection capability. There is also a note to the effect that, in the
event that UML does eventually provide reflection, then OCL will use that,
instead of OclType. This discussion is entirely absent in the final
specification.

It's all so very confusing because the OCL Specification still is not at all
well aligned with UML, and has too much of prevarication about assumptions
about what UML may or may not look like, when UML 2.0 has been around for
quite some time, now.

I am eagerly awaiting an OCL 2.1 specification. :-D


> If we have another metamodel (OperationalMappings for example)
> self.objectsOfType(OperationalTransformation), the type expression
> representes our MetaType OperationalTransformation, which is a
> Module->EClass (so an EClassifier) in the QVTOperational metamodel.
>
> All examples are a valid expression if i have the my operation signature
> is ModelType::objectsOfType(EClassifier), so when i find a name that
> correspond toa EClassifier in the oclExpression i'll create
> TypeExpression with the EClassifier found as his referredType, and his
> metaClassifier (M2) as the type of the TypeExp.
>
> TypeExp::referredType = classifierFound (M1). // In the first example:
> EClassifier
> TypeExp::type = classifierFonund.eClass (M2). // In the first example:
> EClass
>
> I dont know if i hv explained well or if im in the right way :S :S :S

Perfectly clear!


> Anyway I have raised the bug about the TypeExpression's type: #190150

Thanks! That will be a good place to continue discussion and figure out how
to get out of this jam.


> ah, another comment:
>
> When resolving simpleNameCS, and you have binded it to a classifier ( you
> have to create TypeExp node) you could use the private method typeCS(C,
> env) destinated to this task (OCLParser.java -> line 2507), and of course
> redefine these method to get the behaviour we are talking about. I'll
> show what i have done, taking in account that i'm working with Ecore
> Binding
>
> private TypeExp typeCS(EClassifier type) {
>
> TypeExp astNode = oclFactory.createTypeExp();
> astNode.setReferredType(type);
> astNode.setType(type.eClass());
> return astNode;
> }

Well, yes, that would clearly be the way to go if the type of TypeExp is to
be Classifier (generically, C). In the 1.2 release I should look into
providing some kind of option to implement it this way for clients that
prefer Classifier to TypeType (I need to maintain compatibility with 1.1).


> P.D: We could be talking about more issues when trying to extend OCLParser
> to parse operationalMappings (for example, why i have your ast building
> methods reimplemented and binded to Ecore Metamodel) but this will be in
> following posts ;).

You should probably have a look at what Ed Willink is contributing vis-a-vis
extensibility of the OCL parser for his implementation of the QVT
Relational language:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=176110

and Borland's initial contribution of a QVT Operation implementation to the
Model-to-model Transformations project, which likewise extends MDT OCL.

>
> Greetings,
> Adolfo.
Re: About adding new predefined propertys [message #27002 is a reply to message #26168] Thu, 07 June 2007 08:35 Go to previous messageGo to next message
Eclipse User
Originally posted by: alu2526.etsii.ull.es

Hi Christian,

Of course, i hv looked the excelent Ed's Work. I liked very much the
refactor that he made in differents levels of abstraction amongst your OCL
parser, and his QVTRelations one, and both AST builders. Anyway im expecting
to your decision about this theme, so i have a big ball with a lot of
methods :P.

On the other hand i disliked what he made with the environments, having a
lot of HashMaps, to manage all the searches (packages, operations, etc) en
each kind of environment. Perhaps it could be more optimal, but by the
moment I prefer to take advantage of all the implementation that you have
(for example adding operations to classes instead of having a map of
name-operations and overwriting the lookup operation in each environment) as
far as posible.

> and Borland's initial contribution of a QVT Operation implementation to
> the
> Model-to-model Transformations project, which likewise extends MDT OCL.

noidea about that :?

Thank you very much for the help !!!!
Greetings,
Adolfo.

"Christian W. Damus" <cdamus@ca.ibm.com> escribi
Re: About adding new predefined propertys [message #27042 is a reply to message #27002] Thu, 07 June 2007 09:00 Go to previous messageGo to next message
Eclipse User
Originally posted by: cdamus.ca.ibm.com

Hi, Adolfo,

Just a few more replies, in-line.

Cheers,

Christian

Adolfo S�chez-Barbudo Herrera wrote:

> Hi Christian,
>
> Of course, i hv looked the excelent Ed's Work. I liked very much the
> refactor that he made in differents levels of abstraction amongst your OCL
> parser, and his QVTRelations one, and both AST builders. Anyway im
> expecting to your decision about this theme, so i have a big ball with a
> lot of methods :P.

Yes, I like this refactoring, too, which is why I hope to apply it to OCL
early in the 1.2 development plan.


> On the other hand i disliked what he made with the environments, having a
> lot of HashMaps, to manage all the searches (packages, operations, etc) en
> each kind of environment. Perhaps it could be more optimal, but by the
> moment I prefer to take advantage of all the implementation that you have
> (for example adding operations to classes instead of having a map of
> name-operations and overwriting the lookup operation in each environment)
> as far as posible.

I don't know much about this; I think this must be in the QVTr
implementation, which is not part of the refactoring that will be
contributed to OCL. Certainly, more focus on performance tuning might be a
good theme for the OCL 1.2 release.


>> and Borland's initial contribution of a QVT Operation implementation to
>> the
>> Model-to-model Transformations project, which likewise extends MDT OCL.
>
> noidea about that :?

I understand from Rich Gronback that it is due to be committed to CVS
sometime "soon."


> Thank you very much for the help !!!!
> Greetings,
> Adolfo.
>

<snip>
Re: About adding new predefined propertys [message #27276 is a reply to message #27042] Thu, 07 June 2007 12:02 Go to previous messageGo to next message
Eclipse User
Originally posted by: alu2526.etsii.ull.es

Hi Christian,

Some comments,

> Yes, I like this refactoring, too, which is why I hope to apply it to OCL
> early in the 1.2 development plan.

Great !!!. If i get a little time, i could give some notes or comments that
i hv taken while extending grammars, or problems that i could add to the
Ed's ones. I hv left LPG issues back some months ago and i will have to
analyze them again :P

> I don't know much about this; I think this must be in the QVTr
> implementation, which is not part of the refactoring that will be
> contributed to OCL. Certainly, more focus on performance tuning might be
> a
> good theme for the OCL 1.2 release.

Oh yes, i was talking about QVTrEnvironments implementation ;). Anyway, i hv
tried to work with the actual environment mechanism and all the funcionality
that your project let me to work ;)

Greetings and thanks for all !!!!
Adolfo.

"Christian W. Damus" <cdamus@ca.ibm.com> escribi
Re: About adding new predefined propertys [message #31388 is a reply to message #25032] Fri, 29 June 2007 08:46 Go to previous messageGo to next message
Eclipse User
Originally posted by: alu2526.etsii.ull.es

Hi Christian,

I have reached a point, where having separated oclAny operations from each
type is crucial for me.

I'll tell you the ways im taking:

I have my own OMStandardLibraryImpl class which implements
OCLStandardLibrary interface.
where i define the new unique instances of the new OM types. When asking for
original ocl types i return the OCLStandardLibraryImpl instances, so i dont
have to redefine them again.

However, if i have some original OCL types that need new operations (Forget
defining them in the environment, i want all of them in the singleton
OMStandardLibraryImpl ) i have decided to create a new unique instances for
them, and use the OCLStandarLibraryUtil methods to add the original ocl
operations to the type, and and implement the OMStandardLibraryUtil in order
to add the new OM types operations. So i dont have to (and must not) change
the oclstdlib.

The problem then, is that if i want to create a new instance for ocl anyType
( to add new operations for it) , I have to redefine all the rest of the
unique instances (except collectionTypes instances) because the new anyTypes
operations have to be added too, when in fact should not be necesary.

Have i explained propertly? What do you think about it?

greetings,
Adolfo.

"Christian W. Damus" <cdamus@ca.ibm.com> escribi
Re: About adding new predefined propertys [message #31418 is a reply to message #31388] Fri, 29 June 2007 09:53 Go to previous messageGo to next message
Eclipse User
Originally posted by: cdamus.ca.ibm.com

Hi, Adolfo,

Yes, the current definitions of the OCL Standard Library types are
inconvenient for this kind of redefinition of the library. The
extensibility design only really accounts for the OCL mechanism of
"additional operations." The OCL API only intends for metamodel bindings
to define their own standard library implementations; custom environments
should not need to do this.

Why is it necessary to define an OMStandardLibraryImpl? Does the
additional-operations mechanism not work for you? What could be done to
improve that? If it's a problem of having to repeat (and persist) these
additional operations in every environment instance, I'm sure it would be
possible to share them in a well-known in-memory resource in the same
fashion as the oclstdlib.

I am more concerned about the duplication within the oclstdlib.{ecore,uml}
of operations that should be uniquely defined, which will be addressed in
the bug that you raised some time ago.

Cheers,

Christian

Adolfo S�chez-Barbudo Herrera wrote:

> Hi Christian,
>
> I have reached a point, where having separated oclAny operations from each
> type is crucial for me.
>
> I'll tell you the ways im taking:
>
> I have my own OMStandardLibraryImpl class which implements
> OCLStandardLibrary interface.
> where i define the new unique instances of the new OM types. When asking
> for original ocl types i return the OCLStandardLibraryImpl instances, so i
> dont have to redefine them again.
>
> However, if i have some original OCL types that need new operations
> (Forget defining them in the environment, i want all of them in the
> singleton OMStandardLibraryImpl ) i have decided to create a new unique
> instances for them, and use the OCLStandarLibraryUtil methods to add the
> original ocl operations to the type, and and implement the
> OMStandardLibraryUtil in order to add the new OM types operations. So i
> dont have to (and must not) change the oclstdlib.
>
> The problem then, is that if i want to create a new instance for ocl
> anyType
> ( to add new operations for it) , I have to redefine all the rest of the
> unique instances (except collectionTypes instances) because the new
> anyTypes operations have to be added too, when in fact should not be
> necesary.
>
> Have i explained propertly? What do you think about it?
>
> greetings,
> Adolfo.

<snip>
Re: About adding new predefined propertys [message #31595 is a reply to message #31418] Fri, 29 June 2007 11:32 Go to previous messageGo to next message
Eclipse User
Originally posted by: alu2526.etsii.ull.es

Hi Christian,

Some comments in-line, below


> Hi, Adolfo,
>
> Yes, the current definitions of the OCL Standard Library types are
> inconvenient for this kind of redefinition of the library. The
> extensibility design only really accounts for the OCL mechanism of
> "additional operations." The OCL API only intends for metamodel bindings
> to define their own standard library implementations; custom environments
> should not need to do this.

> Why is it necessary to define an OMStandardLibraryImpl?

QVT Specification talks about an Operational Mapping StandardLibrary, as the
same way as i suppose OCL specification talks about its OCLStandarLibrary,
and of course OMStandarLibrary is related as a extension of the
OCLStandardLibrary. Why is necesary to define an OCLStandardLibraryImpl ? I
think that the response is what you comment below, of having only one
resource with the types and operations related.

> Does the
> additional-operations mechanism not work for you? What could be done to
> improve that?

I suppose that it should work, but as i said previously, i think that is
better having an extension of the OCLStandardLibrary, with the OCL original
types and his operations, with the original OCL types modified with new
operations, and eventually new OM types with their operations.

> If it's a problem of having to repeat (and persist) these
> additional operations in every environment instance, I'm sure it would be
> possible to share them in a well-known in-memory resource in the same
> fashion as the oclstdlib.

Sure, as i said, and is exactly what im trying. Perhaps i must add that the
OMenvironments will have OMStandardLibrary as his OCLStandardLibrary, where
the types will have references to "yourResourcePlace/oclstdlib.ecore"
(original ocl types and operations) and references to
"myResourcePlace/omstdlib.ecore" (original ocl types modified with new
operations, and new om types).

> I am more concerned about the duplication within the oclstdlib.{ecore,uml}
> of operations that should be uniquely defined, which will be addressed in
> the bug that you raised some time ago.

Well i think, that when this is resolved, i'll be able to properly extend
the OCLStandardLibrary as i have mentioned. I think this way should be the
best way to commit, shouldnt you ?

I think that on the one hand, you should avoid adding the oclAnyOperations
in every type ( in every method of OCLStandardLibraryUtil
createTYPEoperations), and on the other hand propertly getting the operation
in the OCLStandardLibraryUtil TypeUtil.getOperations (such as the example i
exposed in the previous post). Ah, and i dont forget that you should keep
the compatibility with previous versions ;) (resolve all duplicated
operation's references which will disappear).

Meanwhile, i'll duplicate the OCLStandardLib instances of all the types
(Copy-paste :( ), in the OMStandardLib implementation.

Cheers,
Adolfo.
Re: About adding new predefined propertys [message #31630 is a reply to message #31595] Fri, 29 June 2007 11:58 Go to previous messageGo to next message
Eclipse User
Originally posted by: cdamus.ca.ibm.com

Hi, Adolfo,

I see. Yes, resolving that bug should simplify what you need to do.

We'll just have to see about how and when that bug can be fixed. Any code
that you can contribute towards that end would be most appreciated.
Wouldn't you like to appear in the OCL component's IP log? :-)

Cheers,

Christian


Adolfo S�chez-Barbudo Herrera wrote:

> Hi Christian,
>
> Some comments in-line, below
>
>
>> Hi, Adolfo,
>>
>> Yes, the current definitions of the OCL Standard Library types are
>> inconvenient for this kind of redefinition of the library. The
>> extensibility design only really accounts for the OCL mechanism of
>> "additional operations." The OCL API only intends for metamodel bindings
>> to define their own standard library implementations; custom environments
>> should not need to do this.
>
>> Why is it necessary to define an OMStandardLibraryImpl?
>
> QVT Specification talks about an Operational Mapping StandardLibrary, as
> the same way as i suppose OCL specification talks about its
> OCLStandarLibrary, and of course OMStandarLibrary is related as a
> extension of the OCLStandardLibrary. Why is necesary to define an
> OCLStandardLibraryImpl ? I think that the response is what you comment
> below, of having only one resource with the types and operations related.
>
>> Does the
>> additional-operations mechanism not work for you? What could be done to
>> improve that?
>
> I suppose that it should work, but as i said previously, i think that is
> better having an extension of the OCLStandardLibrary, with the OCL
> original types and his operations, with the original OCL types modified
> with new operations, and eventually new OM types with their operations.
>
>> If it's a problem of having to repeat (and persist) these
>> additional operations in every environment instance, I'm sure it would be
>> possible to share them in a well-known in-memory resource in the same
>> fashion as the oclstdlib.
>
> Sure, as i said, and is exactly what im trying. Perhaps i must add that
> the OMenvironments will have OMStandardLibrary as his OCLStandardLibrary,
> where the types will have references to
> "yourResourcePlace/oclstdlib.ecore" (original ocl types and operations)
> and references to "myResourcePlace/omstdlib.ecore" (original ocl types
> modified with new operations, and new om types).
>
>> I am more concerned about the duplication within the
>> oclstdlib.{ecore,uml} of operations that should be uniquely defined,
>> which will be addressed in the bug that you raised some time ago.
>
> Well i think, that when this is resolved, i'll be able to properly extend
> the OCLStandardLibrary as i have mentioned. I think this way should be the
> best way to commit, shouldnt you ?
>
> I think that on the one hand, you should avoid adding the oclAnyOperations
> in every type ( in every method of OCLStandardLibraryUtil
> createTYPEoperations), and on the other hand propertly getting the
> operation in the OCLStandardLibraryUtil TypeUtil.getOperations (such as
> the example i exposed in the previous post). Ah, and i dont forget that
> you should keep
> the compatibility with previous versions ;) (resolve all duplicated
> operation's references which will disappear).
>
> Meanwhile, i'll duplicate the OCLStandardLib instances of all the types
> (Copy-paste :( ), in the OMStandardLib implementation.
>
> Cheers,
> Adolfo.
Re: About adding new predefined propertys [message #31701 is a reply to message #31630] Mon, 02 July 2007 07:36 Go to previous messageGo to next message
Eclipse User
Originally posted by: alu2526.etsii.ull.es

Hi Christian,

Well, I would be pleased of contributing to the project of course ;).
I have clear ideas of what i have to do improve the oclstdlib, in order to
support extensibility in a better way. But im not very confidence of how i
should act to keep compatibility with previous versions, or what kind of
problems could appear, and i should take into account. If you could me give
some advice, or guides.... :P

Best regards,

Adolfo



"Christian W. Damus" <cdamus@ca.ibm.com> escribi
Re: About adding new predefined propertys [message #31839 is a reply to message #31701] Wed, 04 July 2007 11:20 Go to previous message
Eclipse User
Originally posted by: cdamus.ca.ibm.com

Hi, Adolfo,

The first thing that I would try is a custom resource implementation that
redirects object look-up in the getEObject(String fragment) method. Beyond
that, I would need the same advice from somebody as you :-)

cW


Adolfo S�chez-Barbudo Herrera wrote:

> Hi Christian,
>
> Well, I would be pleased of contributing to the project of course ;).
> I have clear ideas of what i have to do improve the oclstdlib, in order to
> support extensibility in a better way. But im not very confidence of how i
> should act to keep compatibility with previous versions, or what kind of
> problems could appear, and i should take into account. If you could me
> give some advice, or guides.... :P
>
> Best regards,
>
> Adolfo

<snip>
Previous Topic:Suggestion of generalizing Ecore CollectionTypes
Next Topic:Syntax helper for OCL undefined type
Goto Forum:
  


Current Time: Fri Aug 22 00:07:42 EDT 2014

Powered by FUDForum. Page generated in 0.02249 seconds