The Expressions Package

 
This section defines the abstract syntax of the expressions package. This package defines the structure that OCL  expressions can have. An overview of the inheritance relationships between all classes defined in this package is shown  in Figure 12 .

Expressions Core

Figure 6 shows the core part of the Expressions package. The basic structure in the package consists of the classes OclExpression, PropertyCallExp and VariableExp. An OclExpression always has a type, which is usually not explicitly modeled, but derived. Each PropertyCallExp has exactly one source, identified by an OclExpression. In this section we use the term 'property', which is a generalization of Feature, AssociationEnd and predefined iterating OCL  collection operations.

A ModelPropertyCallExp generalizes all propertycalls that refer to Features or associations or AssociationEnds in  the UML metamodel. In Figure 9  the various subtypes of ModelPropertyCallExp are defined.

Most of the remainder of the expressions package consists of a specification of the different subclasses of  PropertyCallExp and their specific structure. From the metamodel it can be deduced that an OCL expression always starts  with a variable or literal, on which a property is recusively applied.

IfExp

An IfExp is defined in Section 8.3.3 ("If Expressions"), but included in this diagram for completeness.

IterateExp

An IterateExp is an expression which evaluates its body expression for each element of a collection. It acts as a loop  construct that iterates over the elements of its source collection and results in a value. An iterate expression evaluates its body expression for each element of its source collection. The evaluated value of the body expression in each iteration-step becomes the new value for the result variable for the succeding iteration-step. The result can be of any type and is defined by the result association. The IterateExp is the most fundamental collection expression defined in the OCL Expressions package.

Associations
IteratorExp

An IteratorExp is an expression which evaluates its body expression for each element of a collection. It acts as a loop  construct that iterates over the elements of its source collection and results in a value. The type of the iterator expression  depends on the name of the expression, and sometimes on the type of the associated source expression. The IteratorExp represents all other predefined collection operations that use an iterator. This includes select, collect, reject, forAll, exists,
etc. The OCL Standard Library defines a number of predefined iterator expressions. Their semantics is defined in terms of the iterate expression in , see Section 11.8, "Predefined Iterator Expressions,"
.
LiteralExp

A LiteralExp is an expression with no arguments producing a value. In general the result value is identical with the expression symbol. This includes things like the integer 1 or literal strings like 'this is a LiteralExp'.

LoopExp

A LoopExp is an expression that respresent a loop construct over a collection. It has an iterator variable that represents  the elements of the collection during iteration. The body expression is evaluated for each element in the collection. The result of a loop expression depends on the specific kind and its name.

Associations

  • iterators
The VariableDeclarations that represents the iterator variables. These variables are, each in its turn, bound to every element value of the source collection while evaluating the body expression.
  • body
The OclExpression that is evaluated for each element in the source collection.

ModelPropertyCallExp

A ModelPropertyCall expression is an expression that refers to a property that is defined for a Classifier in the UML  model to which this expression is attached. Its result value is the evaluation of the corresponding property. In Section  ("Model PropertyCall Expressions") the various subclasses of ModelPropertyCallExp are defined.

OclExpression

An OclExpression is an expression that can be evaluated in a given environment. OclExpression is the abstract  superclass of all other expressions in the metamodel. It is the top-level element of the OCL Expressions package. Every  OclExpression has a type that can be statically determined by analyzing the expression and its context. Evaluation of an expression results in a value. Expressions with boolean result can be used as constraints, e.g. to specify an invariant of a class. Expressions of any type can be used to specify queries, initial attribute values, target sets, etc..

The environment of an OclExpression defines what model elements are visible and can be referred to in an expression.At the topmost level the environment will be defined by the ModelElement to which the OCL expression is attached, for example by a Classifier if the OCL expression is used as an invariant. On a lower level, each iterator expression can also introduce one or more iterator variables into the environment. the environment is not modeled as a separate metaclass,
because it can be completely derived using derivation rules. The complete derivation rules can be found in chapter 9 ("Concrete Syntax").

Associations
  • appliedProperty
The property that is applied to the instance that results from evaluating this OclExpression.
  • type
The type of the value that is the result of evaluating the OclExpression.
  • parentOperation
The OperationCallExp where this OclExpression is an argument of. See Figure 9 .
  • initializedVariable
The variable of which the result of this expression is the initial value.

OclMessageExp

OclMessageExp is defined in Section 8.3.4 ("Message Expressions"), but included in this diagram for completeness.

PropertyCallExp

