From OCL to Typed First-order Logic

Size: px

Start display at page:

Download "From OCL to Typed First-order Logic"

Brianna Watson
5 years ago
Views:

1 22c181: Formal Methods in Software Engineering The University of Iowa Spring 2008 From OCL to Typed First-order Logic Copyright Reiner Hähnle and Cesare Tinelli. Notes originally developed by Reiner Hähnle at Chalmers University and modified by Cesare Tinelli at the University of Iowa. These notes are copyrighted materials and may not be used in other course settings outside of the University of Iowa in their current form or modified form without the express written permission of one of the copyright holders. 22c181: Formal Methods in Software Engineering p.1/15

2 Contents Overview of KeY UML and its semantics Introduction to OCL Specifying requirements with OCL Modelling of Systems with Formal Semantics Propositional & First-order logic, sequent calculus OCL to Logic, horizontal proof obligations, using KeY Dynamic logic, proving program correctness Java Card DL Vertical proof obligations, using KeY Wrap-up, trends 22c181: Formal Methods in Software Engineering p.2/15

3 Formal Verification UML OCL Java I Translation FO Logic Dyn. Logic I I, = Real World Obj. Diagr. Snapshot/ LTS Calculus FO Model Kripke Str. Sequent Calculus 22c181: Formal Methods in Software Engineering p.3/15

4 OCL Context Declarations as Universal Quantifiers Classifier Context (Invariants) context typename inv Boolean OclExpression-with-self 22c181: Formal Methods in Software Engineering p.4/15

5 OCL Context Declarations as Universal Quantifiers Classifier Context (Invariants) context typename inv Boolean OclExpression-with-self Equivalent to universally quantified expression inv typename.allinstances() > forall(x OclExpression-with-x) 22c181: Formal Methods in Software Engineering p.4/15

6 OCL Context Declarations as Universal Quantifiers Classifier Context (Invariants) context typename inv Boolean OclExpression-with-self Equivalent to universally quantified expression inv typename.allinstances() > forall(x OclExpression-with-x) Example context Person inv self.age >= 0 inv Person.allInstances() > forall(x x.age >= 0) 22c181: Formal Methods in Software Engineering p.4/15

7 Translating Universal Quantifiers from OCL to FOL Universally quantified OCL expression inv typename.allinstances > forall(x OclExpression-with-x) 22c181: Formal Methods in Software Engineering p.5/15

8 Translating Universal Quantifiers from OCL to FOL Universally quantified OCL expression inv typename.allinstances > forall(x OclExpression-with-x) Translation T to universal quantifier over variable x of type typename x.t(oclexpression-with-x) 22c181: Formal Methods in Software Engineering p.5/15

9 Translating Universal Quantifiers from OCL to FOL Universally quantified OCL expression inv typename.allinstances > forall(x OclExpression-with-x) Translation T to universal quantifier over variable x of type typename x.t(oclexpression-with-x) Example inv Person.allInstances() > forall(x x.age >= 0) T x : Person x.(t(x.age >= 0)) 22c181: Formal Methods in Software Engineering p.5/15

10 Quantification over Existing Objects If x is variable of type C from UML context, then x.φ quantifies over all objects typeable with C We want only the created objects in the current snapshot! 22c181: Formal Methods in Software Engineering p.6/15

11 Quantification over Existing Objects If x is variable of type C from UML context, then x.φ quantifies over all objects typeable with C We want only the created objects in the current snapshot! Assume that each class C has Boolean attribute < created > I(< created >)(o) is true iff o has been created in state described by I 22c181: Formal Methods in Software Engineering p.6/15

12 Quantification over Existing Objects If x is variable of type C from UML context, then x.φ quantifies over all objects typeable with C We want only the created objects in the current snapshot! Assume that each class C has Boolean attribute < created > I(< created >)(o) is true iff o has been created in state described by I Instead of use quantifier defined as: x.φ <-> x.(x.< created > -> φ) Instead of use quantifier defined as: x.φ <-> x.(x.< created > & φ) 22c181: Formal Methods in Software Engineering p.6/15

13 Translating OCL to FOL: Attributes Attributes OCL constraint with attribute x.age >= 0 class name Person name:string string name compartment attribute compartment attribute names attribute types 22c181: Formal Methods in Software Engineering p.7/15

14 Translating OCL to FOL: Attributes Attributes OCL constraint with attribute x.age >= 0 UML attribute semantics I(age) function from I(Person) to I(int) class name Person name:string string name compartment attribute compartment attribute names attribute types 22c181: Formal Methods in Software Engineering p.7/15

15 Translating OCL to FOL: Attributes Attributes OCL constraint with attribute x.age >= 0 UML attribute semantics I(age) function from I(Person) to I(int) class name Person name:string string attribute names attribute types name compartment attribute compartment FOL type hierarchy & signature (fragment) T = {Person,...,int,...} FSym = {age} with age : Person int PSym = {>=,<=,>,<,...} 22c181: Formal Methods in Software Engineering p.7/15

16 Translating OCL to FOL: Attributes Attributes OCL constraint with attribute x.age >= 0 UML attribute semantics I(age) function from I(Person) to I(int) class name Person name:string string attribute names attribute types name compartment attribute compartment FOL type hierarchy & signature (fragment) T = {Person,...,int,...} FSym = {age} with age : Person int PSym = {>=,<=,>,<,...} FOL translation T (x.age >= 0) = age(x)>=0 22c181: Formal Methods in Software Engineering p.7/15

