topics in object oriented methodology
Download
Skip this Video
Download Presentation
Topics in Object-Oriented Methodology

Loading in 2 Seconds...

play fullscreen
1 / 76

Topics in Object-Oriented Methodology - PowerPoint PPT Presentation


  • 109 Views
  • Uploaded on

Topics in Object-Oriented Methodology. Takuya Katayama JAIST. Hi !. Myself Prof. at Japan Advanced Institute of Science and Technology Working on formal and mathematical aspect of software engineering, especially Object-Oriented Methodology Software evolution Fault-tolerant software

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Topics in Object-Oriented Methodology' - karis


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
slide2
Hi !
  • Myself
    • Prof. at Japan Advanced Institute of Science and Technology
    • Working on formal and mathematical aspect of software engineering, especially
      • Object-Oriented Methodology
      • Software evolution
      • Fault-tolerant software
    • My family

One dog, One wife and two daughters

agenda
Agenda
  • Fundamental Concepts in Object-Oriented Methodologies
    • UML
  • Topics in OO Methodologies
    • Constraints and OCL
    • Proving Constraints
what is object oriented methodology
What is Object-Oriented Methodology ?
  • Software developing methodology based on Object-Oriented Paradigm
    • Our world is a collection of collaborating agents/objects
    • Software has to be organized according to the structure of our world
      • It increases understandability and evolvability of the software
object oriented paradigm 1
Object-Oriented Paradigm(1)
  • Our Word is a collection of collaborating agents

President

Sales dept.

Factory

Factory

workers

Engineers

Scientists

object oriented paradigm 2
Object-Oriented Paradigm(2)
  • Organize software according to the structure of the world

Management Information

Object

Factory

Management

Object

Sales

Dept.

Object

Worker

Object

Laboratory Object

Design Object

computationally objects are
Computationally, Objects are…
  • Elements of the world to be described
    • Autonomous behavioral elements
  • Object=Attributes+Operations+Behavior
    • Attributes:Local data of object
    • Operations:For changing/referencing the attributes
    • Behavior:Upon receiving stimulus(event), perform operations, changes its states and sends out events
      • Usually, modeled as statecharts or event-driven program
  • Object is encapsulated.
slide9
Communication via events,…

Attribute: a,b,c

Operation: draw, paint, move,....

Behavior

e/move, e’

description of the world
Description of the World
  • How do we describe the world?
    • Class concept + Relations among classes
  • Class as a set of “similar objects” in the world
    • Abstraction :{professor Shinoda, professor Tan, …}

 class “professor”

    • Instantiation : “professor”  professor Shinoda
    • Class concepts provides economy and reuse of thought and description.
slide11
Objects and Classes

object:

Chula

Yangon

abstraction

U. Laos

instantiation

class:

university

Tan

Shinoda

Working-at

class:

professor

relationships among classes
Relationships Among Classes
  • Class Hierarchy, Inheritance, “is a”
    • Generalization/Specialization
    • Mammal < Monkey < Human
  • Composition, Aggregation, “has a”
    • Automobile=Body+Wheels+Steering+Engine
  • Association, a general relation between classes

Employ―(works at)―Company

  • Dependency, Realization,...
too major issues in object oriented methodology
Too Major Issues in Object-Oriented Methodology
  • Object-Oriented Analysis/Design
    • BOOCH, OMT, UML, Catalysys methods
    • Constraints, Formal Approach, Analysis Patterns,Unified Process, …
  • Object-Oriented Programming
    • OO langugages :Smalltalk, C++, Java
    • Design Patterns, Frameworks , Class Libraries …
typical object oriented development process
Typical Object-Oriented Development Process

Architecture design

Choice of impl. strategy

Object design

Analyzing

requirement

Object model

Reqmnts

Design

Analysis

Coding

Dynamic model

Coding in OO

language

・・・

Analysis models

multiple analysis models
Multiple Analysis Models
  • Description of a single model from multiple views which are almost independent
  • Eight Models + One Language in UML

division

company

section

Object Model for classes in the world and their relationship

e1/e2, u=f(v)

s2

s1

employee

main

x

sub1

z