A PropertyCallExp is an expression that refers to a property (operation, attribute, association end, predefined iterator for  collections). Its result value is the evaluation of the corresponding property. This is an abstract metaclass.

Associations

VariableDeclaration

A VariableDeclaration declares a variable name and binds it to a type. The variable can be used in expressions where  the variable is in scope. This metaclass represents amongst others the variables self and result and the variables defined  using the Let expression.

  • initExpression
The OclExpression that represents the initial value of the variable. Depending on the role that a variable declaration plays, the init expression might be mandatory.
  • type
The Classifier which represents the type of the variable.

Attributes
VariableExp

A VariableExp is an expression which consists of a reference to a variable. References to the variables self and result or to variables defined by Let espressions are examples of such variable expressions.

Associations

  • referredVariable
The VariableDeclaration to which this variable expression refers. In the case of a self expression the variable declaration is the definition of the self variable.

Model PropertyCall

Expressions

A ModelPropertyCallExp can refer to any of the subtypes of Feature as defined in the UML kernel. This is shown in Figure 9 by the three different subtypes, each of which is associated with its own type of ModelElement



AssociationEndCallExp

An AssociationEndCallExp is a reference to an AssociationEnd defined in a UML model. It is used to determine objects linked to a target object by an association. The expression refers to these target objects by the role name of the association end connected to the target class.

Associations

  • referredAssociationEnd
The AssociationEnd to which this AssociationEndCallExp is a reference. This refers to an AssociationEnd of an Association that is defined in the UML model.

AssociationClassCallExp

An AssociationClassCallExp is a reference to an AssociationClass defined in a UML model. It is used to determine objects linked to a target object by an association class. The expression refers to these target objects by the name of the target associationclass.

Associations
  • referredAssociationClass
The AssociationClass to which this AssociationClassCallExp is a reference. This refers to an AssociationClass that is defined in the UML model.

AttributeCallExp

An AttributeCallExpression is a reference to an Attribute of a Classifier defined in a UML model. It evaluates to the value of the attribute.

Associations
NavigationCallExp

A NavigationCallExp is a reference to an AssociationEnd or an AssociationClass defined in a UML model. It is used  to determine objects linked to a target object by an association. If there is a qualifier attached to the source end of the  association then additional qualifiers expressions may be used to specify the values of
 the qualifying attributes.

Associations

  • qualifiers
The values for the qualifier attributes if applicable.
  • navigationSource
The source denotes the AssociationEnd at the end of the object itself. This is used to resolve ambiguities when the same Classifier participates in more than one Association-End in the same association. In other cases it can be derived.

OperationCallExp

A OperationCallExp refers to an operation defined in a Classifier. The expression may contain a list of argument expressions if the operation is defined to have parameters. In this case, the number and types of the arguments must match the parameters.

Associations

If  Expressions


This section describes the if expression in detail. Figure 8 shows the structure of the if expression.




IfExp

An IfExp results in one of two alternative expressions depending on the evaluated value of a condition. Note that both the thenExpression and the elseExpression are mandatory. The reason behind this is that an if expression should always result in a value, which cannot be guaranteed if the else part is left out.

Associations
  • condition
The OclExpression that represents the boolean condition. If this condition evaluates to true, the result of the if expression is identical to the result of the thenExpression. If this condition evaluates to false, the result of the if expression is identical to the result of the elseExpression
  • thenExpression
The OclExpression that represents the then part of the if expression.
  • elseExpression
The OclExpression that represents the else part of the if expression.


Message Expressions

In the specification of communication between instances we unify the notions of asynchronous and synchronous communication. The structure of the message expressions is shown in Figure 9.

OclMessageExp

An OclMessageExp is an expression that results in an collection of OclMessage value. An OclMessage is the unification of a signal sent, and an operation call. The target of the operation call or signal sent is specified by the target OclExpression. Arguments can be OclExpressions, but may also be unspecified value expressions for arguments whose value is not specified. It covers both synchronous and asynchronous actions. See [Kleppe2000] for a complete description and motivation of this type of expression, also called "action clause".


Associations
  • target
The OclExpression that represents the target instance to which the signal is sent.
  • arguments
The SignalArgs that represents the parameters to the Operation or Signal. The number and type of arguments should conform to those defined in the Operation or Signal. The order of the arguments is the same as the order of the parameters of the Operation or the attributes of a Signal.
  • calledOperation
If this is a message to request an operation call, this is the requested CallAction.
  • sentSignal
