Issues for OCL 2 Revision Task Force

List of Open Issues. Other options: All Issues; Closed Issues.

(red=unresolved; yellow=pending Board vote)

I refer to Section 8.3.9 of the final Adopted Version of the OCL 2.0 Spec,
the two additional operations on the OclExpression.
"withAtPre" and "withAsSet".
I am wondering where the two referred operations "atPre" and "asSet"
(not restricted to collections) are "predefined"(?).

It is not entirely clear from the OCL 2.0 specification whether the allInstances operation returns instances of subclasses of the designated type. In other words, it isn't 100% clear whether t.allInstances( ) returns instances of subclasses of t. 

Recommendation:

The best solution would be to have two operations, one which returns instances of subclasses and one which does not. 

A second-best solution would be to make it clear that allInstances returns instances of subclasses. In this case, an OCL programmer could use the oclIsTypeOf( ) operation as a filter to write a derived operation that does not return instances of subclasses. If allInstances does not return instances of subclasses, it would not be nearly as straightforward to write a derived operation that does return instances of subclasses.

The spec ptc/03-10-14 lists navigating across non navigable associations as a compliance point.  However, all text describing the rules for doing so have been removed from this version.  The rules need to be defined more clearly in the OCL syntax.

 

The following rules for navigation using non-navigable associations extend the text in sections 7.5.4 Navigation to Association Classes, and sections 7.5.5 Navigation from Association classes, 

When a non-navigable association is between different classes, following the association to an opposite end class is specified by: 
               ("self" | <class name>) "." <association class name>["[" < opposite role name> "]"]"." <role name> 

Note the optional component is redundant, but is allowed, but not recommended.


When a non-navigable association is between the same classes, following the association to an opposite end class is specified by: 
               ("self" | <class name>) "." <association class name>"[" < opposite role name> "]." <role name> 

I refer to Section 8.3.9 of the final Adopted Version of the OCL 2.0 Spec,
the two additional operations on the OclExpression.
"withAtPre" and "withAsSet".
I am wondering where the two referred operations "atPre" and "asSet"
(not restricted to collections) are "predefined"(?).

The OCL 2.0 spec is inconsistent on whether class operations, including predefined operations, should be accessed using '.' or '::' notation. 
E.g. should it be Person.allInstances() or Person::allInstances() 

The spec uses Person.allInstances() in the text, but the concrete syntax specifies '::'. 

It seems that most tools have adopted the '.' notation used in the examples which is also backwards compatible with previous versions of OCL. 
There has also been some adoption of the '::' notation, for example in Warmer and Kleppe's OCL book, see: http://www.klasse.nl/english/boeken/ocl-book-errata.pdf 

Note: This issue was originally pointed out by Anthony Shuttleworth of Paranor. 

Proposed solution: 

The '.' notation is widely used and backwards compatible with previous versions of OCL. It should not be made invalid in OCL 2.0. 
It may be appropriate to also support the '::' notation if this has been widely adopted. 

Are two packages allowed to mutually import each other?  I can't find
anything preventing this in the spec, but was wondering if it causes
some kind of "infinite" import loop.

I only recently joined the OCL rtf at the request of David Frankel (who
is now with SAP) - I have not seen any activity on this mailing list as
yet so I hope this is an appropriate forum to raise this question.


First let me introduce myself - I am lead for a proof-of-concept project
investigating the use of OCL to express integrity constraints on models.
Hopefully I will get a chance next year to attend a f2f meeting so that
I can meet you all.


On to my specific question: we have noticed that some time between OCL
1.1 and UML 1.4 "oclType", as a predefined feature, was removed. (I have
been unable to find any versions of OCL between 1.1 and UML 1.4).


I thought it would be best if we found out whether this removal was
intentional before officially raising it as an issue. The reason is that
we find a) this is a useful reflective feature to have and 2) it is
still used in some current OMG specifications (note that it is used
inconsistently).
e.g.:
- UML2 Infrastructure - (ptc/03-09-15) pg.89:
        Classifier::maySpecializeType(c : Classifier) : Boolean;
                maySpecializeType = self.oclIsKindOf(c.oclType)


