Institute for Software Integrated Systems Vanderbilt University Object Constraint Language Himanshu Neema Krishnakumar Balasubramanian Jeff Parsons November 4, 2003

Why OCL? ADVANTAGES DISADVANTAGES Graphical Languages Easy to use Not rigorous Easy to read Expressing rule exceptions difficult Natural Languages Most familiar Ambiguous Formal Languages Powerful Require mathematics Unambiguous Not for everyone OCL fills a useful niche -- Unambiguous, but reasonably easy to use Intended for systems and business programmers Can also supplement graphical languages (GME)

OCL Ancestry Ernst Zermelo introduces set theory in 1908 Given present form by Adolph Fraenkel in 1922 Z (“zed”) based on set theory and predicate logic Syntropy adopted Z ideas, is direct ancestor of OCL OCL developed at IBM as a business modeling language OMG Request for Proposal (RFP) in 1996, submitted in 1997

OCL Overview - Properties  Originally intended for use within UML  Later used in other OMG specs  Used with graphical languages (GME)  Pure expression language  Not a programming language  No actions  No side effects  Typed language  Evaluation of expressions is “instantaneous”

OCL Overview - Uses  To specify invariants  type and class invariants in class models  invariants for UML metamodel itself  To specify constraints on “operations”  pre-conditions  post-conditions  let-expressions  definition constraints  To specify guards in state transitions  As a navigation language (Associations)

OCL Basic Types

GME Model Elements

Institute for Software Integrated Systems Vanderbilt University Himanshu’s part Constraints are key to success of any model. Just think how an instance of the model of society would behave when it doesn’t impose any constraint.. Imagine the possibilities -Himanshu Neema. The more constraints one imposes, the more one frees one's self. And the arbitrariness of the constraint serves only to obtain precision of execution. -Igor Stravinsky With OCL constraints you don’t have to deal with ambiguities like when somebody wrote a comment the formula of water is H2O, some highly intelligent user interpreted the formula to be H-I-J-K-L-M-N-O -Unknown Don’t constrain yourself not to smoke, it could even help you loose weight – one lung at a time - Unknown Let’s talk about interesting parts of the OCL…

Expression Context and Self package main::components context BondGraph inv: self.numGraphElements > 0 endpackage Alternative to ‘self’: context bg: BondGraph inv EnoughElementsConstraint: bg.numGraphElements > 0 Every OCL expression must have a context – basically the UML type to which the OCL constraint has to be applied Self refers to a contextual instance of the UML type in context Package context: Packages are used to organize UML types based on their purpose. Can be omitted when clear; Usually not used unless the model is big; if present, OCL constraints will be applied to UML types only in this package. context is UML type BondGraph Refers to an instance of BondGraph

Invariants, pre- and post- conditions context BondGraph::totalFlow(numElements: Integer) : Integer pre checkQty: numElements > 10 post checkResult: result > to access prev. value of a param at post-condition time Invariants on a UML type are the constraints which must evaluate to ‘true’ for every instance of this type. Pre-condition is a constraint associated with a behavioral feature of a UML type. When present, the pre-condition must evaluate to ‘true’ whenever a method can be invoked. Typically used to check if the parameters are legal. Post-condition is opposite of Pre-condition in the sense that it is checked after a method invoked has been executed. Typically used to check if the result being returned is legal. Could be recursive, i.e. can use itself, e.g. result = result + 1

Let Expressions and Definition Constraints context Person inv: let income:Integer = self.job.salary->sum() in if isUnemployed then self.income < 100 else self.income >= 100 endif context Person def: let income:Integer = self.job.salary->sum() To define an attribute or operation that can be used in constraints later just by its name Attributes, variables, and constraints declared using ‘let’ expressions has a scope of the current constraint that is being defined. Attributes, variables, and constraints defined using ‘def’ are reusable. They can be used in the same context as where any other property of a UML type can be used.

Other important specs Type Conformance rules, e.g. 1+false is invalid Casting: using oclAsType. If B inherits from A, then object pointing to B can be casted to A Precedence rules, e.g ‘*’  ‘/’ Infix operators, e.g if A has operator defined ‘+’, we can use a1+a2 [~ a1.+(b)] Undefined values Identity and Equality with ‘=‘ and ‘==‘ Comments: using ‘--’, e.g. “-- this is a comment” Enumeration stereotypes

