Fundamental Concepts in ObjectOriented Methodology

1
Fundamental Concepts 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 wife, two daughters and one dog

3
Agenda

• Fundamental Concepts in Object-Oriented
  Methodologies
• Objects, Classes, Structures among Classes
• Behavior of Objects, State, State charts
• UML
• Some Topics in OO Methodologies
• Constraints and OCL
• Proving Constraints

4
What is Object-Oriented Methodology ?

• Software development method based on
  Object-Oriented Paradigm
• Our world is a collection of collaborating
  entities called objects
• Software has to be organized according to the
  structure of our world
• It increases understandability.
• It makes evolution of software easier.

5
Object-Oriented Paradigm

• Our Word is a collection of collaborating entities

President
Sales dept.
Factory
Factory workers
Engineers
Scientists
6
Object-Oriented Paradigm

• Organize software according to the structure of
  the world

Management Information Object
Factory Management Object
Sales Dept. Object
Worker Object
Laboratory Object
Design Object
7
Requirement analysis, Specification, Design
Problem P?P'
Platform M?M'
Real World W?W'
Design D?D'
Programming, Test
Program S?S
8
Software Evolution

• The most difficult and costly part in software
  lifecycle
• Missing design information
• Legacy code problem
• Difficulty of understanding and comprehending the
  entire system from the beginning of its
  development.
• Complex systems can only be build only through
  evolution.
• Evolutionary prototyping
• New applications require evolution
• Open system
• Need to adapt to unknown environments

9
Computationally, Objects are

• Elements of the world to be described
• Autonomous behavioral elements
• ObjectAttributesOperationsBehavior
• AttributesLocal data of object
• OperationsFor changing/referencing the
  attributes
• BehaviorUpon receiving stimulus(event), the
  object (1) perform operations, (2) changes its
  states and (3) sends out events to other objects.
  
• Usually, modeled as statecharts or event-driven
  program
• Object is encapsulated.
• No internal state and attribute values can be
  seen from outside the object.

10
Communication via events
Attribute position,color,... Operation draw,
paint, move,.... Behavior
e/move, e
11
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.

12
Objects and Classes
Thai
object
Myanmar
abstraction
Laos
Indonesia
instantiation
class Country
Tan
Shinoda
lives-in
class People
13
Relationships Among Classes

• Class Hierarchy, Inheritance, is a
• Generalization/Specialization
• Mammal lt Monkey lt Human
• Composition, Aggregation, has a
• AutomobileBodyWheelsSteeringEngine
• Association, a general relation between classes
• People?(lives-in)?Country
• Dependency, Realization,...

14
Two Major Issues in Object-Oriented Methodology

• Object-Oriented Analysis/Design
• BOOCH, OMT, UML, Catalysis methods
• Constraints, Formal Approach, Analysis
  Patterns,Unified Process,
• Object-Oriented Programming
• OO languages Smalltalk, C, Java
• Design Patterns, Frameworks , Class Libraries

15
Typical Object-Oriented Development Process
Architecture design Choice of impl.
strategy Object design
Analyzing requirement
Object model
Reqrmnts
Analysis
Design
Dynamic model
Coding
Coding in OO language

