Introduction to OCL Fernando Brito e Abreu (fba@di.fct.unl.pt) - PDF document

Introduction to OCL Fernando Brito e Abreu (fba@di.fct.unl.pt) Universidade Nova de Lisboa (http://www.unl.pt) QUASAR Research Group (http://ctp.di.fct.unl.pt/QUASAR) Abstract  Why formalization?  Formalization in OO  OCL types and operators  Design by contract  Collection operations  Examples 1

Why is formalization required?  Graphical elements of the diagrammatic specifications are very powerful and obvious  easy to understand how they fit together ;)  Modeling details, such as uniqueness and referential restraints, limitations and other constraints are expressed ambiguously  often they cannot be conveyed graphically  examples: Christian marriage, who‟s the boss, ... Who‟s the boss of the boss? Employee name : string boss 0..1 2

Christian marriage On rails … 0..1 Train train_id : integer 1 front_car Car waggon_id : integer * waggons 1 loco Locomotive Waggon horse_power : integer number_places : integer 3

The quest for formalization ...  Accuracy and unambiguity in specification is the aim of the branch of computer science known as “ formal methods ”  Several attempts have been made to combine them with object- oriented modeling … Formal methods in OO (1/4)  Extending and adapting an existing formal languagewith object-oriented constructs  Ex : Z++, Object-Z , VDM++  This approach is not in line with industrial practice trends to use the simple, but powerful, graphical notations in OOAD.  Most practitioners are not at ease in using traditionalformalspecification languages... 4

Z, Z++ and Object Z  Z is a specification language developed by the Programming Research Group at Oxford University  "Understanding Z", J.M.Spivey, Cambridge U Press, 1988  Z is used for describing and modeling computing systems  It is based on axiomatic set theory and first order predicate logic  Z is written using many non-ASCII symbols  Z++ is an object-oriented extension of Z  "Z++, an Object-Oriented Extension to Z", Lano, Z User Workshop, Oxford 1990, Springer Workshops in Computing, 1991, pp.151-172  Object Z is another object-oriented extension of Z developed at University of Queensland, Australia  "Object Orientation in Z", S. Stepney et al eds, Springer 1992 An Object- Z extract … 5

Formal methods in OO (2/4)  Complementing diagrammatic notations with some existing formallanguage constructs  Ex: Syntropy (subset of Z combined with OMT), ROOA (A. Moreira), Metamorphosis (J. Araújo)  Compromise solution, joining the benefits of graphicalmodelingand formallanguages  Drawback1: conceptual gap between formalisms  Drawback2: same as in previous approach A bit of Syntropy 6

Formal methods in OO (3/4)  Use of a constraint language to express design by contractmodeling issues(B.Meyer)  Ex: BON (Business Object Notation) object-oriented method (Waldén 95).  Has a full-fledged textual assertion mechanism, allowing to specify system structure and semantics (constraints, invariants, properties of expected results)  Bridges the semantic gap but failed widespread acceptance (too tied to Eiffel language world)  Acceptance often comes from standardization ... BON: Elevator example 7

Formal methods in OO (4/4)  The last and more promising road is OCL  Allows to specify invariants, preconditions, postconditions, guard conditions, and other types of constraints (restrictions)  Therefore supports design by contract as proposedby Bertrand Meyer  Is a part of the UML standard published by the OMG ( let‟s have a look at it ...)  Used in the standard itself to clarify the semanticsof the graphicalnotations (why?) Unclear semantics of the UML metamodel (example) Can the grandpa inherit from the grandson? 8

Object Constraint Language  It is a formal, yet simple notation, to be used jointly with UML diagrams  Its syntax has some similarities to those of some OO programming languages  It is underpinned by mathematical set theory and logic, like in formal languages  However it was designed for usability and is easily grasped by those familiar with OO modeling concepts (particularly UML ones) Object Constraint Language  OCL brings the best of the previous approaches:  simplicity and powerfulness of graphical notations  preciseness and non-ambiguity granted by formality, in a usable and conceptually integrated fashion  Moreover, since it is a part of UML, it has become a de jure standard  also de facto because there is an increasing number of UML tools supporting OCL 9