If this is a UML signal sent, this is the SendAction.

OclMessageArg

An OclMessageArg is an argument of an OclMessageExp. It is either an OclExpression, or an UnspecifiedValueExp.An OclExpression is used to specify the exact value of the parameter. An UnspecifiedValueExp is used when one does not want, or is not able to specify the exact value of the parameter at the time of sending of the message. An OclMessageArg has either a specified or an unspecified value.

Associations
UnspecifiedValueExp

An UnpecifiedValueExp is an expression whose value is unspecified in an OCL expression. It is used within OCL  messages to leave parameters of messages unspecified.

Literal  Expressions


This section defines the different types of literal expressions of OCL. It also refers to enumeration types and enumeration  literals. Figure 10 shows all types of literal expressions.

BooleanLiteralExp

A BooleanLiteralExp represents the value true or false of the predefined type Boolean.

Attributes
CollectionItem

A CollectionItem represents an individual element of a collection.

CollectionKind

A CollectionKind is an enumeration of kinds of collections.

CollectionLiteralExp

A CollectionLiteralExp represents a reference to collection literal.

Attributes
CollectionLiteralPart

A CollectionLiteralPart is a member of the collection literal.

Associations


CollectionRange

A CollectionRange represents a range of integers.

EnumLiteralExp

An EnumLiteralExp represents a reference to an enumeration literal.

Associations

IntegerLiteralExp

A IntegerLiteralExp denotes a value of the predefined type Integer.

Attributes
NumericLiteralExp

A NumericLiteralExp denotes a value of either the type Integer or the type Real.

PrimitiveLiteralExp

A PrimitiveLiteralExp literal denotes a value of a primitive type.

Attributes
RealLiteralExp

A RealLiteralExp denotes a value of the predefined type Real.

Attributes

StringLiteralExp

A StringLiteralExp denotes a value of the predefined type String.

Attributes
TupleLiteralExp

A TupleLiteralExp denotes a tuple value. It contains a name and a value for each part of the tuple type.

Let  expressions

This section defines the abstract syntax metamodel for Let expressions. The only addition to the abstract syntax is the metaclass LetExp as shown in Figure.11 other metaclasses are re-used from the previous diagrams. TheNote that Let expressions that take arguments are no longer allowed in OCL 2.0. This feature is redundant. Instead, a modeler can define an additional operation in the UML Classifier, potentially with a special stereotype to denote that this operation is only ment to be used as a helper operation in OCL expressions. The postcondition of such an additional operation can then define its result value. Removal of Let functions will therefore not affect the expressibility of the modeler. Another way to define such helper operations is through the <<definition>> constraint, which reuses some of the
concrete syntax defined for Let expressions (see Section 12.5, "Definition," on page 157), but is nothing more than an OCL-based syntax for defining helper attributes and operations.

LetExp

A LetExp is a special expression that defined a new variable with an initial value. A variable defined by a LetExp cannot  change its value. The value is always the evaluated value of the initial expression. The variable is visible in the in expression.




Associations

Well-formedness Rules of the Expressions package

The metaclasses defined in the abstract syntax have the following well-formednes rules
:
AttributeCallExp

The type of the Attribute call expression is the type of the referred attribute.

context AttrubuteCallExp
inv: type = referredAttribute.type

BooleanLiteralExp

  1. The type of a boolean Literal expression is the type Boolean.

  2. context BooleanLiteralExp
    inv: self.type.name = 'Boolean'

CollectionLiteralExp

  1. 'Collection' is an abstract class on the M1 level and has no M0 instances.
    context CollectionLiteralExp
    inv: kind <> CollectionKind::Collection

  2. The type of a collection literal expression is determined by the collection kind selection and the common supertype of all elements. Note that the definition below implicitly states that empty collections have OclVoid as their elementType.

    context CollectionLiteralExp
    inv: kind = CollectionKind::Set implies type.oclIsKindOf (SetType )
    inv: kind = CollectionKind::Sequence implies type.oclIsKindOf (SequenceType)
    inv: kind = CollectionKind::Bag implies type.oclIsKindOf (BagType )
    inv: type.oclAsType (CollectionType).elementType = parts->iterate (p; c : Classifier = OclVoid | c.commonSuperType (p.type))

CollectionLiteralPart

No additional well-formedness rules.

CollectionItem

  1. The type of a CollectionItem is the type of the item expression.
    context CollectionItem
    inv: type = item.type