Analysis models
16
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, uf(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
17
UML

• Notations to describe every aspects of software
  development
• From business systems to industrial embedded
  systems
• Unified notations in Booch method, OMT
  method(Rumbaugh), OOSE method (Jacobson)
• Becoming a standard language of software engineer

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

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

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

22
Use cases are described by activity diagrams 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
23
In OO development, use cases are used to find
objects. Functions represented by the use
cases are realized as collaborations among the
objects.
ltltrealizesgtgt
collaboration
use case U
ltltimplementsgtgt
use case description 1.the actor depresses an
button 2.action 1 is executed 3.a message is
sent to the actor 4.
class Drink op1 op2
class Disp op1 op2 op3
class Button op1 op2 op3
discover classes
24
Class Diagrams

• Classes in the system Relations
• Relations among classes
• Inheritance
• Aggregation
• Association
• Dependency
• Realization

25
Class and Object
Employee
Employee
Employee
nameString
nameSmith
nameSharp
posString
poseng
poschief eng
promote
promote
promote
Objects instantiated from the class Employee
Class Employee
26
Link and Association

• Link Relation among objects instantiated from
  classes
• Channel for event transmission
• Access path for data access/navigation

Person
Company
workat
Joe Smith
Simplex Co.
27

• Association Relation between classes
• Abstraction of links between objects

Person
Company
workat
Joe Smith?Person
Simplex Co.?Company
28
Link and Classes
R
If O1?O2 for some O1?C1,O2?C2 then
C1?C2 R?C1C2 C represents objects
instantiated from the class C
R
29
Direct Products of Sets and Relations

• Direct Product
• C1C2(O1,O2)O1?C1,O2?C2
• Relation R between C1 and C2 R? C1C2
• Parent relation P?HumanHuman
• P(x,y) y is a parent of x, x,y are in
  Human
• Devisor relation D?NN, Nthe set of natural
  numbers
• D(m,n) nkm for some k in N
• When (O1,O2)?R, we write O1?O2

R
30
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
31
Inheritance
Equipment
name manufacturer weight cost
Attributes and operations are inherited from
super classes
Pump
Tank
Heat exchanger
suction pressure discharge pressure flow rate
volume pressure
surface area tube diameter .
Diaphragm pump nameP101 manufactureSimplex suc
t pressure1.1 atm diaph materialTeflon
Diaphragm pump
Floating roof tank
Plunger pump
diameter height
diaphragm material
32
Inheritance

• A method for classifying classes according to
  their generality
• Inheritance is not an association

B inherits attributes and operations from A
Attr(B)Attr(A)?Attr(B) Op(B)Op(A)?Op(B) wh
ere, Attr(C)attributes effective at C
Attr(C)attributes defined in C Op, Op
similarly
super class
subclass
33
Aggregation
Computer
1..
System box
Monitor
Mouse
Keyboard
1..
0..1
Fan
CPU
RAM
Chassis
34

• Aggregation is a special case of association
• Object of the class A is together with objects of
  the Class B and C as OA(OB,OC).
• State space of the object in the class A
• V(Attr(A))V(Attr(B))V(Attr(C))
• Attr(X) attributes effective at class X
• V(a,b,...,c)V(a)V(b)V(c)
• V(a) set of values which the attribute a can
  take.

35

• 2. Operations of the object OA of the class A is
  delegated to its parts OB,OC

OA
Attr A
OC
Attr C
Reacting to events from outside, OA send events
to OB and OC asking to perform the associated
tasks. Their results are sent back to OA.
36
An Example of Delegation
copy
copy
having



37
Aggregation and Inheritance

• Aggregation is inherited.

A
D
B
C

E
Object of D has parts which are objects of B,C
and E. OD(OB,OC,OE1,OE2,...)
38
Fluores- ent Lamp
Incandes- cent Lamp
39
Recursive Aggregation
programblock blocksimple statement
compound statement compound
statementblock AeAAAAAA


compound sentence
simple statement
40
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
41
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
42
Interface and Realization

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

ltltinterfacegtgt ChoiceBlock setDefault(choiceChoice
) getChoice()Choice
PopupMenu setDefault(choiceString) getChoice()St
ring
1..
choice
1..
choice
realization
ltltinterfacegtgt Choice
String
specifier
implementation
43
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

44
State Diagram

• Description of individual objects
• Fundamental concepts
• event, state, scenario, event trace, state
  transition, state transition diagram, operation,
  action
• Advanced concepts
• nested transition diagram, generalized state,
  concurrency, event dispatching, synchronization
  of concurrency

45
Event and Event Trace

• Event
• Stimulus which an object transmit to other
  objects
• Object reacts to events and perform associated
  tasks
• Event has no duration time.
• Event may have attributes, which represents its
  contents

46

• Event Trace
• Sequence of events
• Scenario
• Sequence of events observe when the system
  performs some function
• Event Trace Diagram/Sequence Diagam

47
An Event Sequence in a Telephone System
object
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
48
State

• Status of object at a certain time
• Represented by attribute values and links

49
Behavior of Object and Its State

• Object become active reacting by receiving event.
  
• On receiving events, the object performs
  operation and change its state. It performs the
  same operation at the same state.
• It remains in the state until it receives new
  events.

50
object
event
Caller
Phone line
Callee
caller-lifts-receiver
state
dial-tone-begins
dial(5)
dial(1)
callee-hangs-up
connection-broken
connectin-broken
caller-hangs-up
51
Characterization of State

• Sequence of events leading to the state from the
  initial state

e3
e2
e1
Sinit
S
52

• A predicate/condition which is true at the state

S1
S2
state S a predicate PS
S3
S4
t ?S ? PS(t)true
53

• acceptable input eventsnext states

e1
e2
54
State Diagram

• Input EventNext state style description of the
  behavior of objects

State Diagram (STATE, EVENT,Trans, Sinit)
STATE a set of states EVENT a set of
events Trans STATEEVENT?STATE Sinit
initial state
55
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
56
Guarded Transitions
time-outcars in N/S left lanes
North/south may turn left
North/south may go straight
time-out no cars in N/S left lanes
time-out no cars in E/W left lanes
time-out
time-out
East/west may turn left
East/west may go straight
time-outcars in E/W left lanes
57
Transition with Actions
right button down /display pop-up menu
Idle
Menu visible
right button up /erase pop-up menu
cursor moved /highlight menu item
Action for pop-up menu
58
Unstructured State Transition Diagrams
State1 do Activity1
event(attributes)condition/action
State2 do Activity2
action sending output events changing attribute
values. It does not have duration. activity
operation done in a state. It may
have duration
59
Generalized State
push R
Transmission
Neutral
Reverse
push N
push N
push F
Forward
stop
upshift
upshift
First
Second
Third
downshift
downshift
60
Generalized State
push R
Transmission
Neutral
Reverse
push N
push N
push F
Forward
stop
upshift
upshift
First
Second
Third
downshift
downshift
61
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
stop
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
62
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
63
Collaboration Diagram
Computer
Queue
1Print(file)
printer busy 1.2 Store(file)
PrinterServer
Printer
printer Free 1.1 Print(file)
64
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
65
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)
66
Deployment Diagram