Dynamic Model for behavior description of each object

sub3

y

sub2

Functional Model for data flow in the world

slide16
UML
  • Notations to describe every aspects of software development
    • From business systems to industrial embedded systems
    • Becoming a standard notation
  • Unified notations in Booch method, OMT method(Rumbaugh), OOSE method (Jacobson)
  • Becoming a standard language or culture of software engineer
uml eight diagrams and one language
UML- Eight Diagrams and One Language
  • Use Case Diagram
  • Class Diagram/Object Diagram
  • State Diagram
  • Sequence Diagram
  • Collaboration Diagram
  • Activity Diagram
  • Component Diagram
  • Deployment Diagram
  • OCL(Object Constraint Language)
use case diagram
Use Case Diagram
  • Use Cases describe a rough sketch of functions or “usage” of the system looked from the actors outside the system.
  • System functions are described by a set of use cases.
use case diagram1
Use Case Diagram

Use cases :

specifies functions of

system

Actor :

human, machine,…

interacting with the system

Sign an insurance

policy

Process sales

statistics

Process customer

statistics

Customer

Insurance Salesperson

Insurance System

description of use case
Description of Use Case
  • By sentences or activity diagrams
    • Purpose of use case
    • How the use case is initiated
    • Message flow between actors and use case
    • Alternative flow
      • conditional/exceptional flow
      • do not go into too much details
    • Utilizing of other use cases : use case call
    • How the use case is terminated
slide21
Activity chart used

to describe actors

and the use cases

if they are well-defined.

Insert coins

Enough coins

inserted?

Show that drink

can be chosen

Show that drink

is not available

Choose drink

drink not available

Drink customer

drink available

Deliver drink

slide22
In OO development, use cases are used to find

objects. Functions represented by the use cases

are realized as collaborations among the objects.

<>

collaboration

use case U

<>

use case description

1.the actor depresses an

button

2.action 1 is executed

3.a message is sent to

the actor

4. …

class B

op1

op2

class C

op1

op2

op3 

class A

op1

op2

op3 

dicover classes

class diagrams
Class Diagrams
  • Classes in the system + Relations
  • Relations among classes
    • Inheritance
    • Aggregation
    • Association
    • Dependency
    • Realization
class and object
Class and Object

Employee

Employee

Employee

name:String

name=‘Smith’

name=‘Sharp’

age=24

age=52

age:Integer

Class Employee

Objects instantiated from

the class Employee

association and multiplicity
Association and Multiplicity

0..*

2..*

Line

name

Point

name

Intersect

Line

L1

Point

P1

Line

L2

Point

P1

L2

Line

L3

P1

P2

L3

Line

L4

L1

L4

L5

Line

L5

inheritance
Inheritance

Equipment

name

manufacturer

weight

cost

Attributes and operations

are inherited from super

classes

Heat exchanger

Pump

Tank

suction pressure

discharge pressure

flow rate

surface area

tube diameter

….

volume

pressure

Diaphragm pump

name=P101

manufacture=Simplex

suct pressure=1.1 atm

diaph material=Teflon

Diaphragm pump

Plunger pump

Floating roof tank

diameter

height

diaphragm material

aggregation
Aggregation

Computer

1..*

System box

Monitor

Mouse

Keyboard

1..*

0..1

Fan

CPU

RAM

Chassis

dependency
Dependency
  • Utilize class A in class B
    • B has A as a parameter
    • B accesses data in A
    • B uses operations A
    • Change of A affects B

class A

class B

realization
Realization
  • Class B is a realization of A
    • B is more concrete
    • A is more abstract
    • R: mapping B  A

R

class A

class B

interface and realization
Interface and Realization
  • Interface is a special class with abstract operation. It is used with classes which realize/implement them.

<>

ChoiceBlock

setDefault(choice:Choice)

getChoice():Choice

PopupMenu

setDefault(choice:String)

getChoice():String

1..*

choice

1..*

choice

realization

<>

Choice

String

specifier

implementation

dynamical views
Dynamical Views
  • State Diagram/Statechart
    • Specify dynamics of individual object
  • Sequence Diagram
    • Event sequence observed in collaborating objects
  • Collaboration Diagram
    • Different notation of sequence diagram
  • Activity Diagram
    • Action + Control structure
    • Flowchart
