1. Topics in Object-Oriented Methodology
Takuya Katayama
JAIST

2. 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

3. Agenda Fundamental Concepts in Object-Oriented Methodologies
UML
Topics in OO Methodologies
Constraints and OCL
Proving Constraints

4. Fundamental Concepts in Object-Oriented Methodology

5. 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

6. Object-Oriented Paradigm(1)
Our Word is a collection of collaborating agents
President
Factory
Sales dept.
Factory
workers
Engineers
Scientists

7. Object-Oriented Paradigm(2)
Organize software according to the structure of the world
Management Information
Object
Factory
Management
Object
Sales
Dept.
Object
Worker
Object
Design Object
Laboratory Object

8. 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.

9. Operation: draw, paint, move,.... Behavior e/move, e’
Communication via events,…
Attribute: a,b,c
Operation: draw, paint, move,....
Behavior
e/move, e’

10. 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.

11. Objects and Classes object: Chula Yangon abstraction U. Laos
instantiation
class:
university
Tan
Shinoda
Working-at
class:
professor

12. 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,...

13. 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 …

14. Typical Object-Oriented Development Process
Architecture design
Choice of impl. strategy
Object design
Analyzing
requirement
Object model
Reqmnts
Analysis
Dynamic model
Design
Coding
Coding in OO
language
・・・
Analysis models

15. Multiple Analysis Models
Description of a single model from multiple views which are almost independent
Eight Models + One Language in UML
company
division
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

16. 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

17. 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)

18. 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.

19. Use Case Diagram Use cases : Actor : Customer Insurance Salesperson
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

20. 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

21. if they are well-defined.
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

22. In OO development, use cases are used to find
objects. Functions represented by the use cases
are realized as collaborations among the objects.
<<realizes>>
use case U
collaboration
<<implements>>
　　use case description
1．the actor depresses an
button
2．action 1 is executed
3．a message is sent to
the actor
4. …
　class A　
op1
op２
op３　
　class B　
op1
op２
　class C　
op1
op２
op３　
dicover classes

23. Class Diagrams Classes in the system + Relations
Relations among classes
Inheritance
Aggregation
Association
Dependency
Realization

24. Class and Object Class Employee Objects instantiated from
name:String
name=‘Smith’
name=‘Sharp’
age:Integer
age=24
age=52
Class Employee
Objects instantiated from
the class Employee

25. Association and Multiplicity
Line
name
2..*
0..*
Point
name
Intersect
Line L1
Point P1
Line L2
Point P1 L2
Line L3 P1 P2 L3
Line L4 L1 L5 L4
Line L5

26. Inheritance Attributes and operations are inherited from super classes
Equipment
name
manufacturer
weight
cost
Attributes and operations
are inherited from super
classes
Pump
Heat exchanger
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

27. Aggregation Computer Monitor Mouse Keyboard Fan Chassis CPU RAM 1..*
System box
Mouse
Keyboard
1..*
Fan
0..1
Chassis
CPU
RAM

28. Dependency Utilize class A in class B class A 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

29. Realization R Class B is a realization of A class A class B
B is more concrete
A is more abstract
R: mapping B  A R
class A
class B

30. 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
PopupMenu
setDefault(choice:String)
getChoice():String
choice
1..*
choice
1..*
realization
<<interface>>
Choice
String
specifier
implementation

31. Dynamical Views State Diagram/Statechart Sequence Diagram
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

32. 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

33. 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

34. Generalized State push R Transmission Neutral Reverse push N push N
push F
Forward
stop
upshift
upshift
First
Second
Third
downshift
downshift

35. Aggregation and Concurrent State Diagram
Car
Ignition
Transmission
Brake
Accelerator
Transmission
push R
Accelerator
Neutral
Reverse
push N On
push N
push F
depress
release
Forward 停止
upshift
upshift
Off
First
Second
Third
downshift
downshift
Brake
Ignition
turn key to start
if Transmission in Neutral
Off … …
Off
Starting On
release key On
turn key off

36. Sequence Diagram ・Shows possible sequence(s) of messages among objects
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

37. Collaboration Diagram
Computer
Queue
1:Print(file)
[printer busy]
1.2: Store(file)
PrinterServer
Printer
[printer Free]
1.1: Print(file)

38. 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

39. 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)

40. Deployment Diagram Machines, programs and connections MachineA
　　　：Gateway
MachineB
　　　：Fujitsu
NetC
Client
Program
(client.exe)
Graphics
lib
(graphics.dll)

41. Topics in OO Methodologies
Object Constraint Language OCL
Formal Approach to OO Analysis

42. 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”

43. Benefit of constraints
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

44. “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

45. Customer
name:String
title:String
isMale:Boolean
dateOfBirth:Date
age:Integer
LoyaltyProgram
enroll(c:Customer)
1..*
0..*
0..*
program
1..*
partners
ProgramPartner
numberOfCustomers:Integer
owner
0..*
Membership
{ordered}
1..*
cards
0..*
ServiceLevel
CustomerCard
valid:Boolean
validFrom:Date
goodThru:Date
color:enum{silver,gold}
printedName:String
actual
Level
0..1
delivered
Services
card
0..*
LoyaltyAccount
points:Integer
earn(i:Integer)
burn(i:Integer)
isEmpty():Boolean
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