CollectionRange

  1. The type of a CollectionRange is the common supertype of the expressions taking part in the range.
    context CollectionRange
    inv: type = first.type.commonSuperType (last.type)

EnumLiteralExp

  1. The type of an enum Literal expression is the type of the referred literal.
    context EnumLiteralExp
    inv: self.type = referredEnumLiteral.enumeration

IfExp

  1. The type of the condition of an if expression must be Boolean.
    context IfExp
    inv: self.condition.type.oclIsKindOf(Primitive) and self.condition.type.name = 'Boolean'

  2. The type of the if expression is the most common supertype of the else and then expressions
    context IfExp
    inv: self.type = thenExpression.type.commonSuperType(elseExpression.type)

IntegerLiteralExp

  1. The type of an integer Literal expression is the type Integer.
    context IntegerLiteralExp
    inv: self.type.name = 'Integer'

IteratorExp

  1. If the iterator is 'forAll', 'isUnique', or 'exists' the type of the iterator must be Boolean.
    context IteratorExp
    inv: name = 'exists' or name = 'forAll' or name = 'isUnique'
        implies type.oclIsKindOf(Primitive) and type.name = 'Boolean'

  2. The result type of the collect operation on a sequence type is a sequence, the result type of 'collect' on any other collection type is a Bag. The type of the body is always the type of the elements in the return collection.

    context IteratorExp
    inv: name = 'collect' implies
        if source.type.oclIsKindOf(SequenceType) then
            type = expression.type.collectionType->select(oclIsTypeOf(SequenceType))->first()
        else
            type = expression.type.collectionType->select(oclIsTypeOf(BagType))->first()
        endif


  3. The 'select'and 'reject' iterators have the same type as its source.

    context IteratorExp
    inv: name = 'select' or name = 'reject' implies type = source.type

  4. The type of the body of the select, reject,exists and forAll must be boolean.

    context IteratorExp
    inv: name = 'exists' or name = 'forAll' or name = 'select' or name = 'reject'
        implies body.type.name = 'Boolean'

IterateExp

  1. The type of the iterate is the type of the result variable.
    context IterateExp
    inv: type = result.type

  2. The type of the body expression must conform to the declared type of the result variable.context IterateExp

    body.type.conformsTo(result.type)

  3. A result variable must have an init expression.

    context IterateExp
    inv: self.result.initExpression->size() = 1

LetExp

  1. The type of a Let expression is the type of the in expression. context LetExp
    inv: type = in.type

LiteralExp

No additional well-formedness rules.

LoopExp

  1. The type of the source expression must be a collection.

  2. context LoopExp
    inv: source.type.oclIsKindOf (CollectionType)

  3. The loop variable of an iterator expression has no init expression.

    context LoopExp
    inv: self.iterators->forAll(initExpression->isEmpty())

  4. The type of each iterator variable must be the type of the elements of the source collection.

    context IteratorExp
    inv: self.iterators->forAll(type = source.type.oclAsType (CollectionType).elementType)

ModelPropertyCallExp

No additional well-formedness rules.

NumericLiteralExp

No additional well-formedness rules.

OclExpression

No additional well-formedness rules.

OclMessageArg

  1. There is either an expression or an unspecified value.
    context OclMessageArg
    inv: expression->size() + unspecified->size() = 1

OclMessageExp

  1. If the message is a call action, the arguments must conform to the parameters of the operation.

  2. context OclMessageExp
    inv: calledOperation->notEmpty() implies
        arguments->forall (a | a.getType().conformsTo
            (self.calledOperation.operation.parameter->
                select( kind = ParameterDirectionKind::in )
                    ->at (arguments->indexOf (a)).type))

  3. If the message is a send action, the arguments must conform to the attributes of the signal.

    context OclMessageExp
    inv: sentSignal->notEmpty() implies
        arguments->forall (a | a.getType().conformsTo
            (self.sentSignal.signal.feature.oclAsType(StructuralFeature) )
                ->at (arguments->indexOf (a)).type))

  4. If the message is a call action, the operation must be an operation of the type of the target expression.

    context OclMessageExp
    inv: calledOperation->notEmpty() implies
        target.type.allOperations()->includes(calledOperation.operation)


  5. An OCL message has either a called operation or a sent signal.

    context OclMessageExp
    inv: calledOperation->size() + sentMessage->size() = 1

  6. The target of an OCL message cannot be a collection.

    context OclMessageExp
    inv: not target.type.oclIsKindOf (CollectionType)