• Machines, programs and connections

MachineA Gateway
MachineB Fujitsu
NetC
Client Program (client.exe)
Graphics lib (graphics.dll)
67
Topics in OO Methodologies

• Object Constraint Language OCL
• Formal Approach to OO Analysis

68
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 600 pm has to be
• delivered in the next working day

69

• 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

70
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

71
Customer nameString titleString isMaleBoolean d
ateOfBirthDate ageInteger
LoyaltyProgram enroll(cCustomer)
0..
0..
1..
program
1..
partners
ProgramPartner numberOfCustomersInteger
owner
0..
Membership
0..
cards
1..
ordered
CustomerCard validBoolean validFromDate goodThru
Date colorenumsilver,gold printedNameString
ServiceLevel
actual Level
0..1
delivered Services
card
LoyaltyAccount pointsInteger earn(iInteger) burn
(iInteger) isEmpty()Boolean
0..
Service conditionBoolean pointsEarnedInteger poi
ntsBurnedInteger descriptionString
card
0..
available Services
transactions
0..
Transaction pointsInteger dateDate program()Loy
altyProgram
0..
0..
transactions
transactions
Date nowDate isBefore(tDate)Boolean isAfter(t
Date)Boolean (tBate)Boolean
Burning
Earning
72
Customer nameString titleString isMaleBoolean d
ateOfBirthDate ageInteger
Customer agegt18
LoyaltyProgram enroll(cCustomer)
0..
0..
1..
program
1..
partners
ProgramPartner numberOfCustomersInteger
owner
0..
Membership
0..
cards
1..
ordered
CustomerCard validFrom.isBefore(goodThru)
CustomerCard validBoolean validFromDate goodThru
Date colorenumsilver,gold printedNameString
ServiceLevel
actual Level
0..1
delivered Services
card
LoyaltyAccount pointsInteger earn(iInteger) burn
(iInteger) isEmpty()Boolean
0..
Service conditionBoolean pointsEarnedInteger poi
ntsBurnedInteger descriptionString
card
0..
available Services
transactions
0..
Transaction pointsInteger dateDate program()Loy
altyProgram
0..
0..
transactions
transactions
Date nowDate isBefore(tDate)Boolean isAfter(t
Date)Boolean (tDate)Boolean
Burning
Earning
73
Customer nameString titleString isMaleBoolean d
ateOfBirthDate ageInteger
LoyaltyProgram enroll(cCustomer)
0..
0..
1..
program
1..
partners
ProgramPartner numberOfCustomersInteger
owner
0..
Membership
0..
cards
1..
ordered
CustomerCard validBoolean validFromDate goodThru
Date colorenumsilver,gold printedNameString
ServiceLevel
actual Level
0..1
delivered Services
card
LoyaltyAccount pointsInteger earn(iInteger) burn
(iInteger) isEmpty()Boolean
0..
Service conditionBoolean pointsEarnedInteger poi
ntsBurnedInteger descriptionString
card
0..
available Services
printName in CustomerCard is the concatenation of
name and title of Cutomer which holds it.
CustomerCard printedNamecustomer.title.concat(cu
stomer.name)
transactions
0..
Transaction pointsInteger dateDate program()Loy
altyProgram
0..
0..
transactions
transactions
Date nowDate isBefore(tDate)Boolean isAfter(t
Date)Boolean (tBate)Boolean
Burning
Earning
74
Customer nameString titleString isMaleBoolean d
ateOfBirthDate age()Integer
LoyaltyProgram enroll(cCustomer)
0..
0..
1..
program
1..
partners
ProgramPartner numberOfCustomersInteger
owner
0..
Membership
Program partner wants to restrict total points
is less than 10000 points. LoyaltyProgram partner
s.deliveredServices.transaction -gtselect(oclType
Burning) -gtcollect(points)-gtsumlt10000
0..
cards
1..
ordered
CustomerCard validBoolean validFromDate goodThru
Date colorenumsilver,gold printedNameString
ServiceLevel
actual Level
0..1
delivered Services
card
LoyaltyAccount pointsInteger earn(iInteger) burn
(iInteger) isEmpty()Boolean
0..
Service conditionBoolean pointsEarnedInteger poi
ntsBurnedInteger descriptionString
card
0..
availble Services
transactions
0..
Transaction pointsInteger dateDate program()Loy
altyProgram
0..
0..
transactions
transactions
Date nowDate isBefore(tDate)Boolean isAfter(t
Date)Boolean (tBate)Boolean
Burning
Earning
75

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