telephone system
Telephone System

Event

Caller

Phone line

Callee

caller-lifts-receiver

dial-tone-begins

dial(5)

dial(1)

callee-hangs-up

connection-broken

connectin-broken

caller-hangs-up

state diagram for phone line
State Diagram for “Phone line”

caller-hangs-up

Idle

caller-lifts-receiver

time-out

Time-out

Dial tone

dial(n)

dial(n)

time-out

Dialing

callee-hangs-up

Disconnected

Connected

generalized state
Generalized State

push R

Transmission

Neutral

Reverse

push N

push N

push F

Forward

stop

upshift

upshift

First

Second

Third

downshift

downshift

aggregation and concurrent state diagram
Aggregation and Concurrent State Diagram

Car

Ignition

Transmission

Brake

Accelerator

Accelerator

push R

Transmission

Neutral

Reverse

On

push N

push N

push F

release

depress

Forward

upshift

upshift

停止

Off

First

Second

Third

downshift

downshift

Brake

Off

turn key to start

if Transmission in Neutral

Ignition

Off

Starting

On

release key

On

turn key off

sequence diagram
Sequence Diagram

Print(file)

:Computer

:PrinterServer

:Printer

:Queue

Print(file)

[printer free]

Print(file)

[printer busy]

Store(file)

・Shows possible sequence(s) of messages among objects

・Inter-object behavior

collaboration diagram
Collaboration Diagram

Computer

Queue

1:Print(file)

[printer busy]

1.2: Store(file)

PrinterServer

Printer

[printer Free]

1.1: Print(file)

activity diagram
Activity Diagram
  • Shows relationship among actions
    • Intra-object actions
    • Inter-object actions

CustomerWindow:

PrintAllCustomers

Show MessageBoxe

“Printing” onScreen

Create postscript

file

Remove

MessageBox

Send postscript

file to printer

component diagram
Component Diagram
  • Software components(source, binary and executable) and their relationship

Window

Handler

(whnd.cpp)

Window

Handler

(whnd.obj)

Graphics

lib

(graphics.dll)

Comm

Handler

(comhnd.cpp)

Comm

Handler

(comhnd.obj)

Client

Program

(client.exe)

Main

Class

(main.cpp)

Main

Class

(main.obj)

deployment diagram
Deployment Diagram
  • Machines, programs and connections

MachineA

   :Gateway

MachineB

   :Fujitsu

NetC

Client

Program

(client.exe)

Graphics

lib

(graphics.dll)

topics in oo methodologies
Topics in OO Methodologies
  • Object Constraint Language OCL
  • Formal Approach to OO Analysis
constraints and ocl
Constraints and OCL
  • Constraints
    • Description of systems and services using their properties
    • Usually, constraints are described by the results of the services rather than the procedure to realize them.

What rather than How.

“Any letter posted until 6:00 pm has to be

delivered in the next working day”

slide43
Constraints in UML
    • Constraints on attribute values in class diagram
    • Definition of operations in classes by pre/post-conditions
  • Benefit of constraints
    • Provide means to attach semantic information to UML class diagrams
    • Allow declarative definition of behavior
  • OCL : standard constraint language in UML
    • Based on first order predicate logic
royal loyal company
“Royal Loyal” Company
  • Mileage Handling company
  • LoyaltyProgram
    • Bonus point
    • Air flight mileage
    • Deduction
  • ProgramParner: a company offering its customer a membership in a loyalty program
  • Customer owns CustomerCard
slide45
Customer

name:String

title:String

isMale:Boolean

dateOfBirth:Date

age:Integer

LoyaltyProgram

enroll(c:Customer)

0..*

0..*

1..*

program

partners

1..*

ProgramPartner

numberOfCustomers:Integer

owner

0..*

Membership

0..*

cards

1..*

{ordered}

CustomerCard

valid:Boolean

validFrom:Date

goodThru:Date

color:enum{silver,gold}

printedName:String

ServiceLevel

actual

Level

0..1

delivered

Services