- Meta Object Facility (MOF) 2.0 Core Specification (ptc/03-10-04) -
pg.68
        ExtentImpl::addObject(ObjectInstance o, String suppliedId
[0..1]): String
        pre: not(self.entry.identifier includes suppliedId)
        post: oclIsNew(e) and oclType(e) = IdentifierEntry and
        e.object = o and
        self.entry includes e
        self.entry->select(ex | ex.identifier = e.identifier)->size() =
1 -- the new id is unique and
        (suppliedId <> null implies e.identifier = suppliedId)

Section 7.5.3 of ptc/05-06-06 starts with the following: "Starting from a specific object, we can navigate an association on the class diagram to refer to other objects and their properties. To do so, we navigate the association by using the opposite association-end:"
 
However, unlike in UML 1.x, in UML2 this may well be ambiguous (since names of ends owned by Associations only have to be unique within the Association and not within the context of the Class).
OCL should therefore explicitly allow qualification using the name of the Association itself as well as the end name (it is not clear whether this is currently allowed as part of the syntax for 'associationendname' so there should be an example to show this. This would make it consistent with the metamodel which allows reference to specific Properties.
 
For example we could have associations A1 and A2 both linking classes C1 and C2 and each with ends c1 and c2 owned by the respective associations.
OCL does not then address the fact that aC1.c2 is ambiguous - unlike the case with unnamed ends it does not even say that it may be ambiguous and is hence disallowed.
However rather than disallowing the navigation OCL should have a syntax to allow qualification by the association name
For example aC1.A1::c2
 
The same could be used for missing association end names: If A1 had unnamed ends then one could use aC1.A1::C2
 

In section 8.3.2 of ptc/05-06-06 PropertyCall is shown as a subclass of NavigationCallExp -this seems the wrong way round: NavigationCallExp seems to be a specialization for when the Property is an AssociationEnd. To illustrate this, the description of NavigationCallExp starts with the following, which would not apply if the Property in question were an ownedAttribute of a class:
"A NavigationCallExp is a reference to an AssociationEnd or an AssociationClass defined in a UML model."

We consider a Sequence of instances of a class called 'Example'. This class has an integer attribute called 'ex'. If we have a method specification written as follow: pre: datalist->isTypeOf(Sequence(Example)) post: Sequence{1..datalist->size()}->forAll(n | datalist->at(n).ex = datalist@pre->at(n).ex) I not sure if is correct writes the same specification with the next sentences: pre: datalist->isTypeOf(Sequence(Example)) post: datalist->forAll(n | n.ex = n@pre.ex) The generic questions is: What does the '@pre' operator mean when it is applied to iterators variables (as 'n' in the example)? Is correct the @pre use in this cases? I hope you understand my dude and sorry any gramatical error because my written english is very poor.

The abstract syntax defines the classes NullLiteralExp and InvalidLiteralExp but the concrete syntax does not define these literal values. --- I would like to return 'null' in certain OCL expressions for example: context Person::foo() : Person body: if age > 10 then self else null endif Currenty the only correct way to do this is not very straight forward: context Person::foo() : Person body: if age > 10 then self else OclVoid.allInstances()->any() endif The same is true for the singelton instance of OclUndefined. 

The spec states: ---- The operation oclInState(s) results in true if the object is in the state s. Values for s are the names of the states in the statemachine(s) attached to the Classifier of object. ---- How does this relate to the uml metamodell? A BehavioredClassifier may have several ownedBehaviors but only one(!) of those behaviors may be the behavior of the classifier himself. The other behaviors may be specifications for behavioral features of the classifier. ---- Clarification: Possible states for the operation oclInState(s) are all states of the statemachine that defines the classifier's behavior (property 'classifierBehavior' of the 'BehavioredClassifier' metaclass). 

Using "def" I would like to specify static (classifier scoped) properties and operations.

Hi, I'm reading through the latest OCL spec to get up to date before applying for a System Analyst job, I saw a possible minor issue in the list of the OCL keywords. Indeed, having read it so far, I would add the following ones but pls let me know if there is a reason why it wouldnt apply: body, derive, init, and self

Hello I recently wrote a comment about the OCL keyword list to amend if I'm correct. As I continue reading through the specification, I found that in "7.8 Resolving Properties", 2 inv contraints are specified and mentionned to have a different meaning. I specified the difference between the 2 below and was wondering if you wanted maybe to check that 1. it was correct and 2. add it to the specs so people can make sure they understand well where the difference stands, despite it is fairly straightforward from the explanation in this chapter. >From your specs: context Person inv: employer->forAll(employee->exists(p | p.lastName = name)) inv: employer->forAll(employee->exists(self.lastName = name)) Given explanation on the difference: Invariant constraint 1: Specifies that in the Company a person works for, there exists for all the employees of the company (Person instances) the value of their attribute lastName matching the value of the attibute Name in an instance of Company Invariant constraint 2: Specifies that in the Company a person works for, there exists for all the employees of the company (Person instances) the value of the person's attribute lastName matching the value of the attibute Name in an instance of Company iterator The difference is that in the invariant 1, we specify that the value of the lastName attribute for all the Person instances employed by a company must be found in an instance of the Company by matching the name attribute's value, whereas in the invariant 2, we specify that the value in the lastName attribute of a Person p working for a Company must match the value of the name's attribute in one of the Company's set of Person/employees, thus its related instance. I hope it makes sense and look forward hearing about your comments.

"The forAll operation has an extended variant in which more than one iterator 
is used. Both iterators..."


Which is it "more than one" (two, three...) or "Both" (two) ?

"The OCL specification puts no restriction on visibility."


I don't think this statement is true. For example, self is bound to the 
instance in context. There is a whole prior section on scoping. 

There is a left-paren in rule [A] . Rules [D] and [E] are identical.

"The type OclVoid is a type that conforms to all other types. It has one 
single instance called null which corresponds with the UML Null Literal value 
specification. "


This text could be clearer. What does "called null" mean? Is it saying that 
the name "null" refers to this instance? A suggested rewrite: "It has one 
instance, identified by 'null.' The instance null corresponds to the UML Null 
Literal."

11.2.4 (OclInvalid) - similar criticism as 11.2.3 (issue 10433)

"When new iterator expressions are added to the standard library, there 
mapping to existing constructs should be fully defines.


- What does that mean? It sounds like an admonition to spec writers.
- also "defined" not "defines"
- also "their" not "there"

oclIsTypeOf(typespec : OclType) : Boolean
"Evaluates to true if the self is of the type identifid by typespec.."
oclIsKindOf(typespec : OclType) : Boolean
"Evaluates to true if the self conforms to the type identified by typespec"


>From those descriptions I cannot distinguish these two. Isn't a dog "of the 
type" mammal" and wouldn't a dog "conform to the type" mammal? (Subtypes 
always conform to the supertype).


