Issue 12854: OCL 2.0 Issue: References to Additional Attributes and Operations (ocl2-rtf)
Source: Zeligsoft, Inc. (Mr. Christian W. Damus, nobody)
Nature: Uncategorized Issue
Severity: 
Summary: Re: OCL 2.0 formal/06-05-01


The Abstract Syntax defines expressions that navigate properties and  
call operations of Classifiers:  the PropertyCallExp and  
OperationCallExp, respectively.  These work well for features of  
Classifiers that are defined by the UML model that is the subject of  
the OCL constraints.


However, OCL also provides a mechanism for defining additional  
attributes and operations on behalf of a classifier:  the definition  
constraint.  As these definitions are extrinsic to the UML model,  
there are no Property and Operation elements for the respective  
expressions to reference.  There are only Constraints with an  
«oclHelper» stereotype and a body expression.  The very purpose of  
these definitions is to assist in the formulation of OCL constraints,  
so it is necessary that the abstract syntax be able to reference them.


I can think of an obvious approach to resolution of this problem:  add  
an association "referredDefinition : Constraint" with 0..1  
multiplicity to both of the existing PropertyCallExp and  
OperationCallExp metaclasses.  The 0..1 multiplicity of the existing  
referredProperty and referredOperation associations, as shown in  
Figure 8.3, appears to be in error (as the rest of the text and, in  
particular, the well-formedness rules of Section 8.3.7, assumes the  
reference to the referred features) but is required by this solution.   
Additional well-formedness rules would stipulate, for each expression,  
that exactly one of the referred feature of referred definition  
associations have a value.


This suggestion is not entirely satisfactory, as it breaks the  
uniformity of references to features in call expressions and encodes,  
in the abstract syntax, a dependency on a feature's being an  
additional definition.  However, this problem is a practical concern  
for the serialization and exchange of the OCL Abstract Syntax, as the  
current metamodel is incomplete.


Resolution: 
Revised Text: 
Actions taken:
September 14, 2008: received issue
Discussion: 
The solution suggested by the reporter as recognized by him is not satisfactory. A more clean "conceptual" solution would be to allow OCL define modules (package) that extend the metamodels (as it works in QVT).
Some further examination is needed of this issue to find the most appropriate solution. 

Disposition:	Deferred
End of Annotations:=====

m: "Christian W. Damus" <cdamus@zeligsoft.com>
To: issues@omg.org
Subject: OCL 2.0 Issue: References to Additional Attributes and Operations
Date: Sun, 14 Sep 2008 18:52:35 -0400
X-Mailer: Apple Mail (2.928.1)
X-Authenticated: cdamus@magma.ca - bas21-toronto12-1242558811.dsl.bell.ca ([10.0.1.199]) [74.15.241.91]
X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id m8EMqZEd009012


Re: OCL 2.0 formal/06-05-01


The Abstract Syntax defines expressions that navigate properties and  
call operations of Classifiers:  the PropertyCallExp and  
OperationCallExp, respectively.  These work well for features of  
Classifiers that are defined by the UML model that is the subject of  
the OCL constraints.


However, OCL also provides a mechanism for defining additional  
attributes and operations on behalf of a classifier:  the definition  
constraint.  As these definitions are extrinsic to the UML model,  
there are no Property and Operation elements for the respective  
expressions to reference.  There are only Constraints with an  
«oclHelper» stereotype and a body expression.  The very purpose of  
these definitions is to assist in the formulation of OCL constraints,  
so it is necessary that the abstract syntax be able to reference them.


I can think of an obvious approach to resolution of this problem:  add  
an association "referredDefinition : Constraint" with 0..1  
multiplicity to both of the existing PropertyCallExp and  
OperationCallExp metaclasses.  The 0..1 multiplicity of the existing  
referredProperty and referredOperation associations, as shown in  
Figure 8.3, appears to be in error (as the rest of the text and, in  
particular, the well-formedness rules of Section 8.3.7, assumes the  
reference to the referred features) but is required by this solution.   
Additional well-formedness rules would stipulate, for each expression,  
that exactly one of the referred feature of referred definition  
associations have a value.


This suggestion is not entirely satisfactory, as it breaks the  
uniformity of references to features in call expressions and encodes,  
in the abstract syntax, a dependency on a feature's being an  
additional definition.  However, this problem is a practical concern  
for the serialization and exchange of the OCL Abstract Syntax, as the  
current metamodel is incomplete.


Thanks,


Christian


--
Christian W. Damus
Senior Software Developer, Zeligsoft Inc.
Component Lead, Eclipse MDT OCL and EMF-QTV
E-mail: cdamus@zeligsoft.com