card

LoyaltyAccount

points:Integer

earn(i:Integer)

burn(i:Integer)

isEmpty():Boolean

0..*

Service

condition:Boolean

pointsEarned:Integer

pointsBurned:Integer

description:String

card

0..*

available

Services

transactions

0..*

Transaction

points:Integer

date:Date

program():LoyaltyProgram

0..*

0..*

transactions

transactions

Date

$now:Date

isBefore(t:Date):Boolean

isAfter(t:Date):Boolean

=(t:Bate):Boolean

Burning

Earning

slide46
Customer

name:String

title:String

isMale:Boolean

dateOfBirth:Date

age:Integer

Customer

age>=18

LoyaltyProgram

enroll(c:Customer)

0..*

0..*

1..*

program

partners

1..*

ProgramPartner

numberOfCustomers:Integer

owner

0..*

Membership

0..*

cards

1..*

{ordered}

CustomerCard

validFrom.isBefore(goodThru)

CustomerCard

valid:Boolean

validFrom:Date

goodThru:Date

color:enum{silver,gold}

printedName:String

ServiceLevel

actual

Level

0..1

delivered

Services

card

LoyaltyAccount

points:Integer

earn(i:Integer)

burn(i:Integer)

isEmpty():Boolean

0..*

Service

condition:Boolean

pointsEarned:Integer

pointsBurned:Integer

description:String

card

0..*

available

Services

transactions

0..*

Transaction

points:Integer

date:Date

program():LoyaltyProgram

0..*

0..*

transactions

transactions

Date

$now:Date

isBefore(t:Date):Boolean

isAfter(t:Date):Boolean

=(t:Date):Boolean

Burning

Earning

slide47
Customer

name:String

title:String

isMale:Boolean

dateOfBirth:Date

age:Integer

LoyaltyProgram

enroll(c:Customer)

0..*

0..*

1..*

program

partners

1..*

ProgramPartner

numberOfCustomers:Integer

owner

0..*

Membership

0..*

cards

1..*

{ordered}

CustomerCard

valid:Boolean

validFrom:Date

goodThru:Date

color:enum{silver,gold}

printedName:String

ServiceLevel

actual

Level

0..1

delivered

Services

card

LoyaltyAccount

points:Integer

earn(i:Integer)

burn(i:Integer)

isEmpty():Boolean

0..*

Service

condition:Boolean

pointsEarned:Integer

pointsBurned:Integer

description:String

card

0..*

available

Services

printName in CustomerCard is the concatenation of

name and title of Cutomer which holds it.

CustomerCard

printedName=customer.title.concat(customer.name)

transactions

0..*

Transaction

points:Integer

date:Date

program():LoyaltyProgram

0..*

0..*

transactions

transactions

Date

$now:Date

isBefore(t:Date):Boolean

isAfter(t:Date):Boolean

=(t:Bate):Boolean

Burning

Earning

slide48
Customer

name:String

title:String

isMale:Boolean

dateOfBirth:Date

age():Integer

LoyaltyProgram

enroll(c:Customer)

0..*

0..*

1..*

program

partners

1..*

ProgramPartner

numberOfCustomers:Integer

owner

0..*

Membership

Program partner wants to restrict total points

is less than 10000 points.

LoyaltyProgram

partners.deliveredServices.transaction

->select(oclType=Burning)

->collect(points)->sum<10000

0..*

cards

1..*

{ordered}

CustomerCard

valid:Boolean

validFrom:Date

goodThru:Date

color:enum{silver,gold}

printedName:String

ServiceLevel

actual

Level

0..1

delivered

Services

card

LoyaltyAccount

points:Integer

earn(i:Integer)

burn(i:Integer)

isEmpty():Boolean

0..*

Service

condition:Boolean

pointsEarned:Integer

pointsBurned:Integer

description:String

card

0..*

availble

Services

transactions

0..*

Transaction

points:Integer

date:Date

program():LoyaltyProgram

0..*

0..*

transactions

transactions

Date

$now:Date

isBefore(t:Date):Boolean

isAfter(t:Date):Boolean

=(t:Bate):Boolean

Burning

Earning