I suspect that you intend that one of these evaluates to TRUE if and only if 
self is of type typespec *and not also of a subtype of typespec* . You might 
say just that.

oclAsType(typespec : OclType) : T
"Evaluates to self, where self is of the type identified by typespec.
  post: (result = self) and result.oclIsTypeOf(typeName) 


(BTW , that ought to be "typespec" not typeName).


This description is inadequate. The text in 7.4.6 describes the important 
condition on the use of this method ("An object can only be re-typed to one 
of its subtypes.") But chapter 7 is informative, not normative. Even with 
that text moved into 11.2.5, additional discussion is required. For example, 
referring to the properties that are only defined on the subtype, what would 
the value of those properties be, once the object is re-typed?

 null "conforms to all other types." Thus I suppose null->isEmpty() and 
null->notEmpty() are defined. What do these methods evaluate to when applied 
to null? This should be discussed in this section.

Recommendation: The specification would be better were it to additionally 
describe a practical grammar useful to tool implementors and persons trying 
to understand what constitutes legal OCL syntax. Of course, we all know that 
even practical OCL grammars are permissive of strings that aren't meaningful 
(for example, 7->isEmpty() is typically legal) but more can be done than is 
expressed by the current description. I am not suggesting that you replace 
the current method of description, but that you add (perhaps only as an 
informative, non-normative appendix) a conventional grammar. The spec, after 
all, is supposed to serve the purposes of implementors. 


There are published papers describing practical grammars for OCL, or I can 
supply you with one, if you'd like. 


PS By "practical grammar" I mean one that limits the look-ahead to a finite 
number wherever possible. It is, of course, the use of OclExpression in the 
RHS of so many productions that runs up against the infinite look-ahead 
problem, and makes the published grammar unusable by implementors.

The Object Constraint Language (OCL) is an integral part of the Unified Modeling Language (UML) and is often used separately as a general constraint specification language in software development tools. For example, OCL is incorporated in the Generic Modeling Environment (GME) developed by the Institute of Software Integrated Systems (ISIS) of Vanderbilt University (http://www.isis.vanderbilt.edu/default.asp The GME implementation extends the OCL standard to include Regular Expressions. A Regular Expression is a pattern that describes (or matches) a set of strings where the pattern is itself a string and conforms to a specific syntax. Regular Expressions are ideal for expressing format constraints on OCL String values. Moreover, Regular Expressions are widely used, familiar to many software developers and complement the OCL’s already powerful constraint specification syntax. Unfortunately, Regular Expressions are not currently supported in OCL Version 2.0. Augmenting the OCL standard with Regular Expressions will improve OCL’s constraint specification capabilities for String values with a powerful, familiar notation and would also codify existing practice as manifested in tools such as GME. Please consider the inclusion of Regular Expression support in future releases of the Object Constraint Language (OCL) specification.

I find in the OCL document section "7.3.3. Invariants" that I can name an invariant  as in:
 
"context" <contextdeclaration> "inv" <constraintname> ":" ...
 
I haven't figured out how to parse the document well enough to be clear if this is formally defined.
 
And the real question is whether this applies to pre, post, body, init, and derived constraints.
 
Does it?  
 
If not it would be useful to add.

during work on the definition of the UML Profile for CIM (an activity
performed jointly between OMG and DMTF), we recently found the following
issue with OCL 2. Please record this issue officially and let me know the
issue number for it.



Issue: No explicit statement that ownership of association ends does not
matter for traversal in OCL
   Nature: Clarification
   Severity: Minor
   Summary:


      The UML Superstructure spec 2.1.1 defines in section 6.5.2 "Diagram
      Format" that any meta-association has two ends, regardless of whether
      the ends are owned by the association or the associated classifiers.
      However, the Superstructure spec only describes those association
      ends that are owned by the associated classifiers. Furthermore, a
      major OCL engine (from Eclipse) does not currently support
      meta-association traversal in OCL towards ends owned by the
      meta-association.


      This may leave the impression to some readers that OCL would only
      support meta-association traversal in the direction of ends owned by
      the associated classifiers.


      I understand that the intention is in OCL to support traversal of
      meta-associations in any direction, regardless of whether the target
      end is owned by the association or the associated classifier. It
      would be helpful to state that explicitly in the OCL specification.

I would like to log the following issue against OCL formal/06-05-01.


TypeType, appearing on Fig. 8.1 (p.34), Fig. 13.1 (p.172), and section
11.3.2 (p.140) is not defined

The OCL abstract syntax for Collections has no property to persist the element type
of the collection.


It is therefore not possible to serialise a TypeExp.referredType referring to
for example OrderedSet(String) without synthesising an
OrderedSet_String and finding some artificial scope for it .. and then encountering
ambiguities as to whether two distinct OrderedSet_String types are really distinct.


Suggest: 


Introduce a CollectionTypeExp extending TypeExp to add
        CollectionTypeExp.referredElementType : Type[0..1]
with the constraint that the inherited TypeExp.referredType be a collection type.

The OCL 2.0 spec seems to allow usage of initialization constraints
      and derivation constraints on the same property. For example in
      7.3.7, it says "Initial and derivation expressions may be mixed
      together after one context.", which is a string indication that it is
      not precluded. Having both initialization and derivation constraints
      is an overspecification of the initial value of the property, since
      the derivation constraint must be satisfied at any time, which
      probably includes the initialization time.


      Also, the spec does not seem to contain a statement about how many
      initialization and derivation constraints are allowed on a property.
      By the nature of these constraints, it seems sensible to have at most
      one of them.


      The following clarifications are suggested to address this issue:
         (1) clarify whether "at any time" for derivation constraints
         includes the initialization. Suggestion: Derivation should include
         initialization.
         (2) clarify whether both kinds of constraints are allowed on the
         same property. Suggestion: Both are allowed but must not be
         contradictory.
         (3) clarify how many initialization and derivation constraints are
         allowed on a property. Suggestion: At most one initialization
         constraint and at most one derivation constraint.

Thhis expression context TupleType inv: TupleType.allInstances()->forAll (t | ( t.allProperties()->forAll (tp | -- make sure at least one tuplepart has the same name -- (uniqueness of tuplepart names will ensure that not two -- tupleparts have the same name within one tuple) self.allProperties()->exists(stp|stp.name = tp.name) and -- make sure that all tupleparts with the same name conforms. self.allProperties()->forAll(stp | (stp.name = tp.name) and stp.type.conformsTo(tp.type)) ) implies self.conformsTo(t) ) ) should be context TupleType inv: TupleType.allInstances()->forAll (t | ( t.allProperties()->forAll (tp | -- make sure at least one tuplepart has the same name -- (uniqueness of tuplepart names will ensure that not two -- tupleparts have the same name within one tuple) self.allProperties()->exists(stp|stp.name = tp.name) and -- make sure that all tupleparts with the same name conforms. self.allProperties()->forAll(stp | (stp.name = tp.name) implies stp.type.conformsTo(tp.type)) ) implies self.conformsTo(t) ) ) it means "implies" instead of "and" in this part: (stp.name = tp.name) and stp.type.conformsTo(tp.type)

missing closing parethesis inthese two expressions: [2]The parameters of the referredOperation become attributes of the instance of MessageType. context MessageType: inv: referredOperation->size()=1 implies Set{1..self.ownedAttribute->size()}->forAll(i | self.ownedAttribute.at(i).cmpSlots( referredOperation.ownedParameter.asProperty()->at(i)) [3]The attributes of the referredSignal become attributes of the instance of MessageType. context MessageType inv: referredSignal->size() = 1 implies Set{1..self.ownedAttribute->size()}->forAll(i | self.ownedAttribute.asOrderedSet().at(i).cmpSlots( referredSignal.ownedAttribute.asOrderedSet()->at(i))

I have an issue with OclAny::allInstances() method, as described in the
11.2.5 section of the OCL2 spec (06-05-01.pdf).


If I understand correctly, OCL is a statically typed language (e.g. as stated
in the beginning of 8.2 section or 8.3 section OclExpression paragraph).
Every expression has a type and this type can be statically determined by
analyzing the expression and its context.


Most of the concepts in the OCL spec follows this rule, however I have 
an issue with the allInstances() method, defined on OclAny. Specifically,
the "Returns all instances of self. Type T is equal to self." statement is problematic.


When allInstances is used on the literal type specifier, there is no problem.
E.g.


context classFoo inv:
somepackage::classBar.allInstances()->size() < self.limit


Here, return type of the expression "somepackage::classBar.allInstances()" can be determined
by static analysis ("at compile time") - it is Set(classBar). 



However when allInstances is invoked on variable, calculated by some expression,
and all the staticallity of OCL crumbles and the hell breaks loose :D.
And there are no restrictions, on what objects allInstances() can be invoked, the only rules are
that the object to be classifier and the instance set be finite.


E.g.
(singleton rule - all the classes must have at most 1 instance)
context Class inv:
self.allInstances()->size() <= 1


Now, what is the type of the self.allInstances() expression? Well, it depends on what is the self object - 
and self object is supplied at run time. If we evaluate this constraint on classFoo, 
we see that type of "self.allInstances()" must be Set(classFoo), if we evaluate this constraint on
classBar, type of expression must be Set(classBar). Hence the type of expression can not be determined
at "compile time", it must be determined at "run time". 


E.g. we have 2 classes classFoo and classBar; classFoo has a field someField, classBar doesn't.


context whatever inv:
let s:Set(Classifier) = Set{classFoo, classBar} in
s->allInstances()->any(true)->any(true).someField = someValue


Now what is the type of s->allInstances()->any(true)->any(true) expression?
We have:
expression                              |expression type        |expression value
---------------------------------------------------------------------------------
s                                       |Set(Classifier)        |Set{classFoo, classBar}
s->allInstances()                       |Set(Set(???))          |Set{ Set_of_instances_of_classFoo, Set_of_instances_of_classBar}
s->allInstances()->any(true)            |Set(???)               |either Set_of_instances_of_classFoo or Set_of_instances_of_classBar
s->allInstances()->any(true)->any(true) |????                   |either instance of classFoo or instance of classBar


Now the question arises: can we access someField property?
Here we must have a runtime introspection check in the OCL evaluation code -
if s->allInstances()->any(true)->any(true) returned instance of classFoo,
we can access the field, if instance of classBar - we must runtime-fail here.



Please advise. Is this a problem of the spec or I am wrong somewhere?



Granted, we are making jumps 2 levels down in metamodel hierarchy here
(first from metamodel to model elements-classes, then from classes to instances of those classes),
but there is nothing in the spec, what precludes this.

The operator precedence rules in 9.3.2 are identical to the precedence rules in 7.4.7. Both sets are incomplete in that they do not specify the precedence of the 'let' operator. For example, in a UML profile, a constraint on a 'Property' stereotype might be: not self.base_Property.allNamespaces()->exists(oclIsKindOf(Profile) or oclIsKindOf(Stereotype)) implies let prop:Property=self.base_Property in prop.defaultValue->isEmpty() To parse properly (with RSA 7.0.0.2), this constraint must instead be written as: not self.base_Property.allNamespaces()->exists(oclIsKindOf(Profile) or oclIsKindOf(Stereotype)) implies (let prop:Property=self.base_Property in prop.defaultValue->isEmpty()) This suggests that the 'let' operator has a lower precedence than that of the 'implies' operator. Of course, there is an alternative way to write this constraint that does not expose this issue: let prop:Property=self.base_Property in not prop.allNamespaces()->exists(oclIsKindOf(Profile) or oclIsKindOf(Stereotype)) implies prop.defaultValue->isEmpty() The suggestion is to revise 7.4.7 and 9.3.2 to account for *all* keywords in 7.4.9. The keywords defined in 7.4.9 but not accounted for in 7.4.7 or in 9.3.2 are: - attr - context - def - endpackage - in - inv - let - oper - package - post - pre The keywords referenced in 7.4.7 or in 9.3.2 that are *not* defined in 7.4.9 are: - @pre Nicolas F. Rouquette Principal Computer Scientist http://www.jpl.nasa.gov Jet Propulsion Laboratory, Caltech M/S 301-270 Pasadena, CA 91109, USA phone: +1-818-354-9600 fax: +1-818-393-4100 e-mail: nicolas.f.rouquette@jpl.nasa.gov

For the InvalidType it is stated that: "The only instance of InvalidType is Invalid, which is further defined in the standard library. Furthermore Invalid has exactly one runtime instance called OclInvalid." It should read: "The only instance of InvalidType is OclInvalid, which is further defined in the standard library. Furthermore OclInvalid has exactly one runtime instance called invalid." because this is in line with ch. 11.2.4, p. 138:"It [OclInvalid] has one single instance called invalid. [...] OclInvalid is itself an instance of the metatype InvalidType

The abstractness of CollectionType and corresponding existence of the Collection CollectionKind is inconsistent:
--
9.3 collectionTypeCS synthesized attributes, page 79, contains:


kind = CollectionKind::Collection implies collectionTypeCS.ast.oclIsKindOf(CollectionType)


using CollectionKind::Collection.
--
8.3.5 CollectionKind, page 48, Collection is not one of the enumeration values.
--
11.6.1, page 144, specifies that Collection is an instance of CollectionType
requiring Collection to not be abstract.
--
8.2 CollectionType, page 34, CollectionType is identified as an abstract class.
--
An expression like the following is valid:


  context Package
  def getClasses() : Set(Class) =
    let c : Collection(Type) = self.ownedType in
      c->select(oclIsKindOf(Class))->asSet()


and demonstrates the need for a concrete CollectionType.
--
Recommendation:


Collection should not be abstract; change Fig 8.1, 8.2 CollectionType text.
CollectionKind requires a Collection value; change Fig 8.7, 8.3.5 CollectionKind.