17 Notational Conventions Allow postfix-dot notation for functions that model attributes Example age(x)>=0 T x.age>=0 In simple cases FOL translation looks exactly like OCL: OCL expressions w/o iterators are alternative concrete syntax of FOL 22c181: Formal Methods in Software Engineering p.8/15

18 Notational Conventions Allow postfix-dot notation for functions that model attributes Example age(x)>=0 T x.age>=0 In simple cases FOL translation looks exactly like OCL: OCL expressions w/o iterators are alternative concrete syntax of FOL No generic types in Java Card and FOL (such as Set(Person)) Translation generates suitable flat types on-the-fly SetOfPerson, SequenceOfPerson, etc. Shorthand for sets of objects: Vehicle{}, Person{}, int{} 22c181: Formal Methods in Software Engineering p.8/15

19 Assorted Remarks FOL translation of OCL attribute interpreted as total function Value of an attribute might benull Symbols with fixed interpretation for many OCL properties <=, size, includes, +, 17, self, result, etc. Correct intended semantics guaranteed by sound calculus rules (automatically loaded) If owner type of functions that model attributes and operations is required to resolve overloading, then write it in front: Person ::age(x), Person{} ::includes(siblings(self), p) 22c181: Formal Methods in Software Engineering p.9/15

20 Translating OCL to FOL: Associations Person Associations name:string age:int query getname():string setage(newage:int):int a 1 mother 1 father a Multiplicity 1: like attributes, but no dot notation Function Example: supplier-role-name : client-type supplier-type father : Person Person Use explicit role name if present, otherwise default role name not(self.father = self.mother) T!(father(self). = mother(self)) 22c181: Formal Methods in Software Engineering p.10/15

21 Translating OCL to FOL: Associations Person Associations name:string age:int query getname():string setage(newage:int):int a * siblings * nephews Other multiplicity than 1: a Function supplier-role-name : client-type Supplier-type{} 22c181: Formal Methods in Software Engineering p.11/15

22 Translating OCL to FOL: Associations Person Associations name:string age:int query getname():string setage(newage:int):int a * siblings * nephews Other multiplicity than 1: a Function supplier-role-name : client-type Supplier-type{} Example: siblings : Person Person{} self.siblings = self.nephews T siblings(self). = nephews(self) Problem: no rules for equality of sets of objects extensionality 22c181: Formal Methods in Software Engineering p.11/15

23 Translating OCL to FOL: Associations Person Associations name:string age:int query getname():string setage(newage:int):int a * siblings * nephews Other multiplicity than 1: a Function supplier-role-name : client-type Supplier-type{} siblings(self). = nephews(self) expanded into: p.( Person{}::includes(siblings(self), p) <-> Person{}::includes(nephews(self), p)) 22c181: Formal Methods in Software Engineering p.11/15

24 Translating OCL to FOL: allinstances() Person allinstances() name:string age:int query getname():string setage(newage:int):int a a 1 mother 1 father Argument of OCL quantifier forall, exists Analogous treatment to class context declaration Example Person.allInstances() -> forall(age >= 0) T x.(x.age>=0) 22c181: Formal Methods in Software Engineering p.12/15

25 Translating OCL to FOL: allinstances() Person allinstances() name:string age:int query getname():string setage(newage:int):int a 1 mother a Other collection property than quantifier 1 father For T.allInstances() create constant T{}::allInstances : T{} Add definition of T{}::allInstances to goal antecedent: x. T{}::includes(T{}::allInstances, x) Example for translation of allinstances() Person.allInstances() -> size() = 1 T Person{}::size(Person{}::allInstances). = 1 22c181: Formal Methods in Software Engineering p.13/15

26 Translating OCL to FOL: Important Issues In many cases FOL translation follows OCL closely Some collection properties have complicated translations (select, reject) Translator optimizes whenever possible Sometimes, translation declares new function symbols Definitions placed in antecedent (ie, left) of sequent arrow ==> Details of translation (see also course web page): B. Beckert, U. Keller, P Schmitt: Translating the OCL into First-order Predicate Logic A. Roth & P. Schmitt Formal Specification, Section c181: Formal Methods in Software Engineering p.14/15

27 Horizontal Verification: Behavioural Subtyping Substitution principle (Liskov, 1993) Let φ be a property provable about objects x of type T. Then φ should be true for objects y of type S where S T. 22c181: Formal Methods in Software Engineering p.15/15

28 Horizontal Verification: Behavioural Subtyping Substitution principle (Liskov, 1993) Let φ be a property provable about objects x of type T. Then φ should be true for objects y of type S where S T. Consequence is invariant subtyping property: Invariant of a class must imply invariant of all parent classes 22c181: Formal Methods in Software Engineering p.15/15

29 Horizontal Verification: Behavioural Subtyping Substitution principle (Liskov, 1993) Let φ be a property provable about objects x of type T. Then φ should be true for objects y of type S where S T. Consequence is invariant subtyping property: Invariant of a class must imply invariant of all parent classes inv S is (FOL translation of) OCL invariant constraint of a class S T 1,...,T n parent classes and interfaces of S Proof obligation: self.(invs -> (inv T1 & &inv Tn )) 22c181: Formal Methods in Software Engineering p.15/15

From OCL to Propositional and First-order Logic: Part I

22c181: Formal Methods in Software Engineering The University of Iowa Spring 2008 From OCL to Propositional and First-order Logic: Part I Copyright 2007-8 Reiner Hähnle and Cesare Tinelli. Notes originally