OperationCallExp

  1. All the arguments must conform to the parameters of the referred operation

  2. context OperationCallExp
    inv: arguments->forall (a | a.type.conformsTo
        (self.refParams->at (arguments->indexOf (a)).type))

  3. There must be exactly as many arguments as the referred operation has parameters.

    context OperationCallExp
    inv: arguments->size() = refParams->size()

  4. An additional attribute refParams lists all parameters of the referred operation except the return and out parameter(s).

    context OperationCallExp
    def: refParams: Sequence(Parameter) = referredOperation.parameters->select (p |
        p.kind <> ParameterDirectionKind::return or
        p.kind <> ParameterDirectionKind::out)

PropertyCallExp

No additional well-formedness rules.

RealLiteralExp

  1. The type of a real Literal expression is the type Real.

  2. context RealLiteralExp
    inv: self.type.name = 'Real'

StringLiteralExp

  1. The type of a string Literal expression is the type String.

  2. context StringLiteralExp
    inv: self.type.name = 'String'

TupleLiteralExp

  1. The type of a TupleLiteralExp is a TupleType with the specified parts.

  2. context TupleLiteralExp
    inv: type.oclIsKindOf (TupleType)
        and
        tuplePart->forAll (tlep |
            type.oclAsType (TupleType).allAttributes()->exists (tp | tlep.attribute = tp))
        and
            tuplePart->size() = type.oclAsType (TupleType).allAttributes()->size()

  3. All tuple literal expression parts of one tuple literal expression have unique names.

    context TupleLiteralExp
    inv: tuplePart->isUnique (attribute.name)

TupleLiteralExpPart

  1. The type of the attribute is the type of the value expression.

  2. context TupleLiteralExpPart
    inv: attribute.type = value.type

UnspecifiedValueExp

No additional well-formedness rules.

VariableDeclaration

  1.  For initialized  variable declarations, the type of the initExpression must conform to the type of the declared variable.

  2. context VariableDeclaration
    inv: initExpression->notEmpty() implies initExpression.type.conformsTo (type)


VariableExp


  1. The type of a VariableExp is the type of the variable to which it refers.

  2. context VariableExp
    inv: type = referredVariable.type

  Additional Operations on UML metaclasses

In the chapters "Abstract Syntax," "Concrete Syntax," "The Use of Ocl Expressions in UML Models," and appendix  "Semantics Described using UML" many additional operations on UML metaclasses are used. They are defined in this section. The next section defines additional operations for the OCL metaclasses

Classifier

The operation commonSuperType results in the most specific common supertype of two classifiers.

context Classifier
def: commonSuperType (c : Classifier) : Classifier =
    Classifier.allInstances()->select (cst |
        c.conformsTo (cst) and
        self.conformsTo (cst) and
        not Classifier.allInstances()->exists (clst |
            c.conformsTo (clst) and
            self.conformsTo (clst) and
            clst.conformsTo (cst) and
            clst <> cst
        )
    )->any (true)

The following operations have been added to Classifier to lookup attributes, associationEnds and operations.

context Classifier
def: lookupAttribute(attName : String) : Attribute =
    self.allAttributes->any(me | me.name = attName)
def: lookupAssociationEnd(name : String) : AssociationEnd =
    self.allAssociationEnds->any (ae | ae.name = name)
def: lookupAssociationClass(name : String) : AssociationClass =
    self.allAssociationClasses->any (ae | ae.name = name)
def: lookupOperation (name: String, paramTypes: Sequence(Classifier)): Operation =
    self.allOperations->any (op | op.name = name and
        op.hasMatchingSignature(paramTypes))
def: lookupSignal (sigName: String, paramTypes: Sequence(Classifier)): Operation =
    self.allReceptions.signal->any (sig | sig.name = sigName and
        sig.hasMatchingSignature(paramTypes))

Operations allAttributes, allOperations, etc. are defined in the UML semantics. The operation allReceptions is missing and defined here. The operation allReceptions results in a Set containing all Signals that the Classifier has as Receptions itself and all its inherited Attributes.

context Classifier
def: allReceptions : set(Reception) =
    self.allFeatures->select(f | f.oclIsKindOf(Reception))

Operation