slide49
Defining operations by Pre-, Postcondition
    • precondition:specifies condition when the operation could be triggered.
    • postcondition: specifies condition which holds after the operation.

precondition

P

postcondition

slide50
Customer

name:String

title:String

isMale:Boolean

dateOfBirth:Date

age():Integer

LoyaltyProgram

enroll(c:Customer)

0..*

0..*

1..*

program

partners

1..*

LoyaltyAccount::isEmpty()

pre : -- none

post : result = (points=0)

ProgramPartner

numberOfCustomers:Integer

owner

0..*

Membership

0..*

cards

1..*

{ordered}

CustomerCard

valid:Boolean

validFrom:Date

goodThru:Date

color:enum{silver,gold}

printedName:String

ServiceLevel

actual

Level

0..1

delivered

Services

card

LoyaltyAccount

points:Integer

earn(i:Integer)

burn(i:Integer)

isEmpty():Boolean

0..*

Service

condition:Boolean

pointsEarned:Integer

pointsBurned:Integer

description:String

card

0..*

availble

Services

transactions

0..*

Transaction

points:Integer

date:Date

program():LoyaltyProgram

0..*

0..*

transactions

transactions

Date

$now:Date

isBefore(t:Date):Boolean

isAfter(t:Date):Boolean

=(t:Bate):Boolean

Burning

Earning

formal oo methodology
Formal OO Methodology
  • Problems of Current OO Methodologies
    • Formality is very low and effective computer support is difficult, especially in the analysis phase.
    • Quality of the analysis models is not good, which determines the overall quality of final products.
  • So-called formal methods do not consider practices of OO methodologies seriously.
    • Object-orientation of formal methods
  • Formalization of practical OO methodologies is needed.
current oo methodology
Current OO Methodology

Informal description, probably inconsistent

and inconsistent

(diagrams +natural language)

Usually, requirements are

inconsistent,

incomplete,

imprecise, …

Object model

Req..

Design

Analysis

Coding

Dynamic model

Model unification in design

/coding phase in human brain

・・・

Long and costly feedback

formal oo methodology1
Formal OO Methodology
  • Aiming at Formalized OO Methodology
    • Formal analysis models
      • From multiple view points
    • Consistency among analysis models, construction of a unified model
    • Machine assistance in Validation and Verification of analysis models
      • Prototype execution and verification by theorem proving techniques
    • Transformation from the unified models to software architecture
    • Software architecture + implementation model => source codes
formal oo methodology2
Formal OO Methodology

Formal analysis models

Object model

Executable

Req.

Analysis

Dynamic model

Model

Unification

Unified mdel

・・・

Determination

of software

architecture

Verification/

prototype

execution

Software

generation

Software

Execution time

memory req、OS

communication mech.

Implementation

model

formal oo methodology what we have done
Formal OO Methodology(what we have done)

Formal analysis models in ML

Modeling support

Object model

Unification mapping

Req.

Analysis

Dynamic model

Unified mdel

Unification

Determination

of software

architecture

Verification/

prototype

execution

Software

generation

Software

(1)ML-based execution

environment

Implementation

condition

(2) Consistency Verification

using theorem proving system HOL

consistency between object model and dynamic model
Consistency between Object Model and Dynamic Model
  • Verify that constraints among attributes in object models are maintained for any behavior of objects.

Attr. a1,a2,…

Attr. b1,b2,…

Opr. f1,f2,…

Opr. g1,g2,…

e1

e1’

e1/act,e2

e1’/act,e2’

constraint: a1+a2 = b1+b2

slide58
Counter

number

Class Counter

Dynamic model for Counter

(statechart after unification)

Counter.number:=0

s1

e-/ Counter.number:=Counter.number-1

e+/ Counter.number:=Counter.number+1

e+/ Counter.number:=Counter.number+1

s2

slide59
Counter

constraint:”Counter.number≧0”

number

Counter.number:=0

s1

e-/ Counter.number:=Counter.number-1

e+/ Counter.number:=Counter.number+1

e+/ Counter.number:=Counter.number+1

s2

slide60
Counter

Prove ”Counter.number≧0”

number