precondition
P
postcondition
76
Customer nameString titleString isMaleBoolean d
ateOfBirthDate age()Integer
LoyaltyProgram enroll(cCustomer)
0..
0..
1..
program
1..
partners
LoyaltyAccountisEmpty() pre -- none post
result (points0)
ProgramPartner numberOfCustomersInteger
owner
0..
Membership
0..
cards
1..
ordered
CustomerCard validBoolean validFromDate goodThru
Date colorenumsilver,gold printedNameString
ServiceLevel
actual Level
0..1
delivered Services
card
LoyaltyAccount pointsInteger earn(iInteger) burn
(iInteger) isEmpty()Boolean
0..
Service conditionBoolean pointsEarnedInteger poi
ntsBurnedInteger descriptionString
card
0..
availble Services
transactions
0..
Transaction pointsInteger dateDate program()Loy
altyProgram
0..
0..
transactions
transactions
Date nowDate isBefore(tDate)Boolean isAfter(t
Date)Boolean (tBate)Boolean
Burning
Earning
77
A Formal Approach to Object-Oriented Analysis
78
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.

79
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
80
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 gt
  source codes

81
Formal OO Methodology(what we have done)
Formal analysis models in ML
Modeling support
Object model
Unification mapping
Req.
Analysis
Dynamic model
Unified model
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
82
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 a1a2 b1b2
83
Counter
number
Class Counter
Dynamic model for Counter
(statechart after unification)
Counter.number0
s1
e-/ Counter.numberCounter.number-1
e/ Counter.numberCounter.number1
e/ Counter.numberCounter.number1
s2
84
Counter
constraintCounter.number?0
number
Counter.number0
s1
e-/ Counter.numberCounter.number-1
e/ Counter.numberCounter.number1
e/ Counter.numberCounter.number1
s2
85
Counter
Prove Counter.number?0
number
Counter.number0
s1
Counter.number?0
e-/ Counter.numberCounter.number-1
e/ Counter.numberCounter.number1
e/ Counter.numberCounter.number1
s2
Counter.number?1
86
Counter
Prove Counter.number?0
number
Counter.number0
s1
Counter.number?0
e-/ Counter.numberCounter.number-1
e/ Counter.numberCounter.number1
e/ Counter.numberCounter.number1
s2
Counter.number?1
(1) Counter.number?0 at S1 ? Counter.number?1 at
S2 i.e. Counter.number?0 ?
(Counter.number1)?1 (2) Counter.number?1 at S2 ?
Counter.number?0 at S1 i.e.
Counter.number?1 ? (Counter.number1?0)
87
Counter
Counter.number?0 Global Assertion
number
Local Assertion
Counter.number0
s1
Counter.number?0
e-/ Counter.numberCounter.number-1
e/ Counter.numberCounter.number1
e/ Counter.numberCounter.number1
s2
Counter.number?1
(3) Counter.number?0?Counter.number?Counter.number
?0
88
Axioms

