Analyzing UML/OCL Models with HOL-OCL

(1)

Analyzing UML/OCL Models with HOL-OCL

Achim D. Brucker¹ Burkhart Wolff²

1SAP Research, Vincenz-Priessnitz-Str. 1, 76131 Karlsruhe, Germany [email protected]

2PCRI/co INRIA-Futurs, Parc Club Orsay Université, 91893 Orsay Cedex, France [email protected]

A Tutorial at MoDELS 2008 Toulouse, 28th September 2008

(2)

Outline

1 Introduction

2 Background

3 Formalization of UML and OCL

4 Mechanized Support for Model Analysis Methods

5 The HOL-OCL Architecture

6 Applications

7 Conclusion and Future Work

(3)

Outline

1 Introduction

2 Background

6 Applications

(4)

Introduction Motivation

The Situation Today

A Software Engineering Problem

Software systems

are becoming more and more complex and

are used in safety and security critical applications.

Formal methods are one way to increase their reliability.

But, formal methods are hardly used by mainstream industry:

difficult to understand notation lack of tool support

high costs

Semi-formal methods, especially UML, are widely used in industry, but

they lack support for formal methodologies.

(5)

Introduction Motivation

Is OCL an Answer?

UML/OCL attracts the practitioners:

is defined by the object-oriented community, has a “programming language face,”

increasing tool support.

UML/OCL is attractive to researchers:

defines a “core language” for object-oriented modeling, provides good target for object-oriented semantics research, offers the chance for bringing formal methods closer to industry.

Turning OCL into a full-fledged formal methods is deserving and interesting.

(6)

Introduction The HOL-OCL Vision

The HOL-OCL Vision:

Tool Supported Formal Methods for (Model-driven) Software Development

1..∗Role

Class + Public Method

# Protected Method attribute: Type

− Private Method Class + Public Method

− Private Method Class

+ Public Method

− Private Method

UML/OCL (XMI) or SecureUML/OCL

Code Generator Repository

Model (su4sml)

Model−Analysis and Verification (HOL−OCL) Transformation

Model

HOL−TestGen ArgoUML

AC Config

C#

+OCL Test

Harness

manual Code Proof

Obligations

Test Data

Program

Generation

Validation

(7)

The HOL-OCL Vision:

1..∗Role

+ Public Method

− Private Method

Model Transformation Design

Phase Phase

Verification and

Code−generation Phase Deployment Phase Testing and UML/OCL

(XMI) or SecureUML/OCL

Model (su4sml)

Model

AC Config

C#

+OCL Test

Harness

manual Code Proof

Obligations

Test Data

Program

Generation

Validation Generic

SecureUML ArgoUML−plugin

(8)

The HOL-OCL Vision:

1..∗Role

+ Public Method

− Private Method

Model (su4sml)

Model

AC Config

C#

+OCL Test

Harness

manual Code Proof

Obligations

Test Data

Program

Generation

Validation Code Generator SecureUML, UML, OCL Java, C#, Junit, XACL, USE, ...

(9)

The HOL-OCL Vision:

1..∗Role

+ Public Method

− Private Method

Phase Phase

Verification and

Model (su4sml)

Model

AC Config

C#

+OCL Test

Harness

manual Code Proof

Obligations

Test Data

Program

Generation

Validation Methodologies:

Well−formedness checking Proof−obligation generation

(10)

The HOL-OCL Vision:

1..∗Role

+ Public Method

− Private Method

Model (su4sml)

Model

AC Config

C#

+OCL Test

Harness

manual Code Proof

Obligations

Test Data

Program

Generation

Validation Transformations:

SecureUML −> UML/OCL UML/OCL −> UML/OCL

(11)

The HOL-OCL Vision:

1..∗Role

+ Public Method

− Private Method

Phase Phase

Verification and

Model (su4sml)

Model

AC Config

C#

+OCL Test

Harness

manual Code Proof

Obligations

Test Data

Program

Generation

Validation HOL−OCL

formal analysis formal verification

(12)

The HOL-OCL Vision:

1..∗Role

+ Public Method

− Private Method

Model (su4sml)

Model

AC Config