Counter.number:=0

s1

Counter.number≧0

e-/ Counter.number:=Counter.number-1

e+/ Counter.number:=Counter.number+1

e+/ Counter.number:=Counter.number+1

s2

Counter.number≧1

slide61
Counter

Prove ”Counter.number≧0”

number

Counter.number:=0

s1

Counter.number≧0

e-/ Counter.number:=Counter.number-1

e+/ Counter.number:=Counter.number+1

e+/ Counter.number:=Counter.number+1

s2

Counter.number≧1

(1) Counter.number≧0 at S1 ⇒ Counter.number≧1 at S2

i.e. Counter.number≧0 ⇒ (Counter.number+1)≧1

(2) Counter.number≧1 at S2 ⇒Counter.number≧0 at S1

i.e. Counter.number≧1 ⇒(Counter.number±1≧0)

slide62
Counter

Counter.number≧0 :Global Assertion

number

Local Assertion

Counter.number:=0

s1

Counter.number≧0

e-/ Counter.number:=Counter.number-1

e+/ Counter.number:=Counter.number+1

e+/ Counter.number:=Counter.number+1

s2

Counter.number≧1

(3) Counter.number≧0∧Counter.number⇒Counter.number≧0

axioms
Axioms
  • Six Axioms:
    • Local invariant axiom
    • Global invariant axiom
    • Event output axiom
    • Event communication axiom
    • Inheritance axiom
    • Aggregation axiom
local invariant axiom
Local Invariant Axiom

oI(c). LAs1 ... LAsn.

valid[o](LAs1, ..., LAsn)  1in LAsi([o][si])

where

valid[o](LAs1, ..., LAsn)

LAs1(v)tT LAs(t)([o][s(t)]) condt([o][s(t)])

     LAd(t)(t’[o][d(t)])

v : list of initial values of attributes

condt : transition condition of a transition t∈T

T:the set of transitions of the object o

[o][s] : list of attribute values of o at the state s

s(t), d(t) : source and destination states of the transition t

t’[o][s] :list of attribute values changed by actions of t

global invariant axiom
Global Invariant Axiom

oI(c). GA.

1in GA([o][si])  (s.GA([o][s]))

event output axiom
Event Output Axiom

oI(c). [email protected]condt([o][s])  1kl [email protected]

s, s’ : source and destination states of a transition t

e : input event of the transtion t

e1, ... , ek : output event of t

[email protected] : expresses that event e could be received at the state s of object o

[email protected] : expresses that an event e could be sent at the state s of object o

event communication axiom
Event Communication Axiom

(o,o’)Link , that is, if there is a link between objects o and o’,

P. [email protected]  P([o][s](a1), ..., [o][s](an)) 

o’[email protected]’  P([o’][s’](a1), ..., [o’][s’](an))

P : property about event attributes a1, ..., an event e

[o][s](ak) : values of a1, ..., an at the state s

slide68
O

O’

e(x)/...

.../e(a+1)

P(x)

P(a+1)

inheritance axiom
C

C1

C2

Inheritance Axiom

Let a class c be a super class of c1,…, cn, and o and oi be

instantiated from c and ci.

GA1…GAn

1in si.GAi([oi][si])  V1in s.GAi([o][s])

GA1VGA2

GA1

GA2

f developer environment
F-Developer Environment
  • F-Developer
    • Model Editor for constructing analysis models graphically
    • F-Verifier: for verifying constructed models using HOL
      • HOL: Higher order predicate logic prover developed at Cambridge Univ.
      • Proof-checker rather than automatic prover
    • F-Prototyper: for prototype execution of the models
slide71
Constructed models

Repository

Model Editor

Generation of ML

code for prototyping

Generation of axioms

Generated ML codes

Generated axioms

Prototyper

Verifier

generation of axioms
Generation of Axioms
  • Axioms are introduced into HOL as its theory modules, which are type/term constants, axioms or definitions.

send (Prefix):

'a ObjectID # EventID # 'a StateID -> bool

recieve (Prefix):

'a ObjectID # EventID # 'a StateID -> bool

obj (Prefix): Counter ObjectID

...

Axioms:

AX-LI_Counter|- !o LA_s1 LA_s2.

valid_Counter (o,LA_s1,LA_s2) ==>

LA_s1(Counter_number o s1)/\LA_s2 (Counter_number o s2)

AX-GI_Counter|- ....

....

Definitions:

Counter_inc_DEF|- !n.inc n = n+1

Counter_LA_s1_DEF|- !x. Counter_LA_s1 x = 0<=x

Counter_LA_s2_DEF|- !x. Counter_LA_s2 x = 1<=x

Counter_GA_DEF |- !x. Counter_GA x = 0<=x

...

Type constants:

Counter 0

EventID 0

StateID 1

ObjectID 1

Term constants:

s1 (Prefix) :Counter StateID

s2 (Prefix) :Counter StateID

Counter_number (Prefix):

Counter ObjectID -> Counter StateID -> num

inc(Prefix) :num -> num

Counter_LA_s1 (Prefix) :num -> bool

Counter_LA_s2 (Prefix) :num -> bool

Counter_GA (Prefix) :num -> bool

valid_Counter (Prefix):

e_plus (Prefix) :EventID

e_minus (Prefix) :EventID

link (Prefix): 'a ObjectID # 'b ObjectID -> bool

proof in hol
Proof in HOL
  • - ADD_MONO_LESS_EQ;
  • val it = |- !m n p. m + n <= m + p = n <= p : thm
  • - ADD_0;
  • val it = |- !m. m + 0 = m : thm
  • - SPEC (--`Counter_number obj s1`--)
  • (SPEC (--`0`--)
  • (SPEC (--`1`--) ADD_MONO_LESS_EQ));
  • val it = |- 1 + 0 <= 1 + Counter_number obj s1 =
  • 0 <= Counter_number obj s1: thm
  • - val lemma1 = snd (EQ_IMP_RULE it);
  • val lemma1 =
  • |- 0 <= Counter_number obj s1 ==>
  • 1 + 0 <= 1 + Counter_number obj s1 : thm
  • SPEC (--`1`--) ADD_0;
  • val it = |- 1 + 0 = 1 : thm
  • - val lemma2 = REWRITE_RULE [it] lemma1;
  • val lemma2 = |- 0 <= Counter_number obj s1 ==>
  • 1 <= 1 + Counter_number obj s1

- val r1 =

SYM (SPEC (--`Counter_number obj s1`--)

Counter_LA_s1_DEF);

val r1 =

|- 0 <= Counter_number obj s1 =

Counter_LA_s1 (Counter_number obj s1): thm

- val r2 =

SYM (SPEC (--`1 + Counter_number obj s1`--)

Counter_LA_s2_DEF);

val r2 =

|- 1 <= 1 + Counter_number obj s1 =

Counter_LA_s2 (1 + Counter_number obj s1): thm

- val step1 = REWRITE_RULE [r1, r2] lemma2;

val step1 =

|- Counter_LA_s1 (Counter_number obj s1) ==>

Counter_LA_s2 (1 + Counter_number obj s1) : thm

slide74
Lessons Learned
  • Found that formal verification is useful in developing correct analysis models
    • Even for the small example we tried, errors were found by the proving assertions.
    • In the analysis phase, errors could come in from incomplete and inconsistent requirement.
    • HOL style interactive proof making process could be considered as a process of gradually understanding / constructing analysis models.
lessons learned
Lessons Learned
  • Higher Order Property
    • If you can quantify predicates in your expression, your logic is higher order logic.

∀P∀x [P(x) ⇒ x=0]

  • Higher order logic is hard to handle in automatic proving, but it is very useful in describing analysis model.
    • It could be used to express general knowledge of the domain.
    • Reuse/economy of description
lessons learned1
Lessons Learned
  • Proof requires long steps, as we need to prove
    • Facts about primitive data such as integer, list, …
    • Also, inference rules are primitive.
  • To make it acceptable to “software engineer”, we need
    • Abstract domain libraries
      • Theorems about ‘Banking System’, ‘Hotel’,…
    • Reuse of proof steps
    • Domain specific proof tactics
      • Proof tactics for ‘Banking System’,…
ad