I ntroduction to OCL 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, ... 1
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 language with 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 traditional formal specification languages ... 2
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 … 3
Formal methods in OO (2/4) � Complementing diagrammatic notations with some existing formal language constructs – Ex: Syntropy (subset of Z combined with OMT), ROOA (A. Moreira), Metamorphosis (J. Araújo) � Compromise solution, joining the benefits of graphical modeling and formal languages – Drawback1: conceptual gap between formalisms – Drawback2: same as in previous approach A bit of Syntropy 4
Formal methods in OO (3/4) � Use of a constraint language to express design by contract modeling 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 5
Formal methods in OO (4/4) � The last and more promising road is OCL � 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 semantics of the graphical notations � Allows to specify invariants, preconditions, postconditions, guard conditions, and other types of constraints (restrictions) � Therefore supports design by contract 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) 6
Object Constraint Language � OCL brings the best of the previous approaches: – simplicity and powerfulness of graphical notations – preciseness and unambiguity 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 (soon de facto ?) Adding OCL to UML models Modeling Tools Workload Workload (Model Objects) Graphic Editors Generator UML Model System X Diagrams UML Model Expression Results OCL Tool Expressions Repository System Y Evaluator Diagrams System Z Diagrams OCL Expressions (Model Constraints) 7
Some bits of history ... Version Date Submitters / Supporters Rational, Microsoft, Hewlett-Packard, Oracle, Sterling 1.1 Sep Software, MCI Systemhouse, Unisys, ICON (36 p.) 1997 Computing, IntelliCorp, i-Logix, IBM , ObjecTime, Platinum Technology, Ptech, Taskon, Reich Technologies, Softeam 1.2 … … 1.3 June … 1999 1.4 … … Submitters: Boldsoft, Rational, IONA, Adaptive Ltd. 2.0 Supporters : Klasse Objecten, Borland, Kings Jan (214 p.) 2003 College, University of Bremen, Dresden University of Technology, Kabira Technologies, IBM , Telelogic, University of Kent, Project Technology, University of York, Compuware, Syntropy Ltd., Oracle, Softeam Objectives of OCL 2.0 � Define a MOF 2.0-compliant metamodel for OCL. – This metamodel should define the concepts and semantics of OCL and act as an abstract syntax for the language. � (Re)define the OCL 1.4 syntactical definition – That is done by means of a grammar, as a concrete syntax expressing the abstract syntax defined above. � To allow for alternative concrete syntaxes (e.g. Java-like syntax or visual constraint diagrams) – This is achieved by defining a strict separation between the metamodel and the concrete syntax. 8
OCL features evolution � OCL 1.* is side-effect free ( only selectors allowed) – Selectors are query operations which return a value but do not change the object state (their label isQuery = true) � OCL 2.* allows expressing messages sent by components, classes or other constructs that may have behavior (using the OclMessage concept) – This allows the specification of behavioral constraints � UML 1.4 predefined types and operations are defined as the OCL 2.0 Standard Library. � The concrete syntax of OCL 2.0 is backwards compatible with OCL 1.4 !!! OCL types OclAny Real String Boolean Collection Enumeration Integer Set Bag Sequence 9
Standard operators Type Operations Boolean =, not, and, or, xor, implies, if-then-else Real =, +, -, *, /, abs, floor, max, min, <, >, <=, >= Integer =, +, -, *, /, abs, div, mod, max, min, <, >, <=, >= String =, size, toLower, toUpper, concat, substring Expressing class invariants � Constraints that represent conditions that must be met by all class instances, at all times. – Their context is, therefore, a class, hereafter represented in the first line, underlined, as in: Sequence self.oclIsKindOf( Collection ) -- sequence inherits from Collection and therefore its instances can be used where a collection is allowed (this is a comment) Percentage (self >= 0) and (self <=1) -- Percentage inherits from Real 0 is 0% and 1 is 100% 10
Expressing 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. Design by Contract PRE-CONDITION POST-CONDITION CLIENT Obligation Right SUPPLIER Right Obligation 11
Operation assertions: examples � The context of both pre and post-conditions is, therefore, an operation: Sequence::prepend(object: T): Sequence(T) post: result->size() = self@pre->size() +1 post: result->at(1) = object “::” is a scope indicator “- > ” is used for applying an operation to a collection “ @pre ” is a timing tag (state at preconditions evaluation) Expressing operation semantics Date::isBefore(t:Date): Boolean = if self.year = t.year then if self.month = t.month then self.day < t.day Date else day : In teger mon th : In tege r self.month < t.month ye ar : In teger now : Date endif else isBefore(t : Date) : Boolean isAfter(t : Date) : Boolean self.year < t.year isEqual(t : Date) : Boolean endif ye arsSince(t : Da te) : In teger today() : Date 12
Collection Collection operations � Collection is an abstract Set Bag Sequence class Collection s ize() : Integer i ncludes (obj ect : OclAny) : Boolean count(object : OclAny) : Integer includesAll(c2 : Collection(T)) : Boolean i s Empty() : Boolean notEmpty() : Boolea n s um () : Real exists (expr : OclExpres sion) : Boolean forAl l(expr : Ocl Expres sion) : Boolea n iterate(expr : OclExpres sion) : OclType Set operations Set Sets are non ordered union(s et2 : Set(T)) : Set (T) union(bag1 : Bag(T)) : Bag (T) collections =(s et2 : Set(T)) : Boolean without inters ection(s et2 : Set(T)) : Set (T) duplicates. inters ection(bag1 : Bag(T)) : Bag (T) -(s et2 : Set(T)) : Set (T) including(object : T) : Set (T) excluding(object : T) : Set (T) s ym m etricDifference(s et2 : Set(T)) : Set (T) s elect(expr : OclExpres s ion) : Set (T) reject(expr : OclExpres s ion) : Set (T) collect(expr : OclExpres s ion) : Set (expr.evaluationType()) count(object : T) : Integer as Sequence() : Sequence (T) as Bag() : Bag (T) 13
Recommend
More recommend