C#

+OCL Test

Harness

manual Code Proof

Obligations

Test Data

Program

Generation

Validation HOL−TestGen

model−based unit test sequence testing

(13)

The HOL-OCL Vision:

1..∗Role

+ Public Method

− Private Method

Phase Phase

Verification and

Model (su4sml)

Model

AC Config

C#

+OCL Test

Harness

manual Code Proof

Obligations

Test Data

Program

Generation

Validation

(14)

Background

Outline

1 Introduction

2 Background

6 Applications

(15)

Background UML/OCL in a Nutshell

The Unified Modeling Language (UML)

Visual modeling language Object-oriented

development

Industrial tool support OMG standard

Many diagram types, e. g., activity diagrams class diagrams . . .

Eat something

Read a book Listen to music still hungry

had enough

Account balance:Integer id:Integer getId():Integer getBalance():Integer deposit(a:Integer):Boolean withdraw(a:Integer):Boolean

Customer id:Integer name:String getId():Integer setName(n:String):Boolean getName():String accounts

1..*

owner 1

Customer id:Integer name:String getId():Integer setName(n:String):Boolean getName():String

(16)

The Unified Modeling Language (UML)

Visual modeling language Object-oriented

development

Industrial tool support OMG standard

Many diagram types, e. g., activity diagrams class diagrams . . .

Eat something

Read a book Listen to music still hungry

had enough

Customer id:Integer name:String getId():Integer accounts

1..*

owner 1 Account

balance:Integer id:Integer getId():Integer getBalance():Integer deposit(a:Integer):Boolean withdraw(a:Integer):Boolean

Customer id:Integer name:String getId():Integer

(17)

The Object Constraint Language (OCL)

Textual extension of the UML Allows for annotating UML diagrams In the context of class–diagrams:

invariants preconditions postconditions

Can be used for other diagrams

accounts 1..*

contextAccount inv: 0 <= id

contextAccount::deposit(a:Integer):Boolean pre: 0 < a

post: balance = balance@pre+a and id = id@pre contextAccount

inv: 0 <= id

post: balance = balance@pre+a and id = id@pre

(18)

The Object Constraint Language (OCL)

invariants preconditions postconditions

accounts 1..*

inv: 0 <= id

(19)

The Object Constraint Language (OCL)

invariants preconditions postconditions

accounts 1..*

inv: 0 <= id

(20)

OCL by Example

Class invariants:

context Account inv: 0 <= id Operation specifications:

context Account::deposit(a:Integer):Boolean pre: 0 < a

post: balance = balance@pre + a

A “uniqueness” constraint for the classAccount:

context Account inv:

Account::allInstances()

->forAll(a1,a2 | a1.id = a2.id implies a1 = a2)

OCL context OCL keywords UML path expressions

(21)

Formalization of UML and OCL

Outline

1 Introduction

2 Background

6 Applications

(22)

Formalization of UML and OCL

Developing Formals Tools for UML/OCL?

Turning UML/OCL into a formal method

1 A formal semantics ofUML class models typed path expressions

inheritance dynamic binding . . .

2 A formal semantics ofOCLand proof support for OCL reasoning over UML path expressions

large libraries three-valued logic . . .

(23)

Formalization of UML and OCL Formalization of OCL

Outline

1 Introduction

2 Background

3 Formalization of UML and OCL Formalization of OCL Formalization of UML The OCL Standard

6 Applications

(24)

How to Formalize OCL ?

The semantic foundation of the OCL standard:

Chapter 11 “The OCL Standard Library” (normative):

describes the requirements (pre-/post-style) Appendix A “Semantics” (informative):

presents a formal semantics (paper and pencil)

(25)

The OCL Semantics: An Example

The Interpretation of “X->union(Y)” for sets (“X∪Y”):

I(∪)(X,Y)≡

