Issue 8902: Section 8.3.9 of the final Adopted Version of the OCL 2.0 Spec
Issue 8917: allInstances
Issue 8918: Navigating across non navigable associations
Issue 8922: Section 8.3.9 of the final Adopted Version of the OCL 2.0 Spec
Issue 8937: Notation for accessing class operations is inconsistent
Issue 8982: Circular imports
Issue 9171: Introduction and oclType()
Issue 9404: inability to uniquely reference association ends
Issue 9405: Wrong subtyping of PropertyCallExp and NavigationCallExp
Issue 9796: Section: 7.3.4
Issue 9913: Section: 8.3.5
Issue 9914: Section: 7.5.9
Issue 9915: Using "def"
Issue 10344: Section: 7.4.9
Issue 10346: Section: 7.8
Issue 10430: Section 7.6.3
Issue 10431: Section 9.2.2
Issue 10432: Section "IteratorExpCS"
Issue 10433: 11.2.3
Issue 10434: 11.2.4 (OclInvalid) - similar criticism as 11.2.3
Issue 10435: 11.8.1
Issue 10436: 11.2.5
Issue 10437: 11.2.5 (02)
Issue 10438: 11.7.1
Issue 10439: Recommendations re ptc/2005-06-06
Issue 10561: inclusion of Regular Expression support
Issue 10782: Naming of Constraints in OCL
Issue 10825: ownership of association ends does not matter for traversal in OCL
Issue 10921: TypeType
Issue 10946: Collection element type serialization
Issue 10969: Usage of initialization and derivation constraints on the same property
Issue 11085: 8.2.2 Well-formedness Rules for the Types Package
Issue 11086: missing closing parethesis inthese two expressions
Issue 11097: Dynamic typing with allInstances()
Issue 11098: Section: 7.4.7, 7.4.9, 9.3.2
Issue 12378: Section 8.2 InvalidType
Issue 12419: CollectionType and CollectionKind
Issue 12438: last line on page 28
Issue 12439: Section: A/1.1.1 Types
Issue 12440: Section: A/1.1.5 Associations
Issue 12441: Section: A/1.1.5 Associations -- missing word
Issue 12442: Section: A/1.1.5 Associations
Issue 12443: Section: A/1.1.6 Generalization
Issue 12444: Section: A/1.1.6 Generalization - editorial issues
Issue 12445: Section: A/1.2.1 Objects
Issue 12446: Section: A/1.2.4 System State
Issue 12447: Section: A/2.2 Common Operations on All Types
Issue 12448: section 7.4.6 (p. 12)
Issue 12449: no explanations about how to manipulate optional and multivalued attributes
Issue 12450: The Tuple constructor is problematic
Issue 12451: OrderedSet collection
Issue 12452: Recursivity is not explicitly addressed with examples
Issue 12453: Mismatch between the definition of operators in, e.g., Section 11.7.1 and i
Issue 12454: The constraint [1] on the TupleLiteralPart metaclass is overconstrained
Issue 12456: Errors in examples
Issue 12457: Section: A/2.3 Enumeration Types
Issue 12458: Section: A/2.3 Enumeration Types -- editorial
Issue 12459: Section: Definition A.23 (Semantics of Navigation Operations)
Issue 12460: Section: A.2.5.2 Definition A.24 (Type Expressions)
Issue 12461: Section: A.2.5.5 Collection Operations
Issue 12464: Section: A/2.5.5 Collection Operations - just before table A.3
Issue 12468: Section: A/2.5.5 Collection Operations - Table A.3
Issue 12469: A.2.5.5 Collection Operations
Issue 12470: There are two instances of missing and misplaced parentheses
Issue 12471: Section: A.2.5.6 Set Operations
Issue 12472: Section: A.2.5.6 Set Operations Table A.4
Issue 12473: Section: A.2.5.8 Sequence Operations
Issue 12474: Section: A.3.1.1 Syntax of Expressions
Issue 12475: Section: A.3.1.1 Syntax of Expressions
Issue 12476: Section: A.3.1.1 Syntax of Expressions (Definition A.29)
Issue 12477: Syntax of Expressions (second sentence after Definition A..29)
Issue 12478: Section: A.2.6 Special Types
Issue 12479: Section: A.2.6.1 Definition A.26 (Special Types)
Issue 12484: Section 8.2.1 Type Conformance on page 37
Issue 12485: Section 8.2 page 35 InvalidType
Issue 12486: Section: A.2.7 Type Hierarchy
Issue 12487: Section: A.3.1.1 Syntax of Expressions
Issue 12488: Section: A.3.1.2 Semantics of Expressions
Issue 12489: Section: A.3.1.2 Semantics of Expressions, Definition A.30 part ii
Issue 12490: Section: A.2.5.8 Sequence Operations
Issue 12491: Section: A.3.1.2 Semantics of Expressions
Issue 12493: Section: A.3.2.2 Syntax and Semantics of Postconditions
Issue 12494: Section: A.3.2.2 Syntax and Semantics of Postconditions (02)
Issue 12495: Section: A.3.2.2 Syntax and Semantics of Postconditions (03)
Issue 12496: Section: A.3.2.2 Syntax and Semantics of Postconditions (04)
Issue 8902: Section 8.3.9 of the final Adopted Version of the OCL 2.0 Spec (ocl2-rtf)
Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary: 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"(?).
Resolution:
Revised Text:
Actions taken:
June 7, 2005: received issue
Issue 8917: allInstances (ocl2-rtf)
Click here for this issue's archive.
Source: SAP AG (Mr. David S. Frankel, david.frankel@sap.com)
Nature: Uncategorized Issue
Severity:
Summary:
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.
The last line on page 28 is an example in Java-like code that is supposed to show the accumulation of values into a Bag. The line currently is acc = <expression-with-elem-and-acc> Since such an assignment would not add to the Bag, but more likely produce a compile error in Java, I would think use of the common method name "add" would be more appropriate: acc.add(<expression-with-elem-and-acc>);
The following grammatically incorrect sentence is present in the document: All type domains include an undefined value that allows to operate with unknown or “null” values. This could be corrected in various ways, a couple of which would be: All type domains include an undefined value that allows one to operate with unknown or “null” values. or All type domains include an undefined value that allows operations with unknown or “null” values.
The next to last line of Definition A.4 begins, "that associates (sa) = <oc, c>." I think this should read instead, "that associates (sa) = <c, c>." If I am mistaken, then a note to remind the reader what "oc" means would be helpful, as would a note describing why the classes are not the same.
Between the definitions of "participating" and "navends" is a sentence that, "The following function navends give ...." The s is missing on "gives". It should instead read, "The following function navends gives ...."
In the definition of "navends" the symbol for "and", which was a nice looking capital lambda in previous definitions, is here a more traditional, at least in my mind, "and" sign. Consistency would be nice
At the top of page 182 there are 3 definitions, all of which have the index domain, i.e. C' an element of parents(c), in the wrong place horizontally. In the first two it appears to be associated with the small union symbol, rather than with the large one as it should be. In the third it seems not to be associated with anything in particular. Additionally, in the first line on the page there is an extraneous underscore in the name of the object of the first definition.
In WF-1 there is an "is an element of" sign missing just before the "ATT" in the first line. In WF-2, at a minimum, the first small omega should have a t-sub-1 a bit after it so that the sameness of arguments from t-sub-1 through t-sub-n is clear for both small omegas. Also the second colon is on the wrong side of the small omega. On the other hand, I'm not sure why you don't write it in the same form as WF-1, since it's a similar statement. I hope you can interpret my attempts to get by without sub and superscripts. Since the reader has already waded through WF-1, wouldn't it be more useful like this? ? (? : tc x t1 x …x tn ? t, ?' : tc' x t1 x …x tn ? t' ? OP*c) : (? = ?' => tc = tc' ? t = t')
In Definition A.10 Object Identifiers, part ii, you have the domain of a class c defined as: ICLASS(c') = U{oid(c) | c' ? CLASS ^ c' "gr<" c}. where I've used "gr<" for the generalization relation. I see 4 things that ought to be changed: 1. The initial c' should obviously be a c. 2. The oid(c) should be oid(c') 3. We have still another symbol for "and" 4. There's an extraneous newline before the final c.
Definition 1.12 (System State) ends with "(the function pi(l) projects the ith component of a tuple or list l, whereas the function pi(l) projects all but the ith component):" Obviously the same notation can't mean opposite things, but what was intended here I don't yet know. Perhaps I will as I read on, but I thought I'd report this typo now so I don't forget.
This is another omission of the word "one", making the sentence grammatically incorrect. It is also useful to have an operation that allows to check whether an arbitrary value is well defined or undefined. should be "... allows one to ...." or "... allows the checking of whether ...."
In section 7.4.6 (p. 12) it is said "An object can only be re-typed to one of its subtypes; ... If the actual type of the object is not a subtype of the type to which it is re-typed, the expression is undefined" While in section 7.5.8 (p. 19) it is said Whenever we have a class B as a subtype of class A, and a property p1 of both A and B, we can write: context B inv: self.oclAsType(A).p1 -- accesses the p1 property defined in A self.p1 -- accesses the p1 property defined in B and thus an example is shown where an object is retyped to its supertype. Both sections 7.4.6 and 7.5.8 should be joined into one. See slide 32 in my handouts to see a possible abstract of the joined section.
There are no explanations about how to manipulate optional and multivalued attributes. On the other hand optional and multivalued associations are discussed in detail. For example, while I can use context Person inv: self.job->notEmpty() implies ... to test "whether there is an object or not when navigating the association", I do not know how do a similar test for optional attributes. Is it context Person inv: self.maidenName <> `' implies ... or context Person inv: self.maidenName -> notEmpty() implies ... ?
The Tuple constructor is problematic. It is not a first-class citizen in the specifications. It appears in many parts but it is not formally introduced.
The OrderedSet collection is a later adjunction with respect to previous versions of OCL. However, it has not been systematically introduced in all relevant places. As one example among many, conformance rules in Table 7.3 (p.12) do not include OrderedSet. Also, the semantics defined in Appendix A should be extended to include OrderedSet. By the way, there is no place where the difference between OrderedSet and Sequence is discussed. From my understanding, they are much like the same concept. If it is not the case, the differences must be explicitly stated.
Recursivity is not explicitly addressed with examples, although it is mentioned in several places. For example, in p. 16 it is said "The right-hand-side of this definition may refer to the operation being defined (i.e., the definition may be recursive) as long as the recursion is not infinite." I my course I have put the following example (slide 19) A method that obtains the direct and indirect descendants of a person context Person::descendants(): Set body: result = self.children->union( self.children->collect(c | c.descendants()) ) But there is no way to verify whether the above definition, although conceptually correct, is OK with respect to OCL's syntax. Similarly, the same problem arises with recursive association classes, which is covered in Section 7.5.4. I have covered this in my course in slides 29-30 A person is currently married to at most one person context Person inv: self.marriage[wife]->select(m | m.ended = false)->size()=1 and self.marriage[husband]->select(m | m.ended = false)->size()=1 Operation that selects the current spouse of a person context Person::currentSpouse() : Person pre: self.isMarried = true body: if gender = Gender::male self.marriage[wife]->select(m | m.ended = false).wife else self.marriage[husband]->select(m | m.ended = false).husband end However, I suppose that the syntax for the operation currentSpouse is OK with respect to OCL's syntax, although it is not specified explicitly.
Mismatch between the definition of operators in, e.g., Section 11.7.1 and in Table A.3: product operation is missing in the latter. By the way, there are many printing problems in this table. Similar mismatch: flatten operation is specified for Sets (p. 147) for Bags (p. 151) and for Sequences (p. 152) but are not mentioned in the corresponding tables in Annex A. By the way, whey flatten is not specified for OrderedSets? Why several methods specified for Sets and Bags (union, intersection, etc.) but not for OrderedSets?
The constraint [1] on the TupleLiteralPart metaclass is overconstrained. It requires that the type of the value of a tuple literal part be identical to the corresponding attribute of the tuple type. However, the value type should only be required to conform to the attribute type because tuple literals may optionally specify the part types (in the same fashion as variable declarations). Thus, a more appropriate formulation of this constraint would be: context TupleLiteralPart inv: attribute.type.conformsTo(value.type )
The examples are based on the sample model (Companies and Employees). However, as pointed out in http://www.empowertec.de/products/analyze-spec-expressions.htm there are many errors in the examples. You will find at the address http://cs.ulb.ac.be/oclnotes.pdf the slides that I use in my course in which I slighty modified the example so that all example expressions are (supposed to be) correct.
This may be simply my misunderstanding of what is intended. In the final sentence before Definition A.18 (Semantics of Enumeration Types), the word "interpreted" seems inappropriate. "Defined" is often used in such sentences is mathematics. I just wanted to draw attention to this in case it is a mistake. If not then my apologies
The last sentence of the page is missing the word "one" or, alternately, proper forms of the verbs "to follow" and "to retrieve". A correct form of this sentence would be, "Navigation operations: An object may be connected to other objects via association links. A navigation expression allows one to follow these links and to retrieve connected objects."
Maybe I misunderstand, but it seems to me that L(as)(ci), as defined, has some problems: 1. "(c1, . . . , c i, . . . , c j , . . . , c n )" is undefined in that one doesn't know what it is, and 2. c is undefined in "sCLASS(c)". It seems to me that what you want is "L(as)(ci) = {cj | i ? j ? (c1, . . . , ci, . . . , cj , . . . , cn ) ? I-sub-ASSOC(as)}" - where the characters following the c's are subscripts and each such combination should be underlined to show that it is an object, - and where I-sub-ASSOC(as) is an italic I with a subscripted "ASSOC(as)".
This may not have been a problem with earlier versions of Adobe Acrobat/Reader but in looking at this section I see two typographical representations of "T-hat". The first two occurances are the letter T followed by a small circumflex substript. Subsequent occurances are a large circumflex followed by the letter T. It would be nice if this were fixed to be consistent, and even nicer if the circumflex could be placed over the T, as I imagine was intended.
The 5th word of this section is "of" but was probably meant to be "on". Also, in Table A.3 in this section the entry in the second row, third column is pretty much unreadable because there are so many symbols written on top of each other. I checked this with Internet Explorer as well as Firefox, in case they affected Adobe Acrobat, but the entry looked equally bad in both.
Just before Table A.3, is a sentence, "For this purpose, C, C, C2 ...." The second "C" should have a subscript "1" and the "C2" should have the 2 as a subscript.
Table A.3 has several problems in the "Semantics" column: Row 2: Besides being hard to read, the expression seems to be wrong. There is no operator between the C and capital pi (which I assume to be a Cartesian product), and the "is not an element of" seems like it couldn't be right. Maybe I'm at fault, but I can't make any sense of it. Row 4: There's no entry here. How about " C 'intersect' {v} = Ø" Row 6: The operator should be intersection, not Cartesian product, that is the capital pi should is the wrong symbol here. Rows 8 & 9: First, there shouldn't be anything in row 9's semantics column since the other columns are all blank. Are the c's supposed to be the capital C's? I can't make any sense of the expression, which could be my problem, but I don't think so.
In the paragraph under table A.3, toward the end, it says, "... count : Set(t) _ t ! Integer ...." These are the wrong symbols, of course. The underscore should be a cross and the ! should be an arrow. Also, just below this is the definition of I(count). This contains a 2 that should be a 0.
There are two instances of missing and misplaced parentheses. One is near the bottom of page 195 in the definition of I(count). The line begins, "I(count : Bag)(t) x t ? Integer)". That last closing paren does not match anything. I believe the line should instead begin "(I(count) : Bag(t) x t ? Integer) The other is at the top of page 196. It is currently "I(count : Collection)(t) x t ? Integer)(c,v)" and, I believe, should be "(I(count) : Collection(t) x t ? Integer)(c,v)"
The second sentence of this section ends, "... B is a value of type t.". It should say "... B is a value of type Bag(t).
Table A.4 has several rows in the Semantics column where a "union" symbol is used where an "intersection" symbol should have been used. These are rows 3, 4, 5, and 6. Table A.5 of section A.2.5.7 has the same problem in rows 3 and 4.
There is one error in Table A.6 in the semantics column for the operation "first". The index should be 1, not i.
Definition A.29 (Syntax of Expressions), part iii, b ends with, "and e2 to en the arguments." Here the 2 is a subscript as it should be but the "n" in "en" should also be a subscript and isn't.
Definition A.29 (Syntax of Expressions), part v, appears to have several problems: 1. The symbol used for generalization is not what has always been used previously, see the two previous symbols in Definition A.10 part ii and in section A.1.2.2 just after it. 2. the first expression after the word "then", namely "(e asType t’) ? Exprt’" lacks a comma after it to separate it from the following expression. 3. I'm puzzled by the restrictions that t and t' must be related one way on the other. The restriction isn't strong enough to keep (e asType t’) from being undefined and seems unneeded for isTypeOf and isKindOf. A note here about this might help the reader. It would sure help me.
Definition A.29 (Syntax of Expressions), part vi reads it part, "... v1 ? Vart1, v2 ? Vart2, and ...." The first comma is a subscript along with the "t1" before it, the second one, that follows the "t2" subscript, isn't. Neither should be.
The second sentence after Definition A.29 is "For all t’ < t: if e ? Exprt’ then e ? Exprt’ ." The last prime should be removed.
The third bullet ends, "... as ? is an instance of every type." I don't know if the ? stands for OclAny, which isn't a member of the collection classes and so unlikely, or if ? is meant rather than ?. So I think this is an error.
At the very end if this section it says "I(undefined) = ?." Shouldn't that be "I(undefined) = {?}."? Definition A.14 says the semantics maps each type to a set.
Section 8.2.1 Type Conformance on page 37 [1] Invalid conforms to all other types. context InvalidType inv: Classifier.allInstances()->forAll (c | self.conformsTo (c)) on page 38 [1] Void conforms to all other types. context VoidType inv: Classifier.allinstances()->forAll(c | self.conformsTo(c)) on page 37 [6] The Conforms operation on Types is anti-symmetric context Classifier inv: Classifier.allInstances()-> forAll(12,t2 | t1.conformsTo(t2) and t2.conformsTo(t1) implies t1 = t2) The first invariant yields Classifier.allInstances()->forAll (c | OclInvalid.conformsTo (c)) and thus OclInvalid.conformsTo (OclVoid) The second invariant yields Classifier.allInstances()->forAll (c | OclVoid.conformsTo (c)) and thus OclVoid.conformsTo (OclInvalid) Now the third invariant implies: OclInvalid = OclVoid
InvalidType represents a type that conforms to all types. The only instance of InvalidType is Invalid, which is further defined in the standard library. Furthermore Invalid has exactly one runtime instance called OclInvalid. should be replaced by InvalidType InvalidType represents a type that conforms to all types. The only instance of InvalidType is OclInvalid, which is further defined in the standard library. Furthermore OclInvalid has exactly one runtime instance called invalid. This would follow the naming conventions and be in line with the notation for VoidType, OclVoid, null.
The first two sentences of Definition A.27 (Type Hierarchy) seem to have errors in them. The relation "less than or equal" seems to be represented by an underscore in the first sentence. In the second sentence 2 is used where the "is an element of" symbol was intended, 0 is used where a prime mark is intended, and c simply follows t and t0 (t prime) rather than being a subscript as intended.
Definition A.29 (Syntax of Expressions)part iii, (b) ends, "...and e2 to en the arguments." The n in "en" should be a subscript but is not.
Some problems with Definition A.30: 1. In the second sentence of Definition A.30 (Semantics of Expressions) it says, "I[[ e ]] : Env ? I(t)" but it seems instead that "I[[ e ]] : Exprt ? (Env ? I(t)). 2. It appears that r, which is not defined anywhere, is really supposed to be p. p, which is defined, only appears in part iv and it appears to be r there. 3. Also, it's confusing to use w in parts iii and iv since small omega (or script w maybe) is used previously. Further clarity would be added by putting empty parenthenes after omega in part iii to emphasize the fact that there are no arguments
Definition A.30, part ii says "I[[let v = e1 in e2]](r) = I[[e2]](s, ß{v / I[[e1]](r)})." Maybe the problem is my ignorance of the meaning of the / in that expression as well as the meaning of the notation "ß{...}". I would have expected instead something like, "... = I[[e2]](s, ß U {v = I[[e1]](r)})."
In the flattening expressions there are the expressions "C1 fg" and "Bag fg". These seem to stand for the creation of a new, empty collection and bag respectively. If these expressions are what was intended it would be nice to have a note explaining what they mean. I wasn't able to find any explanations or previous use of "fg".
It would be nice to have a definition of ß{x / y) in association with Definition A.30. Maybe it's defined elsewhere, but I don't see it. From what's written in this section, including the explanation of iteration on page 205 and 206, I get only a vague idea. P.S. So realizing now that this is not a typo, my revision request two previous to this (if I've counted correctly) should be ignored. That was the one about part ii of Definition A.30.
In the paragraph before Definition A.32 you will find, "An environment p = (s, ß is a pair ...." The closing paren. after ß is missing
In the paragraph before Definition A.32 you will find, "... ppre = (spre, ßpre) describing a system state and variable assignments before the execution ...." Originally I had taken the ß's to be sets of assignments. Then I noticed that the text before this point refers to it repeatedly as an "assignment" in the singular. Now, here, and also in the middle of page 205 (which says, "ß' := ß{p1/I[[ e1 ]](r), . . . , pn /I[[ en ]](r)}.") the indication is that beta is multiple of assignments. Consistency would be very desirable.
At the beginning of Definition A.32 you will find the sentence, "The semantics of an expression e ? Post-Exprt is a function I[[ e ]] : Env x Env ? I(t)." It doesn't seem that this can be right since the argument to I[[.]] is an element of Post-Expt-sub-t. So, similarly to Definition A.30, I would suggest that something akin to "I[[ e ]] : Post-Exprt ? (Env x Env ? I(t))" would be more appropriate.
In the paragraph before Definition A.33 we have, "We say that a precondition P satisfies a pre-environment rpre – written as rpre |= P –....". In the explanation of Definition A.33 we have, "...the pre-environment rpre satisfies the precondition P....". One of these must be backwards. Does the environment satisfy the condition (2nd above) or does the condition satisfy the environment (1st above)?