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
Recommend
More recommend