OCL syntax  OCL is strongly type checked  Style convention is Camel Case starting with:  Lower case letter: objects, attributes, operations  Upper case letter: classes  Dot notation is used for:  Attribute access  Operation access  Association end access (navigation in diagram) OCL examples Class : Operations :  Person, Date  boy.marries(girl), girl.age() Note : parameterless operations can be written with or without parenthesis Objects :  boy, girl Class attribute :  Person.allInstances Attributes :  boy.name Navigation through an  girl.birthday association :  boy.spouse.name 10

Navigation example  Consider the object:  bill: Customer  Attribute access  bill.name  Operation access  bill.age()  Navigation through associations  bill.cards  bill.cards.color Class invariants  Invariants are constraints that represent conditions that must be met by all class instances, atall times.  Their context is, therefore, a class  Context can be represented differently: Example: -- every customer must be at least 18 years old OMG standard USE tool Customer context Customer inv CustomerAge: inv CustomerAge: age() >= 18 age() >= 18 11

Design by contract PRE-CONDITION POST-CONDITION CLIENT Obligation Right SUPPLIER Right Obligation Operation assertions  Pre-conditions are constraints that must be true before an operation is executed  In the design by contract paradigm, they represent the rights of the object that offers the service or, if you want, the client responsibilities.  Post-conditions are constraints that must be true when the operation ends its execution  They represent the obligations to be fulfilled by the object that offers the service, or, if you want, the client rights. 12

Operation assertions: example  The context of both pre and post-conditions is, therefore, an operation: This is a scope indicator Math::factorial(value:Integer):Integer pre :value >= 0 post :result = if value = 0 then 1 else value * factorial(value-1) endif OCL types OclAny is the superclass of all classes OclAny in OCL (even user defined ones) Real String Boolean Collection Enumeration Integer Set Bag Sequence 13

OclAny  OclAny is the supertype of all model types  Features on OclAny are available on each object in all OCL expressions  To avoid name conflicts between features in the model and features inherited from OclAny, all names on the OclAny features start with „ocl‟ Features of OclAny (note: object is the instance of OclAny ) object = (object2 : OclAny) : Boolean -- True if object is the same object as object2 . object <> (object2 : OclAny) : Boolean -- True if object is a different object as object2 . object.oclType : OclType -- The type of an object 14

Features of OclAny (note: object is the instance of OclAny ) object.oclIsTypeOf(t : OclType) : boolean -- true if t is the type of self post: result = (object.oclType = t) object.oclIsKindOf(t : OclType) : boolean -- true if t is either the type of object or one of its supertypes post: result = object.oclType.allSuperTypes ->includes(t) or (object.oclType = t) Features of OclAny: example mario: Student (Student is subclass of Person) mario.oclType -- results in Student mario.oclIsTypeOf( Student )-- is true mario.oclIsTypeOf( Person ) -- is false mario.oclIsKindOf( OclAny) -- is true mario.oclIsKindOf( Person ) -- is true 15

OclType  All types defined in an UML model, or pre- defined within OCL, have a type  That type is an instance of the OclType metaclass  Access to OclType allows the modeler to access the model meta-level (reflexivity) Reflexivity: features of OclType (note: type is the instance of OclType ) type.name : String type.supertypes : Set(OclType) The name of type The set of all direct supertypes of type . post: type.allSupertypes->includesAll(result) type.attributes : Set(String) The set of names of the attributes of type.allSupertypes : Set(OclType) type , as they are defined in the model The transitive closure of the set of all supertypes of type type.associationEnds : Set(String) The set of names of the navigable type.allInstances : Set(type) associationEnds of type , as they are The set of all instances of type and all its defined in the model subtypes type.operations : Set(String) Example: The set of names of the operations of Customer.allInstances type , as they are defined in the model Transaction.allInstances 16