46. validFrom.isBefore(goodThru)
Customer
name:String
title:String
isMale:Boolean
dateOfBirth:Date
age:Integer
Customer
age>=18
LoyaltyProgram
enroll(c:Customer)
1..*
0..*
0..*
program
1..*
partners
ProgramPartner
numberOfCustomers:Integer
owner
0..*
Membership
{ordered}
1..*
cards
0..*
CustomerCard
validFrom.isBefore(goodThru)
ServiceLevel
CustomerCard
valid:Boolean
validFrom:Date
goodThru:Date
color:enum{silver,gold}
printedName:String
actual
Level
0..1
delivered
Services
card
0..*
LoyaltyAccount
points:Integer
earn(i:Integer)
burn(i:Integer)
isEmpty():Boolean
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

47. printName in CustomerCard is the concatenation of
name:String
title:String
isMale:Boolean
dateOfBirth:Date
age:Integer
LoyaltyProgram
enroll(c:Customer)
1..*
0..*
0..*
program
1..*
partners
ProgramPartner
numberOfCustomers:Integer
owner
0..*
Membership
{ordered}
1..*
cards
0..*
ServiceLevel
CustomerCard
valid:Boolean
validFrom:Date
goodThru:Date
color:enum{silver,gold}
printedName:String
actual
Level
0..1
delivered
Services
card
0..*
LoyaltyAccount
points:Integer
earn(i:Integer)
burn(i:Integer)
isEmpty():Boolean
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

48. Program partner wants to restrict total points
Customer
name:String
title:String
isMale:Boolean
dateOfBirth:Date
age():Integer
LoyaltyProgram
enroll(c:Customer)
1..*
0..*
0..*
program
1..*
partners
ProgramPartner
numberOfCustomers:Integer
owner
0..*
Program partner wants to restrict total points
is less than points.
LoyaltyProgram
partners.deliveredServices.transaction
->select(oclType=Burning)
->collect(points)->sum<10000
Membership
{ordered}
1..*
cards
0..*
ServiceLevel
CustomerCard
valid:Boolean
validFrom:Date
goodThru:Date
color:enum{silver,gold}
printedName:String
actual
Level
0..1
delivered
Services
card
0..*
LoyaltyAccount
points:Integer
earn(i:Integer)
burn(i:Integer)
isEmpty():Boolean
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

49. 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

50. LoyaltyAccount::isEmpty() pre : -- none post : result = (points=0)
Customer
name:String
title:String
isMale:Boolean
dateOfBirth:Date
age():Integer
LoyaltyProgram
enroll(c:Customer)
1..*
0..*
0..*
program
1..*
partners
LoyaltyAccount::isEmpty()
pre : -- none
post : result = (points=0)
ProgramPartner
numberOfCustomers:Integer
owner
0..*
Membership
{ordered}
1..*
cards
0..*
ServiceLevel
CustomerCard
valid:Boolean
validFrom:Date
goodThru:Date
color:enum{silver,gold}
printedName:String
actual
Level
0..1
delivered
Services
card
0..*
LoyaltyAccount
points:Integer
earn(i:Integer)
burn(i:Integer)
isEmpty():Boolean
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

51. A Formal Approach to Object-Oriented Analysis

52. 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.

53. Current OO Methodology
Informal description, probably inconsistent
and inconsistent
(diagrams +natural language)
Usually, requirements are
inconsistent,
incomplete,
imprecise, …
Object model
Req..
Analysis
Dynamic model
Design
Coding
Model unification in design
/coding phase in human brain
・・・
Long and costly feedback

54. 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

55. Formal OO Methodology Req. Analysis Formal analysis models Executable
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

56. Formal OO Methodology (what we have done)
Formal analysis models in ML
Modeling support
Object model
Unification mapping
Req.
Analysis
Dynamic model
Unification
Unified mdel
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

57. 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

58. Dynamic model for Counter (statechart after unification)
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

59. constraint：”Counter.number≧0” number
e-/ Counter.number:=Counter.number-1
e+/ Counter.number:=Counter.number+1
e+/ Counter.number:=Counter.number+1 s2

60. Counter number s1 s2 Prove ”Counter.number≧0” Counter.number≧0

61. Counter number s1 s2 Prove ”Counter.number≧0” Counter.number≧0
(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)

62. Counter number s1 s2 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

63. Axioms Six Axioms: Local invariant axiom Global invariant axiom
Event output axiom
Event communication axiom
Inheritance axiom
Aggregation axiom

64. 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

65. Global Invariant Axiom
oI(c). GA.
1in GA([o][si])  (s.GA([o][s]))

66. 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
: expresses that event e could be received at the state s of object o
: expresses that an event e could be sent at the state s of object o

67. Event Communication Axiom
(o,o’)Link , that is, if there is a link between objects o and o’,
P.  P([o][s](a1), ..., [o][s](an)) 
 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

68. O O’
.../e(a+1)
e(x)/...
P(x)
P(a+1)

69. Inheritance Axiom 1in si.GAi([oi][si])  V1in s.GAi([o][s])
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
GA1VGA2 C1 C2
GA1
GA2

70. F-Developer Environment
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

71. Repository Model Editor Prototyper Verifier Constructed models
Generation of ML
code for prototyping
Generation of axioms
Generated ML codes
Generated axioms
Prototyper
Verifier

72. 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):
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

73. Proof in HOL - ADD_MONO_LESS_EQ; - val r1 =
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 + 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 : 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

74. 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.

75. Lessons Learned Higher Order Property ∀P∀x [P(x) ⇒ x=0]
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

76. 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’,…