• Six Axioms
• Local invariant axiom
• Global invariant axiom
• Event output axiom
• Event communication axiom
• Inheritance axiom
• Aggregation axiom

89
Inheritance Axiom
Let a class c be a super class of c1,, cn, and o
and oi be instantiated from c and ci.
?GA1GAn ?1?i?n ?si.GAi(?oisi) ? V1?i?n
?s.GAi(?os)
GA1VGA2
GA1
GA2
90
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

91
Constructed models
Repository
Model Editor
Generation of ML code for prototyping
Generation of axioms
Generated ML codes
Generated axioms
Prototyper
Verifier
92
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
-gt bool recieve (Prefix) 'a ObjectID EventID
'a StateID -gt bool obj (Prefix) Counter
ObjectID ... Axioms AX-LI_Counter- !o LA_s1
LA_s2. valid_Counter (o,LA_s1,LA_s2) gt
LA_s1(Counter_number o s1)/\LA_s2 (Counter_number
o s2) AX-GI_Counter- .... .... Definitions Count
er_inc_DEF- !n.inc n n1 Counter_LA_s1_DEF-
!x. Counter_LA_s1 x 0ltx Counter_LA_s2_DEF-
!x. Counter_LA_s2 x 1ltx Counter_GA_DEF -
!x. Counter_GA x 0ltx ...
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 -gt Counter StateID -gt num inc(Prefix)
num -gt num Counter_LA_s1 (Prefix) num -gt
bool Counter_LA_s2 (Prefix) num -gt
bool Counter_GA (Prefix) num -gt
bool valid_Counter (Prefix) e_plus (Prefix)
EventID e_minus (Prefix) EventID link
(Prefix) 'a ObjectID 'b ObjectID -gt bool
93
Proof in HOL

• - ADD_MONO_LESS_EQ
• val it - !m n p. m n lt m p n lt 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 lt 1 Counter_number obj s1
• 0 lt Counter_number obj s1 thm
• - val lemma1 snd (EQ_IMP_RULE it)
• val lemma1
• - 0 lt Counter_number obj s1 gt
• 1 0 lt 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 lt Counter_number obj s1 gt
• 1 lt 1 Counter_number obj s1

- val r1 SYM (SPEC (--Counter_number obj
s1--) Counter_LA_s1_DEF) val r1
- 0 lt 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 lt 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) gt
Counter_LA_s2 (1 Counter_number obj s1) thm
94
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.

95
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,