Object Constraint Language

1. Object Constraint Language Himanshu Neema Krishnakumar Balasubramanian Jeff Parsons November 4, 2003

2. Why OCL? ADVANTAGES DISADVANTAGES Graphical Languages Easy to use Not rigorous Easy to read Expressing rule exceptions difficult Natural Languages Most familiarAmbiguous 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)

3. 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

4. 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”

5. 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)

6. OCL Basic Types

7. GME Model Elements

8. Himanshu’s part Let’s talk about interesting parts of the OCL… 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

9. Expression Context and Self • 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. package main::components context BondGraph inv: self.numGraphElements > 0 endpackage Alternative to ‘self’: context bg: BondGraph inv EnoughElementsConstraint: bg.numGraphElements > 0 context is UML type BondGraph Refers to an instance of BondGraph

10. Invariants, pre- and post-conditions • 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. context BondGraph::totalFlow(numElements: Integer) : Integer pre checkQty: numElements > 10 post checkResult: result > 100 @pre: to access prev. value of a param at post-condition time Could be recursive, i.e. can use itself, e.g. result = result + 1

11. Let Expressions and Definition Constraints • 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. 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()

12. 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

13. Properties and Navigation.. manager employee Person Bool:isUnemployed Integer: age Company Job wife • 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 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()

14. 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

15. 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> | expr-with-elem-and-acc) • e.g. collection->iterate (x:T1; acc:T2 = Set{}| acc->including (x.getName()))

16. 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

17. 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

18. 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

19. Navigation • Assoc. 0..1 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

20. 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]

21. 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

22. 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

23. 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

24. Previous values in Post-Conditions • Expression can refer: • To value at start • To value upon completion • OCL Example context Person::birthdayHappens() post: age = age@pre + 1 • More Examples • Difference between a.b@pre.c & a.b@pre.c@pre

25. 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’)

26. Collection Operations • Iterate • Mother of All Operations collection->iterate (elem:Type; acc: Type = <expression> | 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))

27. GME & OCL • Only invariants can be written • Dos and Don’ts (Refer to manual) • Fav. Quote from Manual “As an expert GME user knows, …”  • Detailed usage instructions

28. 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

29. Questions ?