An additional operation is added to Operation, which checks whether its signature matches with a sequence of Clasifiers.
Note that in making the match only parameters with direction kind `in' are considered.

context Operation
def: hasMatchingSignature(paramTypes: Sequence(Classifier)) : Boolean =
      -- check that operation op has a signature that matches the given parameter lists
      = let sigParamTypes: Sequence(Classifier) = self.allAttributes.type in
        (
            ( sigParamTypes->size() = paramTypes->size() ) and
            ( Set{1..paramTypes->size()}->forAll ( i |
                paramTypes->at (i).conformsTo (sigParamTypes->at (i))
            )
        )
      )

Parameter

The operation asAttribute results in an attribute that has the same name, type, etc. as the parameter.

context Parameter::asAttribute(): Attribute
pre: -- none
post: result.name = self.name
post: result.type = self.type
post: result.multiplicity = 1
post: result.targetscope = ScopeKind::instance
post: result.ownerscope = ScopeKind::instance
post: result.ordering = OrderingKind::unordered
post: result.visibility = VisibilityKind::private
post: result.stereotype.name = 'OclHelper'

An additional class operation is added to Parameter to return a Parameter.

context Parameter::make(n : String, c : Classifier, k : ParameterDirectionKind) :Parameter
post: result.name = n
post: result.kind = k
post: result.type = c
post: result.stereotype.name = 'OclHelper'

Signal

An additional operation is added to Signal, which checks whether its signature matches with a sequence of Clasifiers.
Note that in making the match the parameters of the signal are its attributes.

context Signal
def: hasMatchingSignature(paramTypes: Sequence(Classifier)) : Boolean =
    -- check that signal has a signature that matches the given parameter lists
    = let opParamTypes: Sequence(Classifier) = self.parameter->select (p | p.kind <>
                                           ParameterDirectionKind::return).type in
        (
            ( opParamTypes->size() = paramTypes->size() ) and
            ( Set{1..paramTypes->size()}->forAll ( i |
                paramTypes->at (i).conformsTo (opParamTypes->at (i))
            )
         )
    )

State
The operation getStateMachine() returns the statemachine to which a state belongs.

context State::getStateMachine() : StateMachine
post: result =
    if statemachine->notEmpty() then
        stateMachine
    else
        -- must be part of a composite state
        state.container.getStateMachine()
    endif

Transition

The operation getStateMachine() returns the statemachine to which a transition belongs.

context Transition::getStateMachine() : StateMachine
post: result =
    if statemachine->notEmpty() then
        stateMachine
    else
        -- state is not empty
        state.getStateMachine()
    endif

Additional Operations on OCL metaclasses

In chapters "Abstract Syntax," "Concrete Syntax," "The Use of Ocl Expressions in UML Models," and appendix "Semantics Described using UML" many additional operations on OCL metaclasses are used. They are defined in this  section. The previous section defines additional operations for the UML metaclasses

OclExpression

The following operation returns an operation call expression for the predefined atPre() operation with the self expression  as its source.

OclExpression::withAtPre() : OperationCallExp
post: result.name = 'atPre'
post: result.arguments->isEmpty()
post: result.source = self

The following operation returns an operation call expression for the predefined asSet() operation with the self expression  as its source.

OclExpression::withAsSet() : OperationCallExp
post: result.name = 'asSet'
post: result.arguments->isEmpty()
post: result.source = self

OclMessageArg

An additional operation is added to oclMessageArg to return the type of the argument.

context OclMessageArg
def: getType() : Classifier = if unspecified->notEmpty()
    then unspecified.type
    else expression.type
    endif

TupleType

An additional class operation is added to Tuple to return a new tuple. The name of a tupletype is defined in the abstract  syntax chapter and need not to be specified here.

context TupleType::make(atts : sequence(Attribute) ) : TupleType
post: result.features = atts
post: result.stereotype.name = 'OclHelper'

VariableDeclaration

An additional operation is added to VariableDeclaration to return a corresponding Parameter.

context VariableDeclaration::asParameter() : Parameter
post: result.name = self.varName
post: result.kind = ParameterKind::in
post: result.type = self.type
An additional operation is added to VariableDeclaration to return a corresponding Attribute.
context VariableDeclaration::asAttribute() : Attribute
post: result.name = self.varName
post: result.type = self.type
post: result.multiplicity = 1
post: result.targetscope = ScopeKind::instance
post: result.ownerscope = ScopeKind::instance
post: result.ordering = OrderingKind::unordered
post: result.visibility = VisibilityKind::private
post: result.constraint.bodyExpression = self.initExpression
post: result.stereotype.name = 'OclHelper'

Overview of class hierarchy of OCL Abstract Syntax metamodel