Issue 1790: Lack of features commonly used in OCL
Issue 3513: OCL: Usage of qualifiers
Issue 4451: Downcast OCL collection operators
Issue 5970: OCL 2: flatten
Issue 5971: OCL 2: OrderedSet
Issue 5973: OCL 2: what is a collection?
Issue 5974: OCL 2: String operations
Issue 6528: Provide access to the sender of a message
Issue 6529: oclIsNew for a collection
Issue 6530: status of objects and tuples
Issue 6532: Consider OclType as a powertype
Issue 6533: Template return types in operation signatures
Issue 6534: Up- and Down-casts with oclAsType().
Issue 6535: Lack of operation specifications
Issue 6536: Additional annotations in the OCL Standard Library
Issue 6538: Exception of strict evaluation (implies)
Issue 6539: Exception of strict evaluation (forAll, exists)
Issue 6540: Exception of strict evaluation (queries)
Issue 6541: Exception of strict evaluation (=)
Issue 6544: Operator precedence
Issue 6546: Undefined values, isEmpty() and Collections
Issue 6547: Incomplete and missing well-formedness rules
Issue 6548: Satisfaction of Operation Specifications
Issue 6549: Satisfaction of Operation Specifications (2)
Issue 6550: Satisfaction of Operation Specifications (3)
Issue 6551: Add select/reject/collectNested to Collection
Issue 6552: Clarify definition of collectNested for Set, Bag, and Sequence
Issue 6553: Clarify the semantics of forAll
Issue 6554: Clarify the UML semantics of IfExpEval
Issue 6555: Missing equality and inequality operations on collection types
Issue 6556: Reintroduce allAttributes operator
Issue 6557: Introduce a "tuplejoin" operator
Issue 6559: Issue: Virtual machine
Issue 6560: Issue: Set of characters
Issue 6561: Issue: Unspecified syntax and semantics for Integer, Real, and String
Issue 6562: Issue: Keywords
Issue 6563: Issue: Comments
Issue 6564: Issue: Operator precedence
Issue 6565: Issue: Grammar of OCL
Issue 6566: Issue: Abstract syntax tree
Issue 6571: Issue: Syntax of Operation Call, Iterator, and Iterate Expressions
Issue 6572: Issue: Parsing Tuple Types and Collection Types as Arguments
Issue 6573: Issue: OclAny operations of tuples and collections
Issue 6574: Issue: Signature of Environment
Issue 6600: The index seems incomplete
Issue 6601: compliance points strategies
Issue 6609: OclUndefined / allInstances() clarification.
Issue 6611: OclUndefined = OclUndefine ?
Issue 6614: Example with TupleType
Issue 6615: Keywords "attr" and "oper"?
Issue 6879: The notation for testing the type of a metaclass is too verbose
Issue 6880: The notation for selecting elements should be more intuitive
Issue 6881: notation for selecting unique element within a list should be more concise
Issue 6882: There is no simple way to invoke an "if then else" on a collection
Issue 6883: The notation when nesting "if then else" is too verbose
Issue 6884: The notation when nesting "if then else" is too verbose
Issue 6885: Improve the notation when defining local variables
Issue 6886: Allow applying iteration operations on single objects
Issue 6887: Allow implicit type casting to boolean when a boolean is expected
Issue 6888: Use the "null" keyword instead of verbose "OclUndefined".
Issue 6889: Automatic casting between strings and enumeration values
Issue 6890: Suppress the usage of an Ocl prefix in standard library operations
Issue 6891: Allow defining standard library functions
Issue 6892: Allow defining default values for parameters in operations
Issue 6893: Provide specific notational support when testing stereotypes
Issue 6894: Add a generic text formatter operator '%
Issue 6895: Make usage of tuples less complex and less verbose
Issue 7341: section 7.4.6 (Re-typing or casting) on p.13
Issue 7455: Add an import statement to OCL files (with package - endpackage block)
Issue 7457: Add a concrete syntax to allow OCL users to add additional IteratorExp’s
Issue 7463: plus (infix) operator (’+’)
Issue 7464: tostring operation for Integer, Real and Boolean
Issue 7466: rewrite well-formedness
Issue 7470: The type of body expression must conform to declared type of result variabl
Issue 7475: 7. context AttrubuteCallExp
Issue 7476: collection literal expression
Issue 7477: The type of the condition of an if expression must be Boolean.
Issue 7478: iterator
Issue 7479: result type
Issue 7480: 1] The type of the source expression must be a collection.
Issue 7481: type of each iterator var. must be type of the elements of source collectio
Issue 7482: parameters of the operation.
Issue 7483: attributes of the signal.
Issue 7485: 5] The target of an OCL message cannot be a collection.
Issue 7486: forall’ should be ’forAll’
Issue 7487: the property ’refParams’ is not present in OperationCallExp
Issue 7488: ’parameter’ should be ’Parameter’
Issue 7489: message is a call action,
Issue 7490: message is a send action,
Issue 7491: type of a TupleLiteralExp
Issue 7492: tuple literal expression
Issue 7493: The type of the attribute is the type of the value expression.
Issue 7494: type of a TupleLiteralExp
Issue 7495: context TTupleType::make(atts : sequence(Attribute) ) : TTupleType
Issue 7496: "Bag"
Issue 7498: context TTupleType::...
Issue 7499: context Classifier
Issue 7500: context Classifier (02)
Issue 7501: context Operation
Issue 7502: context Parameter::asAttribute(): Attribute
Issue 7503: context State::getStateMachine() : StateMachine
Issue 7504: context VariableDeclaration::asAttribute() : Attribute
Issue 7505: parameters of the referredOperation
Issue 7506: parameters of the referredOperation
Issue 7507: An additional attribute refParams lists all parameters of the referred
Issue 7508: 1] The type of the attribute is the type of the value expression.
Issue 7509: context LocalSnapshot
Issue 7510: outgoingMessages results in the sequence of OclMessageValues
Issue 7511: context IfExpEval inv:
Issue 7512: sub evaluations (in the sequence bodyEvals)
Issue 7513: sub evaluations (in sequence bodyEvals) have different environment.
Issue 7514: ocl message expression
Issue 7515: isSent attribute
Issue 7516: add ’and’ between both expression parts
Issue 7517: result value of an association class call expression evaluation
Issue 7518: value of an association end call expression evaluation
Issue 7519: missing ’inv:’ twice
Issue 7520: an iterate expression evaluation
Issue 7521: arguments
Issue 7522: inv: model.sentSignal->size() = 1 implies arguments of the return message of an ocl message expression
Issue 7523: arguments of the return message of an ocl message expression
Issue 7524: Only one of the attributes isPost and isPre may be true at the same time.
Issue 7525: ’element’ should be ’elements’
Issue 7526: ’element’ should be ’elements’ (02)
Issue 7527: ’Element’ should be ’NameValueBinding’
Issue 7528: history of an object is ordered.
Issue 7529: The history of an object is ordered.(02)
Issue 7530: The operation allPredecessors
Issue 7531: elements in a tuple value
Issue 7532: value of an association class call expression
Issue 7533: result value of an association end call expression
Issue 7534: result value of an association class call expression
Issue 7535: result value of an association end call expression
Issue 7536: result value of an association end call expression (02)
Issue 7537: result value of an attribute call expression
Issue 7538: value of a collection item
Issue 7539: result value of a collection literal expression evaluation
Issue 7540: number of elements in the result value
Issue 7541: value of a collection range
Issue 7542: result value of an if expression
Issue 7543: elements in the result value
Issue 7544: value of a collection range
Issue 7545: sub evaluations
Issue 7546: sub evaluations (02)
Issue 7722: Section: 6.5.4.3 Combining Properties
Issue 7972: OCL Constraints in many levels
Issue 8620: Section: 7.4
Issue 8621: Section: 7.4.5
Issue 8622: Section: 7.5.3
Issue 8623: Section: 7.5.8
Issue 8624: Section: 7.5.9
Issue 8625: Section: 7.5.11
Issue 8626: Section: 7.5.13
Issue 8627: Section: 7.6.2
Issue 8628: Section: 8.2
Issue 8634: Section: 8.3
Issue 8635: Section: 8.3.4
Issue 8636: Section: 8.3.5
Issue 8637: Section: 8.3.1
Issue 8638: Section: 8.3.8
Issue 8639: Section: 9.1
Issue 8640: Section: 9.3 CollectionLiteralPartsCS
Issue 8641: Section: 10.1
Issue 8642: Section: 10.2
Issue 8643: Section: 10.2.1 Element
Issue 8644: Section: 10.2.1 NameValueBinding
Issue 8645: Section: 10.2.2 LocalSnapshot
Issue 8646: Section: 10.2.3 ObjectValue
Issue 8647: Section: 10.3
Issue 8648: Section: 10.3.1 LoopExpEval
Issue 8649: Section: 10.3.1 VariableExpEval
Issue 8650: Section: 10.3.2 AssociationEndCallExpEval
Issue 8651: Section: 10.3.2 OperationCallExp
Issue 8652: Section: 10.3.2 NavigationCallExpEval
Issue 8653: Section: 10.3.4 OclMessageArgEval
Issue 8654: Section: 10.3.4 OclMessageArgEval
Issue 8655: Section: 10.3.4 OclMessageExpEval
Issue 8656: Section: 10.3.5
Issue 8657: Section: 10.4
Issue 8658: Section: 10.4.3 IntegerLiteralExpEval
Issue 8659: Section: 11.2.1
Issue 8660: Section: 11.5.1
Issue 8661: Section: 11.5.4
Issue 8662: Section: 11.7.2
Issue 8663: Section: 11.9.1 exists
Issue 8664: Section: 11.9.2 reject
Issue 8665: Section: 11.9.2 sortedBy
Issue 8666: Section: 11.9.3 & 11.9.4 Section: 1 - 13
Issue 8667: Section: 1 - 13
Issue 8789: The spec does not describes the syntax of integer, real or string literals
Issue 8790: OclAny cannot be an instance of Classifier
Issue 8808: Container of additional operations
Issue 8818: Reusing TypedElement for UnspecifiedValueExp
Issue 10786: Naming of Constraints in OCL (02)
Issue 10787: OCL Collections applied to Properties
Issue 1790: Lack of features commonly used in OCL (ocl2-ftf)
Click here for this issue's archive.
Nature: Enhancement
Severity: Significant
Summary: Summary: The current specification for OCL lacks many of the features we commonly
use when doing formal specification of class interfaces, e.g. the ability
to specify the frame condition, the ability to specify postconditions
case-wise, the ability to specify when exceptions are thrown, etc.
To bring OCL closer to the state of the art, I would like to see these
considered as future extensions.
Resolution:
Revised Text: This issue needs to be resolved by the OCL 2.0 Finalization Task Force
Actions taken:
August 10, 1998: received issue
July 22, 1999: Deferred to UML 1.4/2.0.
December 2, 2004: Transferred to OCL 2.0 FTF
Discussion: This issue needs to be resolved by the OCL 2.0 Finalization Task Force. This is an UML 1.x issue transferred to the OCL 2 FTF.
Not all the extra facilities suggested by the text of this issue have been incorporated to the
OCL2 specification. Specific facilities for specifying constraints on class interfaces could
be considered within the context of an RTF.
Disposition: Deferred
Issue 3513: OCL: Usage of qualifiers (ocl2-ftf)
Click here for this issue's archive.
Source: Klasse Objecten (Dr. Jos Warmer, j.warmer@klasse.nl)
Nature: Uncategorized Issue
Severity:
Summary:
Qualifiers, written in brackets after the path name of a feature call,
can express two different things.
- qualifying use: A qualifier is used to give the qualifing value of
a qualified association (chapter 7.5.7).
- navigational use: A qualifier is used to refine the navigation to
association classes. While this navigational use is necessary
only with recursive associations, it is legal for every navigation
to an association class (chapter 7.5.5).
There is no way to distinguish these two sorts of qualifiers. There are
even expressions where both uses of the qualifiers would be necessary at
once, but this problem is restricted to such models that contain a
recursive, qualified association that has an association class.
Example where navigational and qualifing use cannot be distinguished:
There are two classes "Bank" and "Person", with a association between
them qualified by the account number (an Integer). The association end
at the class Person is named "customers".
An additional class "Company" has an attribute "customers" of type
Integer.
Now consider the subexpression "bank.person[customers]" in the context
of Company. "bank" clearly is a navigational expression. But "customers"
could either mean the attribute of Company, since Company is the context
of the expression (that is qualifying use as defined in 7.5.7); or
"customer" could mean the name of the association end (navigational use
as defined in 7.5.5). In the first case, the result type would be
Person, in the second case Set(Person).
Discussion: This is an OCL 1 issue transferred to the OCL 2 FTF. Deferred for timing constraints.
It is sometimes useful to downcast an OCL collection, for example
when a generic function returns an OCL Collection, but a particular
usage requires a Sequence. Unfortunately, the OCL operators
asSet(), asSequence() and asBag(), are defined only for the
concrete types, and not for their abstract common supertype
Collection.Discussion: This is an OCL 1 issue transferred to the OCL 2 FTF. Deferred for timing constrains.
quotes from ad/2003-01-07 (v1.6 of OCL 2 proposal):
Section 1.5.1 says, "the flatten operation is a deep flatten, it
completely flattens a nested collection of any depth". However the
formal definition is :
post: result = if self.type.elementType.oclIsKindOf(CollectionType) then
self->iterate(c; acc : Set() = Set{} |
acc->union(c->asSet() ) )
else
self
endif
From Section 6.5.1 (definition of Set.Flatten). The formal declaration does
not show that the flatten operation is deep. This discussion is extended in
Appendix A, which presents an analogous postcondition, but explains that this
is for a single level only.
It would seem that the post-condition(s) in section 6.5.1 are wrong?
Deferred for timing reasons
OrderedSet isn't discussed in the section on semantics
Deferred for timing reasons
OCL 2 doesn't really define what a collection is. In essence, a particular UML construct is arbitrarily designated as the OCL collection, and a series of properties are assigned to it This question arises in 2 different ways: - can you sub-class one of the concrete descendents in a UML diagram - by referring to the OCL package - and thereby add functionality to your own collection types - are all parameterised classifiers collections? if you define a parameterised class, how does an OCL user or environment know whether it's a collection or not? perhaps a stereotype should be intrroduced to allow for unambiguous resolution of these issues
Deferred for timing reasons
the routines on String are too sparse to support real world usage. In particular, most users would require: * uppercase and lowercase routines * the ability to ask if String1 is found in String2 * case insensitive compare would be useful but can be built using the uppercase or lowercase routines
Deferred for timing reasons
Consider the operation: Account::withdraw (amount: Money) Suppose a Person object sends the operation, and we want to state that the person has to be the owner of the account. Access to the sender of the message is needed. One might for instance imagine that the concrete syntax defines a keyword sender, and we could then write: context: Account::withdraw (amount: Money) pre: sender = self.owner
Discussion: Asking for an improvement of the language. Better solved in a RTF
Description: Provide an operation for creating a collection of new objects Rationale: Consider the case where you want to create a new smartcard for a set of persons. Any solution is currently longwinded. It would be nice to be able to have an operation oclIsNew that applies to a collection (or perhaps only to a Set), and states the number of objects to be created, e.g.: let: s: Set(SmartCards) in s.oclIsNew(self.person->size())...
Discussion: Asking for an improvement of the language. Better solved in a RTF
Description: Provide a notation for the status of an object
Rationale:
It would be convenient to have a notation for denoting the status of an object. The type of such a status is a tuple. With such a notation it would be possible to compare the status of two objects or to compare the status of an object with a tuple. If not available, comparisons have to be performed on an attribute by attribute basis. Consider e.g.
p, p1 and p2 are Person(s)
p1.all = p2.all -- the 2 persons have same status, i.e.
is nicer and less error-prone than comparing all attributes:
p1.firstName = p2.firstName and p1.name = p2.name and ...
It would also be possible to compare with a tuple:
p.all = Tuple = Tuple {firstName = 'Alfred', name = 'Strohmeier', ...}
Discussion: Asking for an improvement of the language. Better solved in a RTF
Description: OclType is currently a subtype of OclAny and seen as an enumeration type. This leads to some drawbacks w.r.t. the specification of operations like oclAsType(), oclIsKindOf(), and oclIsTypeOf(), that need to reason about type conformance. As this cannot be done without accessing the metalevel, OclType should rather be considered as a powertype (cf. OCL Workshop paper at UML 2003: S.Flake, OclType - A Type or Metatype?).
Usage of powertypes as an alternative way to represent generically Ocl types is an interesting suggestion. However, for timing reasons we prefer defer this issue to the RTF.
Description: At some places, template parameter T appears in operation signatures, e.g., oclAsType(typename:OclType) : T (e.g., Sect. 6.2.1). At other places, this is denoted by "instance of OclType" or <<the return type of the invoked operation>>. It would be more meaningful when these informal return type descriptions are replaced by "OclAny". An additional constraint about the actual return type should be given when necessary.
Deferred for timing reasons
Description: This is not treated consistently throughout the document. As the formal semantics already allows both up- and downcasts, this should also be allowed in Sect. 2.4.6.
Deferred for timing reasons
Author: Stephan Flake (flake@c-lab.de) Description: Some operation specifications are still missing (they are marked by --TBD), e.g., oclAsType(). For this operation, a proposed specification is as follows (provided that OclType is a powertype): 1: context OclAny::oclAsType(typename:OclType) : OclAny 2: post: if OclType.allInstances() 3: ->select(t:OclType | self.oclIsTypeOf(t)) 4: ->exists(t:OclType | typename.conformsTo(t) or t.conformsTo(typename)) then 5: result = self and result.oclIsTypeOf(typename) 6: else 7: result = OclUndefined and result.oclIsTypeOf(OclVoid) 8: endif For a comparison, a complex OCL specification for ENUMERATION TYPE OclType can be found in the paper "OclType - A Type or Metatype?".
Deferred for timing reasons
Author: Stephan Flake (flake@c-lab.de) Description: The OCL Standard Library type system should make use of the notation offered by the official UML specification. In particular, abstract types (like OclAny, Collection(T)), datatypes (Integer, Set(T)), and enumeration types (OclState) can be denoted in italics and stereotyped, respectively. An ellipsis can be used to indicate that further types are imported from a referred UML user model. Moreover, OrderedSet(T) is missing in the OCL Standard Library Type type system.
Deferred for timing reasons
Author: Thomas Baar (thomas.baar@epfl.ch) Description: Exception from strict evaluation for IMPLIES is incomplete and contradicts set-theoretical semantics Rationale: On page 2-10 only one exception from strict evaluation for IMPLIES is given: False IMPLIES x == True However, based on the official semantics of IMPLIES given on page A-12 also x IMPLIES True == True
Deferred for timing reasons
Author: Thomas Baar (thomas.baar@epfl.ch)
Description: Exception of strict evaluation should be extended to forAll, exists
Rationale: Suppose r(o1) = undef, r(o2) = false What is value of Exp = {o1, o2}->forAll(x| r(x)) ? One could argue, because of strict evaluation, the value of Exp is undef. However, this would contradict the semantics of forAll als 'iterated and' given on page A.28. Similarily, for exists.
A note should be added on page 2-10 on evalution of expressions based on iterate.
Deferred for timing reasons
Author: Thomas Baar (thomas.baar@epfl.ch) Description: Strict evaluation for queries yields to contradictions in specifications Rationale: Queries can be specified in two ways, as invariants and in form of pre/post conditions. Suppose we specify query q(arg) as post: if (arg.oclIsUndefined()) then result = true else result = false endfi Having this, the following invariant should evaluate always to true: self.q(arg) = true or self.q(arg) = false. However, the invariant evaluates to undef once arg evaluates to undef thanks to strict evaluation. There is a misconception of strict evaluation when it comes to queries. The idea of queries is to have user-defined functions on classes. Why should the user be restricted only to such function which return undef once one of its arguments is undef? Using OCL, the user can even specify queries which can handle undefined arguments (e.g. see post specification of q(arg) ). Obviously, the post specification for q(arg) makes sense. The rule of strict evaluations for queries should be weakened to the case where the owner of the query (the object upon the query was called) is undefined.
Deferred for timing reasons
Author: Thomas Baar (thomas.baar@epfl.ch) Description: contradiction for evaluation of navigation expression Rationale: Suppose to have two classes A, B and an association with multiplicity 0..1 on B between them. The invariant context A inv: self.b = self.b is evaluated for an instance of A not having an associated instance of B to i) true, when the expression self.b has the type Set(B), because self.b is evaluated to emptyset and emptyset = emptyset is evaluated to true ii) undef, when the expression self.b has the type B, because self.b is evaluated to undef and undef = undef is evaluated to undef thanks to strict evaluation of '=' This is a contradiction since the expression self.b can be both of type set(B) and B! The examples also shows, that x = x is not a tautology unlike in almost all other logics including classical predicates logic. This is especially confusing because OCL claims to be based on classical predical logic!
Deferred for timing reasons
Author: Octavian Patrascoiu (O.Patrascoiu@kent.ac.uk) Description: Logical operators 'and', 'or', and 'xor' have the same precedence, which in my opinion is not natural. I think that the precedence of these operators should be from highest to lowest as follows: 'and' 'or' 'xor' Also, the precedence of some useful operators like 'div', 'mod', '^', and '^^', is not specified in section 4.3.2.
Asking for an improvement of the language. Better solved in a RTF
Author: Octavian Patrascoiu (O.Patrascoiu@kent.ac.uk)
Description: Most of the modern OO languages support null values, but OCL does not. In order to map null values into OCL concepts we used the undefined value. Unfortunately, OCL offers two choices to test if a value is undefined or not: isEmpty and oclIsUndefined. Using isEmpty for such a purpose is some how confusing:
the result of property->isEmpty() must be true if the value of the property null/undefined
the result of Set{1/0, 1/0}->isEmpty() must be false
These situations are a source of errors and confusion at the implementation level. I think that isEmpty() should be used only to test if a collection is empty or not; the undefined values should be tested using ocIslUndefined. This operation should be also valid on collections. This approach will also work nice and clear for nested collections.
Deferred for timing reasons
Author: Sten Loecher (Sten.Loecher@inf.tu-dresden.de) Description: OCL specification contains incomplete/ missing well-formedness rules Rationale: The following list contains the concerned classes of the OCL metamodel and provides information about the required changes to the OCL specification. AssociationClassCallExp: missing rule to describe the type AssociationEndCallExp: missing rule to describe the type AttributeCallExp: multiplicity, order, and unambiguousness must be considered CollectionLiteralExp: OrderedSetType must be added IteratorExp: well-formedness rules needed for iterator operations one, any, collectNested, and sortedBy OclMessageExp: missing rule to describe the type OclExpressionWithTypeArgExp: missing rule to describe the type OperationCallExp: missing rule to describe the type
Deferred for timing reasons
Author: Hubert Baumeister (baumeist@informatik.uni-muenchen.de), Rolf Hennicker (hennicke@informatik.uni-muenchen.de), Alexander Knapp (knapp@informatik.uni-muenchen.de) Description: Change Definition A.34 to allow the precondition to be weakened Rationale: It is commonly accepted that a program S satisfying an operation specification may weaken the precondition. This corresponds to Bertrand Meyer's view of software specifications as contracts between clients of a program and program provider. This is in accordance with the explanation following Def. A.34: "In other words, the program S accepts each environment satisfying the precondition as input and produces an environment that satisfies the postcondition." This sentence admits the possibility that S may be defined for environments not satisfying the precondition. However Def. A.34 requires S to be defined exactly on the environments for which the precondition holds. Therefore, we propose to replace Def. A.34 by: DEFINITION A.34 (SATISFACTION OF OPERATION SPECIFICATIONS) An operation specification with pre- and postconditions is satisfied by a program S in the sense of total correctness if the computation of S is a function fS such that the restriction of fS to the domain of R is a total function fS|_dom(R): dom(R) -> im(R) and graph(fS|_dom(R)) \subseteq R. Comment by Daniel Jackson (dnj@mit.edu) i'd be very wary of linking any particular notion of refinement to a modelling language. different circumstances might need different notions, and there's no reason that the language should be tied to one. i wonder, for example, if you've considered the difference between preconditions as disclaimers and preconditions as firing conditions. even for the standard notion of preconditions as disclaimers, your particular definition seems too narrow to me. requiring the program to be a function will rule out many reasonable implementations that are non-deterministic -- hash tables, for example.
Deferred for timing reasons
Author: Achim D. Brucker (brucker@inf.ethz.ch), Burkhart Wolff (wolff@informatik.uni-freiburg.de) Description: Change Definition A.34 to allow the precondition to be weakened Rationale: It is commonly accepted that a program S satisfying an operation specification may weaken the precondition. This corresponds to Bertrand Meyer's view of software specifications as contracts between clients of a program and program provider. This is in accordance with the explanation following Def. A.34: "In other words, the program S accepts each environment satisfying the precondition as input and produces an environment that satisfies the postcondition." This sentence admits the possibility that S may be defined for environments not satisfying the precondition. However Def. A.34 requires S to be defined exactly on the environments for which the precondition holds. Therefore, we propose to replace Def. A.34 by: DEFINITION A.34 (SATISFACTION OF OPERATION SPECIFICATIONS) An operation specification with pre- and postconditions is satisfied by a specification S if the restriction of S to the domain of R (denoted S|_dom(R)) is included in R, i.e. S|_dom(R) \subseteq R. This is equivalent to: \forall x, y. x:dom(R) & (x,y):S --> (x,y):R. In particular, S may be a program, i.e. a computation function in the sense of total correctness.
Deferred for timing reasons
Author: Hubert Baumeister (baumeist@informatik.uni-muenchen.de), Rolf Hennicker (hennicke@informatik.uni-muenchen.de), Alexander Knapp (knapp@informatik.uni-muenchen.de) Description: Change Definition A.34 to allow the precondition to be weakened Rationale: It is commonly accepted that a program S satisfying an operation specification may weaken the precondition. This corresponds to Bertrand Meyer's view of software specifications as contracts between clients of a program and program provider. This is in accordance with the explanation following Def. A.34: "In other words, the program S accepts each environment satisfying the precondition as input and produces an environment that satisfies the postcondition." This sentence admits the possibility that S may be defined for environments not satisfying the precondition. However Def. A.34 requires S to be defined exactly on the environments for which the precondition holds. Therefore, we propose to replace Def. A.34 by: DEFINITION A.34 (SATISFACTION OF OPERATION SPECIFICATIONS) An operation specification with pre- and postconditions is satisfied by a program S in the sense of total correctness if the computation of S is a function fS such that the restriction of fS to the domain of R is a total function fS|_dom(R): dom(R) -> im(R) and graph(fS|_dom(R)) \subseteq R.
Deferred for timing reasons
Author: Hubert Baumeister (baumeist@informatik.uni-muenchen.de), Rolf Hennicker (hennicke@informatik.uni-muenchen.de), Alexander Knapp (knapp@informatik.uni-muenchen.de) Description: Add select/reject/collectNested to Collection Rationale: The definition of any on Collection (page 6-16f.) uses select on Collection. However, select is not defined for Collection. Similarly, the definition of collect on Collection (page 6-17) uses collectNested on Collection, which is not defined on Collection. We therefore propose to add select and collectNested (and possibly reject) to Collection.
Deferred for timing reasons
Author: Hubert Baumeister (baumeist@informatik.uni-muenchen.de), Rolf Hennicker (hennicke@informatik.uni-muenchen.de), Alexander Knapp (knapp@informatik.uni-muenchen.de) Description: Clarify definition of collectNested for Set, Bag, and Sequence Rationale: For Set, Bag, and Sequence the definition of collectNested (page 6-17ff.) actually defines collect which should read collectNested. As a minor detail, the definition of collectNested seems to be the only one using iterators as iterator variable. This should be aligned with select, reject, etc.
Deferred for timing reasons
Author: Hubert Baumeister (baumeist@informatik.uni-muenchen.de),
Rolf Hennicker (hennicke@informatik.uni-muenchen.de),
Alexander Knapp (knapp@informatik.uni-muenchen.de)
Description: Clarify the semantics of forAll
Rationale:
According to the informal explanation (page 6-16) the following Expression Set { 1 }->forAll(x | x/0 < 0) would evaluate to false. However, according to the OCL definition it evaluates to undefined. Thus we propose to omit "otherwise, result is false" in the informal explanation.
Deferred for timing reasons
Author: Hubert Baumeister (baumeist@informatik.uni-muenchen.de), Rolf Hennicker (hennicke@informatik.uni-muenchen.de), Alexander Knapp (knapp@informatik.uni-muenchen.de) Description: Clarify the UML semantics of IfExpEval Rationale: The specification on page 5-21 of the evaluation of if_then_else omits the case when the condition evaluates to undefined. Thus the sentence should read: "The result value of an if expression is the result of the thenExpression if the condition is true, it is the result of the elseExpression if the condition is false, else it is undefined."
Deferred for timing reasons
Author: Hubert Baumeister (baumeist@informatik.uni-muenchen.de), Rolf Hennicker (hennicke@informatik.uni-muenchen.de), Alexander Knapp (knapp@informatik.uni-muenchen.de) Description: Missing equality and inequality operations on collection types Rationale: The collection types Set, Sequence, and Bag show a predefined = operation. However, this operation is not defined for the abstract type Collection. Moreover, the operation <> is missing for all collection types.
Deferred for timing reasons
Author: Herman Balsters (h.balsters@bdk.rug.nl) Description: Reintroduce allAttributes operator Rationale: In pre-OCL 2.0 versions, there was an operator called "allAttributes": this operator (to be applied to class objects) returns the set of attributes of that object. (This operator should also be applicable to tuples as well, by the way.) Now the strange thing has happened that this most useful operator has vanished in OCL 2.0 I propose that it be re-introduced.
This issue asks for reconsidering a decision taken by the OCL2 submitters..Should better be solved in a RTF.
Author: Herman Balsters (h.balsters@bdk.rug.nl) Description: OCL 2.0 is not as expressive as SQL (as opposed to common belief) and needs to be extended to this end Rationale: In my paper "Modeling Database Views with Derived Classes in the UML/OCL-framework" of this years UML conference (see proc. pp. 295-309) I investigated the issue of expressibility of OCL 2.0 w.r.t. to the query langauge SQL. I have demonstrated in that paper that OCL 2.0 is not as expressive as SQL (as opposed to common belief), and that OCL needs an additional "tuplejoin" operator to achieve the desired result. If this issue cannot be dealt with in this phase, I propose it be retained and examined at the next stage.
This is a request to improve the language. Should better be solved in a RTF.
Description: The OCL 2.0 specification should be behaviour-oriented and not implementation-oriented (see section 4.3). Rationale: The idea of using OCL to describe itself is interesting from the research point of view, but unfortunately OCL is not a suitable metalanguage to define the meaning of other textual languages. I think that the best thing to do is to define a virtual machine and to describe the behaviour of the virtual machine using natural language. This technique was successfully used for languages like C, C++, Java, C#, and Prolog. I see no reasons why such a technique would fail for OCL. After all, OCL is less complex than modern programming language like C++, Java, or C#. A proper description and implementation of the OCL virtual machine will create all the conditions to have a language that is platform/tool independent.
This is a request to improve language definition. Should better be solved in a RTF.
Description: The OCL 2.0 specification should describe the set of characters allowed in the OCL constructions (e.g. Unicode or ASCII). Rationale: This will help implementers to solve another ambiguity and to produce portable implementations. Unicode will be in my opinion the best choice.
Deferred for timing reasons
Description: The specification does not describes the syntax of integer, real or string literals. Also, it does not contain the description of the allowed set of values. Rationale: Specifying the syntax and the semantics of basic types will increase the portability of OCL programs. In order to describe the semantics of basic types, the specification should describe the set of values, the allowed operations, and the standard used to perform the allowed operations. I think that it will be also useful to allow different types of integers and reals, like Integer(16), Integer(32), Integer(64), Real(32), and Real(64), in order to optimize the computational process.
This is a request to improve language definition and extend its expresiveness. Should better be solved in a RTF.
Description: OCL 2.0 uses keywords (e.g. and, or, xor, implies etc.) that cannot be used elsewhere. Rationale: This means that these names cannot be used to identify properties, classes or packages. There are two options to solve this problem: either UML 2.0 specifies the names that cannot be used or the OCL concept of keywords has to be revised.
Deferred for timing reasons
Description: OCL 2.0 comments start with -- Rationale: This means that an expression like --4 cannot be interpreted as an arithmetic expression without inserting at least one space between the first - and the second -. I think that this problem can be resolved if the OCL comments start with // instead of --.
Deferred for timing reasons
Description: Section 4.3.2 does not specify precedence for operators like div, mod, ^^, or ^. Rationale: The operator precedence must be as precise as possible in order to provide a platform-independent implementation. I think that logical operators should be organized on different levels of precedence: 'not' 'and' 'or' 'xor' 'implies'
This is a request to improve language definition. Should better be solved I a RTF.
Description: The grammar presented in 4.3, which is in my opinion a semantic grammar, is not suitable to describe the syntax of OCL. Rationale: Introducing non-terminals like primary-expression, selection-expression, and operation-call-expression will solve all the problems and will reduce the number of ambiguities. Hence, the grammar contained in the specification will suffer less changes in order to be used to design and implement a deterministic parser. This is the case of the specifications for C, C++, Java, C#, and Prolog.
Decision deferred to an RTF. It would imply a lot of changes.
Description: Some of the elements presented in 3.3.10 (e.g. EnumLiteralExp, children of ModelPropertyCallExp) cannot be constructed without using semantic information (e.g. the type of the expression determines if a name denotes an attribute, an association end, or an operation). Rationale: Usually a parser produces an AST. The semantic analyser augments the AST by computing for each node from AST the values of the attached attributes. The semantic analysis also checks if there are static semantics errors and reports them. Using other terms in the AST and hence other non-terminals in 4.5 (e.g. dot-selection-expression, arrow-selection-expression, call-expression etc.) will solve this problem.
Decision deferred to an RTF. It would imply a lot of changes.
Description: Syntax for the above constructions is extremely ambiguous and it might involve backtracking.
Rationale: According to OCL specification
* self.f(x, y)
* Set{1,2,3}->select(x, y| x+y = 3)
* Set{1,2,3,4,5,6}->iterate(x; acc:Integer=0 | acc + x)
describe an operation call, an iterator, and an iterate expression.
In order to make the distinction between an iterator call and an operation call we need in this case a three token lookahead, starting from x. The problem gets even more complicated if we consider that an argument for an operation call can be an expression.
In order to solve this problem, which is a potential source of problems for the implementation (error-prone, inefficiency aso), we think that these OCL constructs should contain some extra syntax markers. There are several choices:
* change the comma marker from iterator calls to something else, maybe a semicolon
* add a syntax marker to an iterator name
* do not allow the default types
The above choices will allow to a deterministic parser to deal with the enumerated problems more efficiently. I do not agree with textual language in which variables are given a default type according to the context in which they are used, especially if these languages are design for industrial use. The same problems were in previous versions of C standard, which allowed implicit type int for variables in constructions like
x;
Now, the latest C standard states that variables with default type are not allowed.
Deferred for timing reasons
Description: One issue we have discovered is about expressions of the form: expr.oclAsTypeOf( Type ) The OCL standard does not support Type as a collection or tuple type. Rationale: We think that the syntax should be extended to support collection and tuple types. This will make the language more symmetric and increase the expressiveness of the language.
This issue asks for an improvement of the language. Should better be solved in a RTF.
Description: The OCL specification does not allow operations like = or <> to be performed tuple values. It also forbids operations like oclIsKindOf and oclIsTypeOf on collections. Rationale: Add such operations to tuple and collection types signatures directly or by inheritance, will make the language more powerfull (e.g. a set of dogs can be casted to a set of animals).
This issue asks for an improvement of the language. Should better be solved in a RTF.
Description: The specification (in the standard) of the Environment class is missing a few things that are used or referred to elsewhere in the standard; some are missing altogether and some are missing from the class diagram: The association from an environment to its parent. The operations lookupImplicitSourceForOperation, lookupPathName, addEnvironment Rationale: We show a more complete specification below. We also add a convenience method addVariableDeclaration; although not necessary as addElement can be used to add a VariableDeclaration, this operation avoids the need to construct the VariableDeclaration before adding it to the environment. The specification of the Environment operations uses various methods on the bridge classes; we have added these operations to the classes, as shown in the previous section about the bridge classes.
Deferred for timing reasons
The index seems incomplete and leaves out interesting items (e.g., the definition of standard library functions).
Deferred for timing reasons
The compliance points strategies mentioned in the OCL 2.0 spec are different from the UML 2.0 infra, super and MOF 2.0 specs. We need to align the OCL spec on this
Deferred for timing reasons
think the operation allInstances() is under-specified in the current version of the OCL 2.0 specification. It does not seem to be clear whether OclUndefined is included in the returned set or not: According to the 1.5 specification of allInstances(), the instances of all subtypes are included. OclVoid is a subtype of all other types, thus OclUndefined would be a part of the set. I assume this is not the intended behaviour. For example, the "all names must be different" expression example would always yield OclUndefined or false, but never true.
Deferred for timing reasons
Perhaps it makes sense to explicitly mention whether OclUndefined = OclUndefined results in OclUndefined (or true)? The SQL equivalent seems to cause a lot of confusion, especially since in C "NULL == NULL" resturns true. For example, the above expression would not work with excluding(OclUndefined), given (OclUndefined=OclUndefined).isOclUndefined().....
Deferred for timing reasons
Typo in an example with TupleType Section 7.5.15: In the example constraint, expression attr: Statistics : Set(TupleType(& This must be Tuple only, according to the concrete syntax.
Deferred for timing reasons
Keywords "attr" and "oper" still necessary? Keywords attr and oper are defined in the keywords list, but are not included in the concrete grammar. Are they maybe superfluous? If "attr" is really a keyword, then the well-formedness rule on page 140 that uses a local variable attr must use another variable name.
Deferred for timing reasons
Suggestion: Use special characters to denote a call to oclIsKindOf and oclIsTypeOf. For instance, use '#ActionState' instead of 'oclIsKindOf(ActionState)' and use '##ActionState' instead of 'oclIsTypeOf(ActionState)'
This is a request to improve the language. Better solved in a RTF.
Suggestion: Use brackets as an alternate option to denote a call to the "select"
function. Notation: mylist[iterator | condition]
Example:
self.ownedElement[#Class and name="MyClass"]
-- #Class is a shorthand for oclIsKindOf(MyClass)
equivalent to :
self.ownedElement->select(oclIsKindOf(Class) and name="MyClass")
This is a request to improve the language. Better solved in a RTF.
Suggestion: Use brackets with a "!" prefixing mark
Example:
self.ownedElement[! #Class and name="MyClass"]
means
self.ownedElement->select(oclIsKindOf(Class) and name="MyClass")->first()
This is a request to improve the language. Better solved in a RTF.
Suggestion: Define an "alt" collection function, with a specific notation, as in:
mylist->alt(iterator | condition? thenExp, elseExp)
The expression elseExp is not evaluated if condition returns true
This is a request to improve the language. Better solved in a RTF.
Suggestion: Define a "switch" collection function, with a sepecific notation, as in:
mylist->switch( iterator | cond1 ? exp1, cond2 ? exp2, …, else ? expN)
The expressions cond2 is not evaluated if cond1 returns true and so on.
This is a request to improve the language. Better solved in a RTF.
Suggestion: Define a "switch" collection function, with a sepecific notation, as in:
mylist->switch( iterator | cond1 ? exp1, cond2 ? exp2, …, else ? expN)
The expressions cond2 is not evaluated if cond1 returns true and so on.
This is a request to improve the language. Better solved in a RTF.
This is to avoid using the unreadable and unfriendly "let … in …" notation.
Suggestion: Use the result of a variable initialization as in:
if (let c = self.address)="" then "UNKNOWN"
else if c.includes(Set{"Irak","Afganifsthan"}) then "DANGEROUS"
else "OK" endif endif endif …
This is a request to improve the language. Better solved in a RTF.
Use a DOT instead of an ARROW is this situation.
myinstance.anycollectionfunction() equivalent to
Set{myinstance}->anycollectionfunction(…)->first()
This is a request to improve the language. Better solved in a RTF.
Example1: if list.select(...) then … equivalent to
if list.select(...)->notEmpty() then …
Example2: if item then … equivalent to
if item<>OCLUndefined then ...
This is a request to improve the language. Better solved in a RTF.
Use the "null" keyword instead of verbose "OclUndefined".
This is a request to improve the language. Better solved in a RTF.
Make optional the qualification of enumeration values. Example: Be able to write 'self.aggregationKind="Composite" ' as an alternative to 'self.aggregationKind=AggregationKind::Composite'.
This is a request to improve the language. Better solved in a RTF.
When a name conflicts happen, it should be possible to resolve by qualifying the
names.