Transcript Topics in Object-Oriented Methodology

Topics in Object-Oriented
Methodology
Takuya Katayama
JAIST
1
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
2
Agenda
• Fundamental Concepts in Object-Oriented
Methodologies
– UML
• Topics in OO Methodologies
– Constraints and OCL
– Proving Constraints
3
Fundamental Concepts in
Object-Oriented Methodology
4
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
5
Object-Oriented Paradigm(1)
• Our Word is a collection of collaborating
agents
President
Sales dept.
Factory
Factory
workers
Engineers
Scientists
6
Object-Oriented Paradigm(2)
• Organize software according to the structure
of the world
Factory
Management
Object
Management Information
Object
Sales
Dept.
Object
Worker
Object
Design Object
Laboratory Object
7
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.
8
Communication via events,…
Attribute: a,b,c
Operation: draw, paint, move,....
e/move, e’
Behavior
9
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.
10
Objects and Classes
object:
U. Laos
Chula
Yangon
abstraction
instantiation
Shinoda
Tan
class:
university
Working-at
class:
professor
11
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,...
12
Too Major Issues in ObjectOriented 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
…
13
Typical Object-Oriented
Development Process
Reqmnts
Analyzing
requirement
Object model
Analysis
Dynamic model
・
・
・
Analysis models
Architecture design
Choice of impl. strategy
Object design
Design
Coding
Coding in OO
language
14
Multiple Analysis Models
• Description of a single model from multiple views
which are almost independent
division
company
employee
section
Object Model for classes in the
world and their relationship
main
x
sub1
y
sub3
z
sub2
e1/e2, u=f(v)
s1
s2
Dynamic Model for behavior
description of each object
Functional Model for data flow in the world
• Eight Models + One Language in UML
15
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
16
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)
17
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.
18
Use Case Diagram
Use cases :
specifies functions of
system
Sign an insurance
policy
Actor :
human, machine,…
interacting with the system
Process sales
statistics
Customer
Process customer
statistics
Insurance Salesperson
Insurance System
19
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
20
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
21
In OO development, use cases are used to find
objects. Functions represented by the use cases
are realized as collaborations among the objects.
<<realizes>>
collaboration
use case U
<<implements>>
use case description
class A
class B
class C
1．the actor depresses an
button
2．action 1 is executed
3．a message is sent to
the actor
4. …
op1
op２
op３
op1
op２
op1
op２
op３
dicover classes
22
Class Diagrams
• Classes in the system + Relations
• Relations among classes
–
–
–
–
–
Inheritance
Aggregation
Association
Dependency
Realization
23
Class and Object
Employee
name:String
age:Integer
Class Employee
Employee
name=‘Smith’
age=24
Employee
name=‘Sharp’
age=52
Objects instantiated from
the class Employee
24
Association and Multiplicity
Line
name
Line
L1
Line
L2
2..*
0..*
Intersect
Point
name
Point
P1
Point
P1
Line
L3
L3
Line
L4
Line
L5
L2
L5
L1
P1
P2
L4
25
Equipment
Inheritance
Attributes and operations
are inherited from super
classes
Diaphragm pump
name=P101
manufacture=Simplex
…
suct pressure=1.1 atm
…
diaph material=Teflon
Pump
suction pressure
discharge pressure
flow rate
Diaphragm pump
diaphragm material
name
manufacturer
weight
cost
Heat exchanger
surface area
tube diameter
….
Plunger pump
Tank
volume
pressure
Floating roof tank
diameter
height
26
Aggregation
Computer
1..*
Monitor
System box
Mouse
1..*
Chassis
CPU
RAM
Keyboard
0..1
Fan
27
Dependency
class A
class B
– 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
28
Realization
class A
R
class B
– Class B is a realization of A
• B is more concrete
• A is more abstract
• R: mapping B  A
29
Interface and Realization
• Interface is a special class with abstract operation.
It is used with classes which realize/implement
them.
<<interface>>
ChoiceBlock
setDefault(choice:Choice)
getChoice():Choice
choice 1..*
<<interface>>
Choice
PopupMenu
setDefault(choice:String)
getChoice():String
realization
specifier
choice 1..*
implementation
String
30
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
31
Telephone System
Caller
Event
Phone line
Callee
caller-lifts-receiver
dial-tone-begins
dial(5)
dial(1)
callee-hangs-up
connection-broken
connectin-broken
caller-hangs-up
32
State Diagram for “Phone line”
Idle
caller-hangs-up
caller-lifts-receiver
time-out
Dial tone
Time-out
dial(n)
dial(n)
Dialing
Connected
time-out
callee-hangs-up
Disconnected
33
Generalized State
Transmission
push R
Neutral
push N
push F
push N
Forward
stop
First
Reverse
upshift
downshift
Second
upshift
downshift
Third
34
Aggregation and Concurrent State Diagram
Car
Ignition
Transmission
Neutral
push N
Forward
停止
First
upshift
downshift
Transmission
push R
push N
push F
Second
Brake
Reverse
upshift
downshift
Accelerator
Accelerator
On
release
depress
Off
Third
Brake
Ignition
Off
Off
turn key to start
if Transmission in Neutral
Starting
release key
turn key off
On
…
…
On
35
Sequence Diagram
Print(file)
:Computer
:PrinterServer
Print(file)
:Printer
:Queue
[printer free]
Print(file)
[printer busy]
Store(file)
・Shows possible sequence(s) of messages among objects
・Inter-object behavior
36
Collaboration Diagram
Computer
1:Print(file)
Queue
[printer busy]
1.2: Store(file)
PrinterServer
Printer
[printer Free]
1.1: Print(file)
37
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
38
Component Diagram
• Software components(source, binary and executable)
and their relationship
Window
Handler
(whnd.cpp)
Comm
Handler
(comhnd.cpp)
Main
Class
(main.cpp)
Window
Handler
(whnd.obj)
Comm
Handler
(comhnd.obj)
Main
Class
(main.obj)
Graphics
lib
(graphics.dll)
Client
Program
(client.exe)
39
Deployment Diagram
• Machines, programs and connections
MachineA
：Gateway
Graphics
lib
(graphics.dll)
MachineB
：Fujitsu
NetC
Client
Program
(client.exe)
40
Topics in OO Methodologies
(1) Object Constraint Language OCL
(2) Formal Approach to OO Analysis
41
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”
42
• Constraints in UML
– Constraints on attribute values in class diagram
– Definition of operations in classes by pre/postconditions
• 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
43
“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
44
LoyaltyProgram
0..*
0..*
enroll(c:Customer) program
1..*
1..* partners
ProgramPartner
numberOfCustomers:Integer
0..*
owner
Membership
cards 0..*
{ordered} 1..*
ServiceLevel
delivered
Services 0..*
Service
condition:Boolean
pointsEarned:Integer
pointsBurned:Integer
description:String
0..*
available
Services
Customer
name:String
title:String
isMale:Boolean
dateOfBirth:Date
age:Integer
actual
Level
0..1
LoyaltyAccount
points:Integer
earn(i:Integer)
burn(i:Integer)
isEmpty():Boolean
transactions
CustomerCard
valid:Boolean
validFrom:Date
card goodThru:Date
color:enum{silver,gold}
printedName:String
0..*
Transaction
0..* points:Integer
transactions date:Date
program():LoyaltyProgram
Burning
card
Earning
0..*
transactions
Date
$now:Date
isBefore(t:Date):Boolean
isAfter(t:Date):Boolean
=(t:Bate):Boolean
45
Customer
0..*
age>=18
enroll(c:Customer) program
LoyaltyProgram
1..*
0..*
1..* partners
ProgramPartner
numberOfCustomers:Integer
0..*
owner
Membership
cards 0..*
{ordered} 1..*
ServiceLevel
actual
Level
CustomerCard
0..1
validFrom.isBefore(goodThru)
LoyaltyAccount
delivered
Services 0..*
Service
condition:Boolean
pointsEarned:Integer
pointsBurned:Integer
description:String
0..*
available
Services
Customer
name:String
title:String
isMale:Boolean
dateOfBirth:Date
age:Integer
points:Integer
earn(i:Integer)
burn(i:Integer)
isEmpty():Boolean
transactions
CustomerCard
valid:Boolean
validFrom:Date
card goodThru:Date
color:enum{silver,gold}
printedName:String
0..*
Transaction
0..* points:Integer
transactions date:Date
program():LoyaltyProgram
Burning
card
Earning
0..*
transactions
Date
$now:Date
isBefore(t:Date):Boolean
isAfter(t:Date):Boolean
=(t:Date):Boolean
46
LoyaltyProgram
0..*
0..*
enroll(c:Customer) program
1..*
1..* partners
ProgramPartner
numberOfCustomers:Integer
0..*
owner
Membership
cards 0..*
{ordered} 1..*
ServiceLevel
delivered
Services 0..*
Service
condition:Boolean
pointsEarned:Integer
pointsBurned:Integer
description:String
0..*
available
Services
Customer
name:String
title:String
isMale:Boolean
dateOfBirth:Date
age:Integer
actual
Level
0..1
LoyaltyAccount
points:Integer
earn(i:Integer)
burn(i:Integer)
isEmpty():Boolean
CustomerCard
valid:Boolean
validFrom:Date
card goodThru:Date
color:enum{silver,gold}
printedName:String
card
printName in CustomerCard is the concatenation of
transactions 0..*
name and title of Cutomer
which holds it.
Transaction
0..*
CustomerCard
0..* points:Integer
date:Date
transactions
transactions
printedName=customer.title.concat(customer.name)
program():LoyaltyProgram
Burning
Earning
Date
$now:Date
isBefore(t:Date):Boolean
isAfter(t:Date):Boolean
=(t:Bate):Boolean
47
LoyaltyProgram
0..*
0..*
enroll(c:Customer) program
1..*
1..* partners
ProgramPartner
numberOfCustomers:Integer
0..*
Customer
name:String
title:String
isMale:Boolean
dateOfBirth:Date
age():Integer
owner
Membership
Program partner wants to restrict
total points
cards 0..*
{ordered} 1..*
is less than 10000 points. CustomerCard
ServiceLevel
delivered
Services 0..*
Service
condition:Boolean
pointsEarned:Integer
pointsBurned:Integer
description:String
0..*
availble
Services
actual
Level
valid:Boolean
validFrom:Date
LoyaltyProgram0..1
card goodThru:Date
color:enum{silver,gold}
LoyaltyAccount
partners.deliveredServices.transaction
printedName:String
points:Integer
->select(oclType=Burning)
earn(i:Integer)
card
burn(i:Integer)
->collect(points)->sum<10000
isEmpty():Boolean
transactions
0..*
Transaction
0..* points:Integer
transactions date:Date
program():LoyaltyProgram
Burning
Earning
0..*
transactions
Date
$now:Date
isBefore(t:Date):Boolean
isAfter(t:Date):Boolean
=(t:Bate):Boolean
48
• 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
49
LoyaltyProgram
0..*
0..*
enroll(c:Customer) program
1..*
1..* partners
Customer
name:String
title:String
isMale:Boolean
dateOfBirth:Date
age():Integer
owner
LoyaltyAccount::isEmpty()
0..*
Membership
pre : -- none
cards 0..*
{ordered} 1..*
post
:
result
=
(points=0)
CustomerCard
ServiceLevel
ProgramPartner
numberOfCustomers:Integer
actual
Level
delivered
Services 0..*
Service
condition:Boolean
pointsEarned:Integer
pointsBurned:Integer
description:String
0..*
availble
Services
0..1
LoyaltyAccount
points:Integer
earn(i:Integer)
burn(i:Integer)
isEmpty():Boolean
transactions
valid:Boolean
validFrom:Date
card goodThru:Date
color:enum{silver,gold}
printedName:String
0..*
Transaction
0..* points:Integer
transactions date:Date
program():LoyaltyProgram
Burning
card
Earning
0..*
transactions
Date
$now:Date
isBefore(t:Date):Boolean
isAfter(t:Date):Boolean
=(t:Bate):Boolean
50
A Formal Approach to ObjectOriented Analysis
51
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.
52
Current OO Methodology
Usually, requirements are
inconsistent,
incomplete,
imprecise, …
Req..
Informal description, probably inconsistent
and inconsistent
(diagrams +natural language)
Object model
Analysis
Design
Dynamic model
・
・
・
Coding
Model unification in design
/coding phase in human brain
Long and costly feedback
53
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
54
Formal OO Methodology
Formal analysis models
Object model
Req.
Analysis
Executable
Dynamic model
Model
Unification
Unified mdel
・
・
・
Verification/
prototype
execution
Determination
of software
architecture
Software
generation
Software
Implementation Execution time
memory req、OS
model
communication mech.
55
Formal OO Methodology
(what we have done)
Formal analysis models in ML
Req.
Modeling support
Object model
Analysis
Dynamic model
Verification/
prototype
execution
Determination
of software
architecture
(1)ML-based execution
environment
(2) Consistency Verification
using theorem proving system HOL
Unification mapping
Unification
Software
generation
Unified mdel
Software
Implementation
condition
56
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/act,e2
e1
e1’
e1’/act,e2’
constraint: a1+a2 = b1+b2
57
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
Counter
number
constraint：”Counter.number≧0”
Counter.number:=0
s1
e / Counter.number:=Counter.number-1
-
e+/ Counter.number:=Counter.number+1
e+/ Counter.number:=Counter.number+1
s2
Counter
number
Prove ”Counter.number≧0”
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
Counter
number
Prove ”Counter.number≧0”
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)
Counter
number
Counter.number≧0 ：Global Assertion
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
• Six Axioms:
–
–
–
–
–
–
Local invariant axiom
Global invariant axiom
Event output axiom
Event communication axiom
Inheritance axiom
Aggregation axiom
63
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
64
Global Invariant Axiom
oI(c). GA.

1in
GA([o][si])  (s.GA([o][s]))
65
Event Output Axiom
oI(c). o?e@scondt([o][s]) 

1kl
o!ek@s’
s, s’ : source and destination states of a transition t
e : input event of the transtion t
e1, ... , ek : output event of t
o?e@s : expresses that event e could be received at the state s of object o
o!e@s : expresses that an event e could be sent at the state s of object o
66
Event Communication Axiom
(o,o’)Link , that is, if there is a link between objects o and o’,
P. o!e@s  P([o][s](a1), ..., [o][s](an)) 
o’?e@s’  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
67
O
.../e(a+1)
P(a+1)
O’
e(x)/...
P(x)
68
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])
C
GA1
C1
GA1VGA2
C2
GA2
69
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
70
Constructed models
Repository
Model Editor
Generation of ML Generation of axioms
code for prototyping
Generated ML codes
Prototyper
Generated axioms
Verifier
Generation of Axioms
• Axioms are introduced into HOL as its theory
modules, which are type/term constants, axioms
or definitions．
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
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
72
...
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
73
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.
74
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
75
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’,…
76