Object Co nstr aint Lang ua g e Specif i cation 7

52 Pages·2001·0.27 MB·English

Object Constraint Language
Specification 7
This chapter introduces and defines the Object Constraint Language (OCL), a formal
language to express side-effect-free constraints.
Contents
(cid:1)This chapter contains the following topics.
Topic Page
“Overview” 7-1
“Introduction” 7-3
“Connection with the UML Metamodel” 7-4
“Basic Values and Types” 7-6
“Objects and Properties” 7-11
“Collection Operations” 7-22
“Predefined OCL Types” 7-28
“Grammar” 7-50
7.1 Overview
This chapter introduces and defines the Object Constraint Language (OCL), a formal
language used to express constraints. These typically specify invariant conditions that
must hold for the system being modeled. Note that when the OCL expressions are
(cid:2)
evaluated, they do not have side effects (i.e., their evaluation cannot alter the state of
(cid:3)
OMG-UML V1.3 March 2000 (cid:0)7-1
7
(cid:4)the corresponding executing system). In addition to specifying invariants of the UML
metamodel, UML modelers can use OCL to specify application-specific constraints in
(cid:4)their models.
(cid:5)OCL is used in the UML Semantics chapter to specify the well-formedness rules of the
metaclasses comprising the UML metamodel. A well-formedness rule in th e static
(cid:2)
semantics chapters in th e UML Semantics section normally contains an OCL
(cid:6)
expression, specifying an invariant for the associated metaclass. The grammar for OCL
(cid:3)
(cid:7)is specified at the end of this chapter. A parser generated from this grammar has
correctly parsed all the constraints in the UML Semantics section, a process which
(cid:8)
improved the correctness of the specifications for OCL and UML.
7.1.1 Why OCL?
(cid:9)A UML diagram, such as a class diagram, is typically not refined enough to provide all
(cid:4)the relevant aspects of a specification. There is, among other things, a need to describe
additional constraints about the objects in the model. Such constraints are often
(cid:10)
(cid:11)described in natural language. Practice has shown that this will always result in
ambiguities. In order to write unambiguous constraints, so-called formal languages
(cid:10)
have been developed. The disadvantage of traditional formal languages is that they are
usable to persons with a string mathematical background, but difficult for the average
(cid:12)
(cid:13)business or system modeler to use.
(cid:5)OCL has been developed to fill this gap. It is a formal language that remains easy to
read and write. It has been developed as a business modeling language within the IBM
(cid:14)Insurance division, and has its roots in the Syntropy method.
(cid:5)OCL is a pure expression language; therefore, an OCL expression is guaranteed to be
without side effect. When an OCL expression is evaluated, it simply returns a value. It
(cid:15)
cannot change anything in the model. This means that the state of the system will never
(cid:8)
change because of the evaluation of an OCL expression, even though an OCL
(cid:8)
(cid:3)expression can be used to (cid:16)specify a state change (e.g., in a post-condition).
(cid:5)OCL is not a programming language; therefore, it is not possible to write program
logic or flow control in OCL. You cannot invoke processes or activate non-query
operations within OCL. Because OCL is a modeling language in the first place, not
(cid:17)
everything in it is p romised to be directly executable.
(cid:3)
(cid:5)OCL is a typed language, so that each OCL expression has a type. To be well formed,
an OCL expression must conform to the type conformance rules of the language. For
(cid:10)
example, you cannot compare an Integer with a String. Each Classifier defined within
(cid:3)
a UML model represents a distinct OCL type. In addition, OCL includes a set of
(cid:10)
supplementary predefined types (these are described in Section7.8, “Predefined OCL
(cid:6)
(cid:1)Types,” on page7-28).
(cid:9)As a specification language, all implementation issues are out of scope and cannot be
expressed in OCL.
(cid:3)
The evaluation of an OCL expression is instantaneous. This means that the states of
objects in a model cannot change during evaluation.
(cid:17)
(cid:0)7-2 OMG-UML V1.3 March 2000
7
7.1.2 Where to Use OCL
(cid:5)OCL can be used for a number of different purposes:
•
To specify invariants on classes and types in the class model
•
To specify type invariant for Stereotypes
•
(cid:1)To describe pre- and post conditions on Operations and Methods
•
To describe Guards
•
As a navigation language
•
(cid:1)To specify constraints on operations
(cid:19)Within the UML Semantics chapter, OCL is used in the well-formedness rules as
invariants on the metaclasses in the abstract syntax. In several places, it is also used to
(cid:11)define ‘additional’ operations, which are used in the well-f ormedness rules.
7.2 Introduction
7.2.1 Legend
Text written in the courier typeface as shown below is an OCL expression.
'This is an OCL expression'
The (cid:20)context keyword introduces the context for the expression. The keywords (cid:21)inv, (cid:23)pre
(cid:22)
(cid:10)and (cid:23)post denote the stereotypes, respectively «invariant», «precondition», and
«postcondition», of the constraint. The actual OCL expression comes after the colon.
context TypeName inv:
'this is an OCL expression with stereotype <<invariant>> in the
context of TypeName' = 'another string'
(cid:14)In the examples. the keywords of OCL are written in boldface in this document. The
(cid:13)boldface has no formal meaning, but is used to make the expressions more readable in
(cid:4)this document. OCL expressions are written using ASCII characters only.
(cid:19)Words in Italics within the main text of the paragraphs refer to parts of OCL
expressions.
(cid:3)
7.2.2 Example Class Diagram
The following diagram is used in the examples in this document.
(cid:18)OMG-UML V1.3 Introduction March 2000 7-3
7
Bank
(cid:25)accountNumber:Integer
(cid:27)0..1
(cid:28)customer
manager (cid:27)0..*
Person (cid:29)Company
managedCompanies
isMarried : Boolean name : String
isUnemployed : Boolean numberOfEmployees : Integer
birthDate : Date (cid:30)employee (cid:30)employer
(cid:25)afirgsetN : aInmteeg :e Srtring (cid:27)0..* (cid:27)0..* (cid:26)stockPrice() : Real
lastName : String
(cid:26)sex : enum {male, female}
wife
income(Date) : Integer
(cid:27)0..1 (cid:31)Job
husband 0..1 title : String
(cid:26)startDate : Date
(cid:26)salary : Integer
Marriage
place : String
!date : Date
(cid:24)Figure 7-1 Class Diagram Example
7.3 Connection with the UML Metamodel
7.3.1 Self
Each OCL expression is written in the context of an instance of a specific type. In an
(cid:5)OCL expression, the reserved word (cid:16)self is used to refer to the contextual instance. For
instance, if the context is Company, then self refers to an instance of Company.
(cid:16)
7.3.2 Specifying the UML context
The context of an OCL expression within a UML model can be specified through a so-
called context declaration at the beginning of an OCL expression. The context
(cid:8)
(cid:11)declaration of the constraints in the following sections is shown.
(cid:0)7-4 OMG-UML V1.3 March 2000
7
(cid:14)If the constraint is shown in a diagram, with the proper stereotype and the dashed lines
(cid:4)to connect it to its contextual element, there is no need for an e xplicit context
(cid:11)declaration in the test of the con straint. The context declaration is optional.
7.3.3 Invariants
(cid:1)The OCL expression can be part of an Invariant, which is a Constraint stereotyped as
an «invariant». When the invariant is associated with a Classifier, the latter is referred
(cid:10)
(cid:4)to as a “type” in this chapter. An OCL expression is an invariant of the typ e and must
(cid:13)be true for all instances of that type at any time. (Note that all OCL expressions that
express invariants are of the type Boolean.)
(cid:3)
For example, if in the context of the Company type in Figure 7-1, the following
expression would specify an invariant that the number of employees must always
(cid:3)
exceed 50:
(cid:3)
self.numberOfEmployees > 50
where self is an instance of type Company. (We can view self as the object from where
(cid:15) (cid:16) (cid:16)
we start the expression.) This invariant holds for every instance of the Company type.
(cid:15)
(cid:1)The type of the contextual instance of an OCL expression, which is part of an
invariant, is written with the context keyword, followed by the name of the type as
(cid:20)
follows. The label (cid:21)inv: declares the constraint to be an «invariant» constraint.
context Company inv:
self.numberOfEmployees > 50
(cid:14)In most cases, the keyword (cid:16)self can be dropped because the context is clear, as in the
above examples. As an alternative for self, a different name can be defined playing the
(cid:10)
part of self:
"
context c : Company inv:
c.numberOfEmployees > 50
(cid:1)This invariant is equivalent to the previous one.
(cid:5)Optionally, the name of the constraint may be written after the (cid:21)inv keyword, allowing
(cid:4)the constraint to be referenced by name. In the following example the name of the
(cid:8)constraint is #enoughEmployees. In the UML metamodel, this name is an attribute of the
metaclass Constraint that is inh erited from ModelElement.
(cid:2)
context c : Company inv enoughEmployees:
c.numberOfEmployees > 50
7.3.4 Pre- and Postconditions
The OCL expression can be part of a Precondition or Postcondition, corresponding to
«precondition» and «postcondition» stereotypes of Constraint associated with an
(cid:5)Operation or Method. The contextual instance (cid:16)self then is an instance of the type that
(cid:18)OMG-UML V1.3 Connection with the UML Metamodel March 2000 7-5
7
owns the operation or method as a feature. The context declaration in OCL uses the
(cid:17)
context keyword, followed by the type and operation declaration. The stereotype of
(cid:20)
constraint is shown by putting the labels ‘pre:’ and ‘post:’ before the actual
(cid:8)
$Preconditions and Postconditions
context Typename::operationName(param1 : Type1, ... ): ReturnType
pre : param1 > ...
%
post: result = ...
%
(cid:1)The name (cid:16)self can be used in the expression referring to the object on which the
(cid:17)operation was called. The reserved word result denotes the result of the operation, if
(cid:4)there is one. The names of the parameters ((cid:23)param1&) can also be used in the OCL
expression. In the example diagram, we can write:
(cid:3)
context Person::income(d : Date) : Integer
post: result = 5000
%
(cid:5)Optionally, the name of the precondition or postcondition may be written after the (cid:23)pre
or post keyword, allowing the constraint to be referenced by name. In the following
’
example the name of the precondition is parameterOk and the name of the
(cid:3) (cid:23)
"postcondition is resultOk. In the UML metamodel, these names are attributes of the
metaclass Constraint that is inherited from ModelElement.
context Typename::operationName(param1 : Type1, ... ): ReturnType
pre parameterOk: param1 > ...
%
post resultOk: result = ...
%
7.3.5 General Expressions
(cid:9)Any OCL expression can be used as the value for an attribute of the UML metaclass
Expression or one of its subtypes. In that case, the semantics section describes the
meaning of the expression.
7.4 Basic Values and Types
In OCL, a number of basic types are predefined and available to the modeler at all
(cid:4)time. These predefined value types are independent of any object model and part of the
(cid:11)definition of OCL.
(cid:0)7-6 OMG-UML V1.3 March 2000
7
(cid:1)The most basic value in OCL is a value of one of the basic types. Some basic types
used in the examples in this document, with corresponding examples of their values,
(cid:12)
are shown in Table7-1.
(cid:10)
Table7-1 )Basic types
*type values
Boolean true, false
Integer 1, -5, 2, 34, 26524, ...
Real 1.5, 3.14, ...
+String 'To be or not to be...'
(cid:5)OCL defines a number of operations on the predefined types. Table7-2 gives some
examples of the operations on the predefined types. See Section7.8, “Predefined OCL
(cid:3)
(cid:1)Types,” on page 7-28 for a complete list of all operations.
Table7-2 ,Operations on predefined types
*type operations
Integer *, +, -, /, abs
Real *, +, -, /, floor
Boolean and, or, xor, not, implies, if-then-else
+String toUpper, concat
The complete list of operations provided for each type is described at the end of this
chapter. Collection, Set, Bag and Sequence are basic types as well. Their specifics will
(cid:8)
(cid:13)be described in the upcoming sections.
7.4.1 Types from the UML Model
Each OCL expression is written in the context of a UML model, a number of
classifiers (types/classes, ...), their features and associations, and their generalizations.
(cid:8)
All classifiers from the UML model are types in the OCL expressions that are attached
(cid:4)to the model.
7.4.2 Enumeration Types
(cid:9)As shown in the example diagram, new enumeration types can be defined in a model
(cid:13)by using:
enum{ value1, value2, value3 }
(cid:1)The values of the enumeration can be used within expressions.
(cid:9)As there might be a name conflict with attribute names being equal to enumeration
values, the usage of an enumeration value is expressed syntactically with an additional
(
pound (#) symbol prefixing the name of the value:
"
(cid:18)OMG-UML V1.3 Basic Values and Types March 2000 7-7
7
#value1
The type of an enumeration attribute is Enumeration, with restrictions on the values for
(cid:4)the attribute.
7.4.3 Let Expression
+Sometimes a sub-expression is used more than once in a constraint. The -let expression
allows one to define a variable that can be used in the constraint.
(cid:10)
context Person inv:
let income : Integer = self.job.salary->sum in
if isUnemployed .then
income < 100
else
/
income >= 100
endif
/
7.4.4 Type Conformance
(cid:5)OCL is a typed language and the basic value types are organized in a type hierarchy.
This hierarchy determines conformance of the different types to each other. You
cannot, for example, compare an Integer with a Boolean or a String.
(cid:8)
(cid:9)An OCL expression in which all the types conform is a valid expression. An OCL
expression in which the types don’t conform is an invalid expression. It contains a type
(cid:3)
(cid:20)conformance error. A type 0type1 conforms to a type type2 when an instance of 0type1
(cid:8)can be substituted at each place where an instance of 0type2 is expected. The type
conformance rules for types in the class diagrams are simple.
(cid:8)
•
Each type conforms to each of its supertypes.
•
(cid:1)Type conformance is transitive: if 0type1 conforms to 0type2, and 0type2 conforms to
(cid:22)
0type3, then 0type1 conforms to 0type3.
(cid:22)
The effect of this is that a type conforms to its supertype, and all the supertypes above.
The type conformance rules for the value types are listed in Table7-3.
Table7-3 1Type conformance rules
Type Conforms to/Is a subtype of
+Set(T) Collection(T)
+Sequence(T) Collection(T)
Bag(T) Collection(T)
Integer Real
(cid:0)7-8 OMG-UML V1.3 March 2000
7
(cid:1)The conformance relation between the collection types only holds if they are
collections of element types that conform to each other. See Section 7.5.14, “Collection
(cid:8)
Type Hierarchy and Type Conformance Rules,” on page7-20 for the complete
conformance rules for collections.
(cid:8)
(cid:1)Table7-4 provides examples of valid and invalid expressions.
Table7-4 4Valid expressions
5OCL expression valid explanation
1 + 2 * 34 yes
1 + 'motorcycle' no type Integer does not conform to type
+String
623 * false no type Integer does not conform to
Boolean
12 + 13.5 yes
7.4.5 Re-typing or Casting
In some circumstances, it is desirable to use a property of an object that is defined on
a subtype of the current known type of the object. Because the property is not defined
(cid:10)
on the current known type, this results in a type conformance error.
(cid:17)
(cid:19)When it is certain that the actual type of the object is the subtype, the object can be re-
(cid:4)typed using the operation ’oclAsType(OclType). This operation results in the same
(cid:17)object, but the known type is the argument 2OclType. When there is an object ’object of
(cid:4)type 3Type1 and 3Type2 is another type, it is allowed to write:
object.oclAsType(Type2) --- evaluates to object with type Type2
An object can only be re-typed to one of its subtype; therefore, in the example, Type2
(cid:2)must be a subtype of 3Type1.
(cid:14)If the actual ty pe of the object is not a subtype of the type to which it is re-typed, the
expression is undefined (see Section7.4.9, “Undefined Values,” on page7-10).
(cid:3)
7.4.6 Precedence Rules
The precedence order for the operations, starting with highest precedence, in OCL is:
•
@pre
•
(cid:11)dot and arrow operations: ‘.’ and ‘->’
•
unary ‘not’ and unary minus ‘-’
(cid:12)
•
‘*’ and ‘/’
•
‘+’ and binary ‘-’
•
‘if-then-else-endif’
(cid:18)OMG-UML V1.3 Basic Values and Types March 2000 7-9
7
•
‘<’, ‘>’, ‘<=’, ‘>=’
•
‘=’, ‘<>’
•
‘and’, ‘or’ and ‘xor’
•
‘implies’
$Parentheses ‘(’ and ‘)’ can be used to change precedence.
7.4.7 Use of Infix Operators
The use of infix operators is allowed in OCL. The operators ‘+’, ‘-’, ‘*’. ‘/’, ‘<‘, ‘>’,
‘<>’ ‘<=’ ‘>=’ are used as infix operators. If a type defines one of those operators with
(cid:4)the correct signature, they will be used as infix operators. The expression:
a + b
is conceptually equal to the expression:
a.+(b)
(cid:4)that is, invoking the ‘+’ operation on a with b as the parameter to the operation.
The infix operators defined for a type must have exactly one parameter. For the infix
operators ‘<‘, ‘>’, ‘<=’, ‘>=’, ‘<>’, ‘and’, ‘or’, and ‘xor’ the return type must be
(cid:17)
7Boolean.
7.4.8 Comment
8Comments in OCL are written following two successive dashes (minus signs).
Everything immediately following the two dashes up to and including the end of line is
part of the comment. For example:
"
-- this is a comment
7.4.9 Undefined Values
(cid:19)Whenever an OCL expression is being evaluated, there is a possibility that one or more
of the queries in the expression are undefined. If this is the case, then the complete
(cid:17)
expression will be undefined.
(cid:3)
There are two exceptions to this for the Boolean operators:
1. True OR-ed with anything is True
2. False AND-ed with anything is False
The above two rules are valid irrespective of the order of the arguments and the above
rules are valid whether or not the value of the other sub-expression is known.
9
(cid:0)7-10 OMG-UML V1.3 March 2000