(X∪Y ifX6=⊥andY6=⊥,

⊥ otherwise This is a

lifted(sets can be undefined, denoted by⊥) and

strict(the union of undefined with anything is undefined) version of the union of “mathematical sets.”

(26)

A Machine-checked Semantics

Our formalization of “X->union(Y)” for sets (“X∪Y”):

_->union_≡

strictify λX. strictify(λY.xp^Xq∪pYqy) . We model concepts likestrictandliftedexplicit, i. e., we introduce:

a datatype for lifting:

α⊥:=xαy| ⊥ a combinator for strictification:

strictifyf x≡ifx=⊥then⊥elsef x

(27)

Is This Semantics Compliant?

We prove formally (within our embedding):

SemJ^not ^XKγ= (

x¬pSemJ^XKγqy ^{if Sem}J^XKγ6=⊥,

⊥ otherwise.

lemma"`

SemJ^not^xKγ´

=`

if SemJ^xKγ6=⊥thenx¬pSemJ^xKγqy^else⊥´

"

apply(simp add: OclNot_def DEF_def lift0_def lift1_def lift2_def semfun_def )

done

(28)

Proving Requirements

isEmpty() : Boolean (11.7.1-g)

Is self the empty collection?

post: result = ( self->size() = 0 )

Bag

lemma(self->isEmpty()) = ((self,β ::bot)Bag)->size().

=0 apply(rule Bag_sem_cases_ext, simp_all)

apply(simp_all add: OCL_Bag.OclSize_def OclMtBag_def OclStrictEq_def

Zero_ocl_int_def ss_lifting’) done

(29)

Formalization of UML and OCL Formalization of UML

Outline

1 Introduction

2 Background

3 Formalization of UML and OCL Formalization of OCL Formalization of UML The OCL Standard

6 Applications

(30)

A Semantics of Typed Path Expressions

Question: What is the semantics ofself.s?

Access the value of the attributesof the objectself.

Formalizingtype safepath expressions requires a HOL representation of class types

HOL functions for accessing attributes support for inheritance and subtyping Afteradding new classesto a model

there is no need for re-proving definitions can be re-used

Goal: a type-safe object store, supporting modular proofs

(31)

Representing Class Types

The “extensible records” approach We assume a common superclass (O).

The uniqueness is guaranteed by atag type, e. g.:

Otag:=classO

Construct class type as tuple along inheritance hierarchy

O

A s:String

B b:Integer

α

α B:= (Otag×oid)×

(Atag×String)

× (Btag×Integer)

×α_⊥

⊥

where __⊥denotes types supporting undefined values.

(32)

Representing Class Types

Otag:=classO

O

A s:String

B b:Integer

α

B:=

(Otag×oid)×

(Atag×String)

× (Btag×Integer)

×α_⊥

⊥

(33)

Representing Class Types

Otag:=classO

O

A s:String

B b:Integer

α

B:= (Otag×oid)

×

(Atag×String)

× (Btag×Integer)

×α_⊥

⊥

(34)

Representing Class Types

Otag:=classO

O

A s:String

B b:Integer

α

B:= (Otag×oid)×

(Atag×String)

× (Btag×Integer)

×α_⊥

⊥

(35)

Representing Class Types

Otag:=classO

O

A s:String

B b:Integer

α

B:= (Otag×oid)×

(Atag×String)× (Btag×Integer)

×α_⊥

⊥

(36)

Representing Class Types

Otag:=classO

O

A s:String

B b:Integer

α

α B:= (Otag×oid)×

(Atag×String)× (Btag×Integer)×α_⊥

⊥

(37)

Representing Class Types: Summary

Advantages:

it allows for extending class types (inheritance), subclasses are type instances of superclasses

⇒ it allows for modular proofs, i. e.,

a statementφ(x: : (αB))proven for classBis still valid after extending classB.

However, it has a major disadvantage:

modular proofs are only supported foroneextension per class

O

A s:String

B b:Integer

(38)

A Universe Type

Auniversetype represents all classes supports modular proofs with arbitrary extensions

provides a formalization of a extensible typed object store

(39)

An Extensible Object Store

O O

α^O

U^_(αO)=O×α⊥^O

A A β^O

α^A

U^_(αO)=O×α^O⊥

U^_(αA,βÔ)=O× (A×αÂ⊥+βÔ)⊥

B B β^A

α^B

U^_(αA,βÔ)=O× (A×αÂ⊥+βÔ)⊥

U^₍_αB,βÔ,βÂ)=O× (A× (B×α^B⊥+βÂ)⊥+βÔ)⊥

C C β^A

α^C

U^_(αA,βÔ)=O× (A×αÂ⊥+βÔ)⊥

U^₍_αB,α^C,βÔ,βÂ)=O× (A× (B×α^B⊥+ (C×α^C⊥+βÂ))⊥+βÔ)⊥

U_(α³^B_,α^C_,βO,βÂ)≺U_(α²^B_,βO,βÂ)≺U_(α¹Â_,βO)≺U_(α⁰O)

(40)

An Extensible Object Store

O O

α^O

A

A β^O

α^A

U^_(αA,βÔ)=O× (A×αÂ⊥+βÔ)⊥

B B β^A

α^B

U^_(αA,βÔ)=O× (A×αÂ⊥+βÔ)⊥

C C β^A

α^C

U^_(αA,βÔ)=O× (A×αÂ⊥+βÔ)⊥

(41)

An Extensible Object Store

O O

α^O

A A β^O

α^A

U^_(αA,βÔ)=O× (A×αÂ⊥+βÔ)⊥

B B β^A

α^B

U^_(αA,βÔ)=O× (A×αÂ⊥+βÔ)⊥

C C β^A

α^C

U^_(αA,βÔ)=O× (A×αÂ⊥+βÔ)⊥

(42)

An Extensible Object Store

O O

α^O

A A β^O

α^A

U^_(αA,βÔ)=O× (A×αÂ⊥+βÔ)⊥

B B β^A

α^B

U^_(αA,βÔ)=O× (A×αÂ⊥+βÔ)⊥

C C β^A

α^C

U^_(αA,βÔ)=O× (A×αÂ⊥+βÔ)⊥

(43)

An Extensible Object Store

O O

α^O

A A β^O

α^A

U^_(αA,βÔ)=O× (A×αÂ⊥+βÔ)⊥

B B β^A

α^B

U^_(αA,βÔ)=O× (A×αÂ⊥+βÔ)⊥

C C β^A

α^C

U^_(αA,βÔ)=O× (A×αÂ⊥+βÔ)⊥

(44)

An Extensible Object Store

O O

α^O

A A β^O

α^A

U^_(αA,βÔ)=O× (A×αÂ⊥+βÔ)⊥

B B β^A

α^B

U^_(αA,βÔ)=O× (A×αÂ⊥+βÔ)⊥

C C β^A

α^C

U^_(αA,βÔ)=O× (A×αÂ⊥+βÔ)⊥

(45)

An Extensible Object Store

O O

α^O

A A β^O

α^A

U^_(αA,βÔ)=O× (A×αÂ⊥+βÔ)⊥

B B β^A

α^B

U^_(αA,βÔ)=O× (A×αÂ⊥+βÔ)⊥

C C β^A

α^C

U^_(αA,βÔ)=O× (A×αÂ⊥+βÔ)⊥

(46)

Operations Accessing the Object Store

injections

mkOo=Inlo with typeα^O O→Uα⁰^O

projections

get_Ou=u with typeUα⁰^O →α^OO type casts

A[O]=getO◦mkA with typeαÂA→(A×αÂ_⊥+βÔ)O O[A]=getA◦mkO with type(A×αÂ_⊥+βÔ)O→αÂA . . .

All definitions are generated automatically

(47)

Does This Really Model Object-orientation?

For each UML model, we have to show several properties:

O

A s:String

B b:Integer

subclasses are of the superclasses kind:

isTypeBself isKindAself

“re-casting”:

isTypeBself

self_[A][B]6=⊥ ∧isTypeB(self_[A][B][A]) monotonicity of invariants, . . .

All rules are derived automatically

(48)

Formalization of UML and OCL The OCL Standard

First Results of Formalizing the OCL Standard

We found several glitches:

inconsistencies between the formal semantics and the requirements missing pre- and postconditions

wrong (e.g., to weak) pre- and postconditions . . .

and examined possible extensions (open problems):

operations calls and invocations smashing of datatypes

equalities recursion

semantics for invariants (type sets) . . .

(49)

Mechanized Support for Model Analysis Methods

Outline

1 Introduction

2 Background

6 Applications

(50)

Mechanized Support for Model Analysis Methods

Motivation

Observation:

UML/OCL is agenericmodeling language:

usually, only a sub-set of UML is used and

per se there is no standard UML-based development process.

Successful use of UML usually comprises a well-defined development process and

tools that integrate into the development process.

Conclusion:

Formal methods for UML-based development should support the local UML development methodologies and integrate smoothly into the local toolchain.

A toolchain for formal methods should provide tool-support formethodologies.

(51)

Mechanized Support for Model Analysis Methods Well-formedness Checking: Enforcing Syntactical Requirements

Well-formedness of Models

Well-formedness Checking

Enforcesyntacticalrestriction on (valid) UML/OCL models.

Ensure a minimal quality of models.

Can be easily supported by fully-automatic tools.

Example

There should be at maximum five inheritance levels.

The Specification of public operations may only refer to public class members.

. . .

(52)

Mechanized Support for Model Analysis Methods Proof Obligations: Enforcing Syntactical Requirements

Proof Obligations for Models

Proof Obligation Generation

Enforcesemanticalrestriction on (valid) UML/OCL models.

Build the basis for formal development methodologies.

Require formal tools (theorem prover, model checker, etc).

Example

Liskov’s substitution principle.

Model consistency Refinement.

. . .

(53)

Proof Obligations: Liskov’s Substitution Principle

Liskov substitution principle

Letq(x)be a property provable about objects x of typeT. Thenq(y)should be true for objectsyof typeSwhereSis a subtype ofT.

For constraint languages, like OCL, this boils down to:

pre-conditionsof overridden methods must beweaker.

post-conditionsof overridden methods must bestronger.

Which can formally expressed as implication:

Weakening the pre-condition:

op_pre→op^sub_pre Weakening the pre-condition:

op^sub_post →op_post

(54)

Proof Obligations: Liskov’s Substitution Principle

Example

Rectangle width:Integer height:Integer

setHeight(h:Integer):OclVoid setWidth(w:Integer):OclVoid contextRectangle::setWidth(w:Integer):OclVoid

pre: w >= 0

post: self.width = w

contextSquare::setWidth(w:Integer):OclVoid pre: w >= 0

post: self.width = w and self.height=w

Square

setHeight(h:Integer):OclVoid setWidth(w:Integer):OclVoid

Weakening the pre-condition:

(w >= 0)→(w >= 0) Strengthening the post-condition:

(55)

Well-formedness and Proof Obligations

Repository Model (su4sml) UML

OCL

Verification (e.g., HOL−OCL)

Validation (e.g., USE, OCLE)

Syntactic Checks (e.g., su4sml)

Well−formedness Proof Obligation

(56)

Mechanized Support for Model Analysis Methods Formal Methodologies for UML/OCL

Methodology

A tool-supported methodology should

integrate into existing toolchains and processes, provide a unified approach, integrating ,

syntactic requirements (well-formedness checks), generation of proof obligations,

means forverification(proving) orvalidation, and of course all phases should be supported by tools.

Example

A package-based object-oriented refinement methodology.

(57)

Refinement – Motivation

Support top-down development from an abstract model to a more concrete one.

We start with an abstract transition system sys_abs= (σ_abs,initabs,op_abs) We refine each abstract operationop_abs

to a more concrete one:op_conc.

Resulting in a more concrete transition system sys_conc= (σ_conc,initconc,op_conc) Such refinements can be chained:

sys₁ sys₂ · · · sys_n

E.g., from an abstract model to one that supports code generation.

(58)

Refinement: Well-formedness

If packageBrefines a packageA, then

one should be able to substitute every usage of packageAwith packageB.

1 The concrete package must provide at a corresponding public class for each public class of the abstract model.

2 For public attributes we require that their type and for public operations we require that the return type and their argument types are either basic datatypes or public classes.

3 For each public class of the abstract package, we require that the corresponding concrete class provides at least

1 public attributes with the same name and

2 public operations with the same name.

4 The types of corresponding abstract and concrete attributes and