Properties and Navigation.. context Person inv: let income:Integer = self.job.salary->sum() in if isUnemployed then self.income < 100 else self.income >= 100 endif context Person def: let income:Integer = self.job.salary->sum() Navigating association using opposite end’s rolename property like – object.rolename Returned type depends on the cardinality of association, if 0..1 or 1 then returned type is same as the associated type, else if more than 1 is possible then the returned type would be a set, e.g. context Company inv: self.manager.isUnemployed = false [example of associated type inv: self.employee->noyEmpty() [example of set] Note: a single object returned can also be used as a Set. If rolename is absent, name of the opposite association end type starting with a lowercase can be used. In case of ambiguity rolename must exist. If rolenames are ambiguous, they cannot be used in OCL. If cardinality is [0..1], this expression comes very handy context Person inv: self.wife->notEmpty() Navigation to association classes (in GME, connections): No rolename thus class name is used starting with a lowercase letter context Person inv: self.job Person Bool:isUnemployed Integer: age Company Job employee manager wife

Properties and Navigation In case of ambiguity, qualifiers need to be used, e.g in above figure in context of Person – self.employeeRanking[bosses]->sum() has to be used for employeeRankings belonging to collection of bosses. Navigation to association class, in case of recursion, the expression needs to be qualified. For navigating from an association class to associated types, use rolenames, e.g. context job inv: self.employee.age > 21 Navigation through qualified associations – uses one or more qualifier attributes to select the objects at the other end of the association Navigation to a specific type with full qualified path using package names, e.g. main::roster::Person type As described earlier, for accessing overridden properties of supertypes, we can use the casting e.g. if B inherits from A and overrides A’s property ‘prop1’, then context B inv: self.oclAsType(A).prop1 -- accesses property ‘prop1’ of supertype A self.prop1 -- accesses property ‘prop1’ of B Note: Again, qualifier is needed in case of ambiguity

Collections: Set, Bag, and Sequence  Collection is an abstract type – powerful means  Set, Bag, and Sequence derive from Collection  Set {1, 2, 5, 3} – no repetitions, order not necessary  Bag {1, 2, 3, 3, 2} – repetitions allowed, order not necessary  Sequence {1, 2, 2, 3, 5} – repetitions allowed, but order is necessary  Type conformation rules  Collection operations: Select, Reject, Collect  e.g. collection->collection_operation(v: Type| expr-with-v)  expr-with-v must be a boolean expression for Select and Collect  ForAll, Exists  Iterate Operation  Collection->iterate(elem:Type; acc:Type = | expr-with-elem-and- acc)  e.g. collection->iterate (x:T1; acc:T2 = Set{}| acc->including (x.getName()))

MCL – GME’s Meta Constraint Language - Issues Extension of OCL to GME specific types, all constraints e.g. collections, definitions, should also work with GME types MCL maintenance with upgrades in OCL, e.g. still not 100% compliant with OCL 2.0 Performance of MCL Parser and Constraint Evaluator – critical. Different heuristics can be used depending upon size & structure of the model and the type of constraint in question Error reporting – Detailed contents, User-friendly dialogs, Evaluation progress monitor, User interaction during evaluation When OCL or MetaGME paradigm is updated older constraints should still be compatible. Abort operation when any priority 1 constraint is violated Constraint preferences

MCL – GME’s Meta Constraint Language - Differences All predefined iterators are supported except ‘sortedBy’ MCL features have been added with extra security Extension of pre-defined OCL types with useful features e.g. meta-kind features, e.g. ocl::String::match(ocl::String) GME specific types have been introduced, e.g. gme::Object && gme::Folder, gme::Reference For gme::FCO kinds or for kinds whose ‘is Abstract’ property is ‘true’, it cannot be referred in constraints as the information is lost in the interpreted meta. Interface and Implementation inheritance cannot be distinguished as again the knowledge will be lost during interpretation GME specific features like – gme::FCO::connectedFCOs meta  gme  ocl  exception/undefined [3 namespaces] Read-only constraints defined in imported libraries

Navigation  Association Ends  Object.rolename  Return value: Set  OCL Example context Company inv: self.manager.isUnemployed = false inv: self.employee->notEmpty()  Missing Rolenames  name of type  Reflexive associations

Navigation  Assoc multiplicity  Return value: Both Set as well as Object  OCL Example context Company inv: self.manager->size() = 1 inv: self.manager.age > 40  Useful in navigation context Person inv: self.wife->notEmpty() implies self.wife.sex = Sex::female

Navigation  To Association Classes  Dot and name of class  OCL Example context Person inv: self.job  Reflexive associations  Distinguish direction  Qualifiers context Person inv: self.job[employers]

Navigation  From Association Classes  Dot and role-name  Return value  Always one Object  OCL Example context Job inv: self.employer.numberofEmployees >= 1 self.employee.age > 21

Navigation  Overridden Properties  OCL Example context Dependency inv: self.src <> self  Ambiguity  Normal Navigation  Association class Navigation context Dependency inv: self.oclAsType (Dependency).src inv: self.oclAsType (ModelElement).src

Predefined Properties oclIsTypeOf (t: OclType) : Boolean oclIsKindof (t: OclType) : Boolean oclInState (s: OclState) : Boolean oclIsNew(): Boolean oclAsType (t: OclType) : instance of OclType  OCL Example context Person inv: self.oclIsTypeOf(Person) – True inv: self.oclIsTypeOf(Company) -- False

Previous values in Post-Conditions  Expression can refer:  To value at start  To value upon completion  OCL Example context Person::birthdayHappens() post: age = + 1  More Examples  Difference between &

Collection Operations  Set  Bag  Sequence  Operations  select(), reject()  collect()  forall()  OCL Examples context Company inv: self.employee->reject(isMarried)->isEmpty() self.employee->collect(person| person.birthdate) self.employee->forAll (p: Person | p.forename = ‘Jack’)

Collection Operations  Iterate  Mother of All Operations collection->iterate (elem:Type; acc: Type = | expression-with-elem-and-acc)  i.e., collection->collect (x: T | x.property)  Is identical to collection->iterate (x: T; acc: T2 = Bag{} | acc->including (x.property))

GME & OCL  Only invariants can be written  Do s and Don’t s (Refer to manual)  Fav. Quote from Manual “As an expert GME user knows, …”  Detailed usage instructions

OCL 2.0  OCL 1.4  No metamodel  Integration problems with UML  OCL 2.0  Define MOF compliant metamodel  Define concepts and semantics  Act as an abstract syntax  (Re)Define OCL 1.4 as concrete syntax of the above syntax  Separation between metamodel and concrete syntax  Alternative concrete syntaxes (e.g. visual constraint diagrams)  Metamorphosis  Constraint language  Object query language  Behavioural constraints

Questions ?