Object Modellling Technologies

Fundamental Concepts 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 wife, two daughters and one dog
2
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
3
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.
4
• Our Word is a collection of collaborating
entities
President
Factory Sales dept.
Factory
workers
Engineers Scientists 5
• Organize software according to the
structure of the world
Management Information
Object
Factory
Sales
Management
Dept.
Object
Object
Worker
Object
Design Object Laboratory Object 6
Requirement analysis,
Problem Specification, Design
Ｐ⇒Ｐ '
Platform Ｍ⇒Ｍ '
Real
World module A
Ｗ⇒Ｗ module B module C module D
' module E
b (defun
(rcs-write
f a c e (if (error-occurred (write-current-file))
(if buffer-is-modified
d (do-checkout (current-buffer-name)
)))
Design Ｄ⇒Ｄ ' (novalue))

(do-checkout c-buf co-fname
(setq c-buf (arg 1))
(setq co-fname (arg 2))
(if ( | (file-exists (concat "RCS/ " c-buf ".v"))
(progn
(messsage "please wait, nowlooking ")
(execute-monito- command
(concat ...
Programming, Test (message "done")
Program Ｓ⇒Ｓ‘
7
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
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), 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.
9
Communication via events
Attribute: position,color,...
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: Thai
Laos Myanmar abstraction
Indonesia
instantiation
class:
Tan
Shinoda Country
lives-in
class:
People
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
　 People― （ lives-in ）― Country
• Dependency, Realization,...
13
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
…
14
Typical Object-Oriented
Development Process
Architecture design
Analyzing Choice of impl. strategy
requirement Object model Object design
Reqrmnts 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
company division section
Object Model for classes in the e1/e2, u=f(v)

employee world and their relationship s1 s2
mai
x n
sub1
z Dynamic Model for behavior
sub3
EightyModels + One Language in UML
• description of each object
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
• Unified notations in Booch method, OMT
method(Rumbaugh), OOSE method
(Jacobson)
• Becoming a standard language 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 :
specifies functions of
system
Actor :
Sign an insurance human, machine,…
policy interacting with the system
Process sales
statistics
Process customer
Customer statistics
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
Use cases are described
by activity diagrams if they Insert coins
are well-defined.
Enough coins
inserted?
Show that drink

can be chosen
Show that drink
is not available
Choose drink
Drink customer drink not available
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 class Button class Drink class Disp
1 ． the actor depresses an op1 op1 op1

button op ２ op ２ op ２
2 ． action 1 is executed op ３　　 op ３　
3 ． a message is sent to
the actor
4. …
23
discover classes
Class Diagrams
• Classes in the system + Relations
• Relations among classes
– Inheritance
– Aggregation
– Association
– Dependency
– Realization
24
Class and Object
Employee Employee Employee

name:String name:’Smith’ name:’Sharp’
pos:String pos:’eng’ pos:’chief eng’
promote promote promote
Class Employee Objects instantiated from

the class Employee
25
Link and Association
• Link : Relation among objects instantiated

from classes
– Channel for event transmission
– Access path for data access/navigation
Person workat Company

Joe Smith Simplex Co.
26
• Association : Relation between classes
– Abstraction of links between objects
Person workat Company
Joe Smith∈Person Simplex Co.∈Company
27
Link and Classes
・ If OR1―O2 　 for some O1∈C1,O2∈C2

then
R
　　　　　　　 C1―C2
・ R⊆C1×C2
C represents objects instantiated from the class C
28
Direct Products of Sets and Relations
• Direct Product 　
C1×C2 ＝｛（ O1,O2 ）｜ O1∈C1 ， O2∈C2 ｝
• Relation R between C1 and C2 : 　 R⊆ C1×C2
– Parent relation 　 P⊆Human×Human
P={(x,y) | y is a parent of x, x,y are in Human}
– Devisor relation 　 D⊆N×N, N:the set of natural numbers
D={(m,n) | n=km for some k in N}
• When (O1,O2)∈R, we write O1 ー O2

R
29
Association and Multiplicity
Line 2..* 0..* Point
name Intersect name
Line Point
L1 P1
Line
Point
L2
P1
L2
Line
L3 P1 P2
L3
Line
L4
L5 L1 L4
Line
L5 30
Equipment
Inheritance name
manufacturer
weight
cost
Attributes and operations
are inherited from super
classes
Pump Heat exchanger Tank
suction pressure surface area volume
discharge pressure tube diameter pressure
Diaphragm pump flow rate ….
name=P101
manufacture=Simplex
… Diaphragm pump Plunger pump Floating roof tank
suct pressure=1.1 atm
diaphragm material diameter
…
height
diaph material=Teflon
31
Inheritance
• A method for classifying classes according to their generality
• Inheritance is not an association
B inherits attributes and operations

from A
super class A
　　 Attr*(B)=Attr*(A)∪Attr(B)
　　 Op*(B)=Op*(A)∪Op(B)
where,
　　 Attr*(C):attributes effective at C
subclass B
　　 Attr(C):attributes defined in C
　　 Op, Op*: similarly
32
Aggregation
Computer
1..*
Monitor System box Mouse Keyboard
1..* 0..1
Chassis CPU RAM Fan
33
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).
•
1. 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.
–
B C
34
2. 　 Operations of the object OA of the class
A is delegated to its parts OB,OC
OB Attr B
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. 35
An Example of Delegation
having copy copy

Person * document * paragraph * character
copy copy copy
36
Aggregation and Inheritance
• Aggregation is inherited.
A
B C D
*
E
Object of D has parts which are objects of B,C and E.

　　　　　 OD(OB,OC,OE1,OE2,...) 37
Lamp
Fluores- Incandes- Base Cover Switch Wiring

ent Lamp cent Lamp
Ballast Twist Starter Socket

mount
38
Recursive Aggregation
program
program: ： = ｛ block ｝
block::=simple statement
* ｜ compound statement
* block compound statement::= ｛ block ｝
｛ A ｝≡ ε ｜ A ｜ AA ｜ AAA ｜…
compound simple
sentence statement
39
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
40
Realization
R
class A class B
– Class B is a realization of A
• B is more concrete
• A is more abstract
• R: mapping B  A
41
Interface and Realization
• Interface is a special class with abstract operation.
It is used with classes which realize/implement
them.
<<interface>>
PopupMenu
ChoiceBlock
setDefault(choice:String)
setDefault(choice:Choice)
getChoice():String
getChoice():Choice
choice 1..*
choice 1..*
<<interface>> realization
Choice specifier implementationString
42
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
43
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
44
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
45
• Event Trace
– Sequence of events
– Scenario
• Sequence of events observe when the system
performs some function
• Event Trace Diagram/Sequence Diagam
46
An Event Sequence in a Telephone System
object
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
47
State
• Status of object at a certain time
• Represented by attribute values and links
s = ( attr1:12, attr2:5, L1:O1, L2:O3 )
L1 attr1=12,attr2=5
L2
O3∈C3
O1∈C1
O2∈C2
s∈state(C2)=V(attr1)×V(attr2)×C1×C3
48
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.
49
object
Caller event Phone line Callee
state dial-tone-begins
dial(5)
dial(1)
callee-hangs-up
connection-broken connectin-broken
caller-hangs-up
50
Characterization of State
• Sequence of events leading to the state from
the initial state
e3
e2
e1
Sinit S
e1e2e3....
S≡{e1e2e3.... | S0 → S}
51
• A predicate/condition which is true at the
state
S1 S2
state S≡ a predicate PS
S3 S4
t ∈S ⇔ PS(t):true
52
• acceptable input events ＋ next states
e1 S1
S
e2
S2
53
State Diagram
• “Input Event+Next 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: STATE×EVENT→STATE
Sinit : initial state
54
State Diagram for “Phone line”
caller-hangs-up
Idle
time-out
Dial tone Time-out
dial(n)
dial(n) time-out
Dialing
callee-hangs-up
Connected Disconnected
55
Guarded Transitions
North/south time-out[cars in N/S left lanes] North/south

may go straight may turn left
time-out
[no cars in N/S left lanes]
time-out time-out time-out

[no cars in E/W left lanes]
East/west East/west
may turn left time-out[cars in E/W left lanes] may go straight
56
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
57
Unstructured State Transition
Diagrams
State1 event （ attributes ） [condition]/action State2

do: Activity １ do: Activity2
action: sending output events changing attribute values.

It does not have duration.
activity: operation done in a state.
It may have duration
58
Generalized State
push R
Transmission
Neutral Reverse
push N
push N push F
Forward
stop upshift upshift
First Second Third
downshift downshift
59
Generalized State
push R
Transmission
Neutral Reverse
push N
push N push F
Forward
First Second Third
downshift downshift
60
Aggregation and Concurrent State Diagram
Car
Ignition Transmission Brake Accelerator
Transmission push R Accelerator

Neutral Reverse
push N On
push N push F
Forward depress release
First Second Third Off
downshift downshift
Brake
Ignition turn key to start Off
if Transmission in Neutral
… …
Off Starting On
release key
On
61
turn key off
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
62
Collaboration Diagram
Computer Queue
1:Print(file)
[printer busy]
1.2: Store(file)
PrinterServer Printer
[printer Free]
1.1: Print(file)
63
Activity Diagram
• Shows relationship among actions
– Intra-object actions
– Inter-object actions
CustomerWindow:
　　 PrintAllCustomers
Show MessageBoxe Create postscript
“Printing” onScreen file
Remove Send postscript

MessageBox file to printer
64
Component Diagram
• Software components(source, binary and executable) and their relationship
　　
Window
Handler
(whnd.cpp)
Window
Handler Graphics
(whnd.obj) lib
Comm
(graphics.dll)
Handler
(comhnd.cpp)
Comm
Handler Client
(comhnd.obj) Program
Main
(client.exe)
Class
(main.cpp)
Main
Class
(main.obj)
65
Deployment Diagram
• Machines, programs and connections
MachineA MachineB
　　　： Gateway 　　　： Fujitsu
NetC
Graphics Client
lib Program
(graphics.dll) (client.exe)
66
Topics in OO Methodologies
(1) Object Constraint Language OCL
(2) Formal Approach to OO Analysis
67
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”
68
• 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
69
“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
70
Customer
name:String
LoyaltyProgram 0..* title:String
1..* 0..*
isMale:Boolean
enroll(c:Customer) program
dateOfBirth:Date
1..* partners age:Integer
ProgramPartner owner
numberOfCustomers:Integer 0..*
Membership
{ordered} 1..* cards 0..*
ServiceLevel CustomerCard
actual valid:Boolean
Level validFrom:Date
0..1
delivered cardgoodThru:Date
Services 0..* LoyaltyAccount color:enum{silver,gold}
Service points:Integer printedName:String
condition:Boolean earn(i:Integer)
0..* card
pointsEarned:Integer burn(i:Integer)
pointsBurned:Integer available isEmpty():Boolean
description:String Services
transactions 0..*
Transaction
0..* points:Integer 0..*
transactions date:Date transactions
program():LoyaltyProgram
Date
$now:Date
isBefore(t:Date):Boolean
isAfter(t:Date):Boolean
Burning Earning =(t:Bate):Boolean
71
Customer
Customer
LoyaltyProgram
0..*
name:String
0..* title:String
1..*
age>=18
isMale:Boolean
dateOfBirth:Date
Membership
CustomerCard Level
0..1
validFrom:Date
Services 0..* validFrom.isBefore(goodThru)
LoyaltyAccount color:enum{silver,gold}
0..* card
transactions 0..*
Transaction
Date
$now:Date
Burning Earning =(t:Date):Boolean
72
Customer
name:String
1..* 0..*
isMale:Boolean
dateOfBirth:Date
Membership
0..1
0..* card
printName in CustomerCard is the concatenation of
transactions 0..*
name and title of Cutomer which holds it.
Transaction
CustomerCard 0..* points:Integer 0..*
date:Date
printedName=customer.title.concat(customer.name)
transactions
transactions
Date
$now:Date
73
Customer
name:String
1..* 0..*
isMale:Boolean
dateOfBirth:Date
1..* partners age():Integer
Membership
Program partner wants to restrict total points
cards 0..*
{ordered} 1..*
is less than 10000 points. CustomerCard
ServiceLevel
delivered
LoyaltyProgram 0..1
cardgoodThru:Date
Services 0..* partners.deliveredServices.transaction
LoyaltyAccount color:enum{silver,gold}
points:Integer printedName:String
Service ->select(oclType=Burning)
earn(i:Integer)
condition:Boolean card
pointsEarned:Integer
0..* ->collect(points)->sum<10000
burn(i:Integer)
pointsBurned:Integer availble isEmpty():Boolean
transactions 0..*
Transaction
Date
$now:Date
74
• 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
75
Customer
name:String
1..* 0..*
isMale:Boolean
dateOfBirth:Date
1..* partners age():Integer
ProgramPartner
numberOfCustomers:Integer
LoyaltyAccount::isEmpty()
0..*
owner
Membership
pre : -- none cards 0..*
{ordered} 1..*
post : result = (points=0)
0..1
0..* card
pointsBurned:Integer availble isEmpty():Boolean
transactions 0..*
Transaction
Date
$now:Date
76
A Formal Approach to Object-
Oriented Analysis
77
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.
78
Current OO Methodology
Informal description, probably inconsistent
Usually, requirements are
and inconsistent
inconsistent,
(diagrams +natural language)
incomplete,
imprecise, … Object model
Req.. Analysis Dynamic model Design Coding
Model unification in design

/coding phase in human brain
Long and costly feedback

79
• 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
80
(what we have done)
Formal analysis models in ML
Modeling support Object model

Unification mapping
Req. Analysis Dynamic model Unification Unified model
Verification/ Determination
prototype of software Software
Software
execution generation
architecture
(1)ML-based execution
environment
Implementation
(2) Consistency Verification condition
using theorem proving system HOL
81
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 82

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
s2
Counter
number constraint ：” Counter.number≧0”
Counter.number:=0
s1
-
s2
Counter
Prove ”Counter.number≧0”
number
Counter.number:=0
s1 Counter.number≧0
-
Counter
Prove ”Counter.number≧0”
number
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)
Counter
Counter.number≧0 ： Global Assertion
number
Local Assertion
Counter.number:=0
-
(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
88
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 GA1VGA2
GA1 C1 C2 GA2
89
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
90
Constructed models
Repository
Model Editor
Generation of ML Generation of axioms
code for prototyping
Generated ML codes Generated axioms
Prototyper Verifier
Generation of Axioms
• Axioms are introduced into HOL as its theory
modules, which are type/term constants, axioms
or definitions ．
Type constants: send (Prefix):
Counter 0 'a ObjectID # EventID # 'a StateID -> bool
EventID 0 recieve (Prefix):
StateID 1 'a ObjectID # EventID # 'a StateID -> bool
ObjectID 1 obj (Prefix): Counter ObjectID
Term constants: ...
s1 (Prefix) :Counter StateID Axioms:
s2 (Prefix) :Counter StateID AX-LI_Counter|- !o LA_s1 LA_s2.
Counter_number (Prefix): 　 valid_Counter (o,LA_s1,LA_s2) ==>
　 Counter ObjectID -> Counter StateID -> num 　 LA_s1(Counter_number o s1)/\LA_s2 (Counter_number o s2)
inc(Prefix) :num -> num AX-GI_Counter|- ....
Counter_LA_s1 (Prefix) :num -> bool ....
Counter_LA_s2 (Prefix) :num -> bool Definitions:
Counter_GA (Prefix) :num -> bool Counter_inc_DEF|- !n.inc n = n+1
valid_Counter (Prefix): Counter_LA_s1_DEF|- !x. Counter_LA_s1 x = 0<=x
e_plus (Prefix) :EventID Counter_LA_s2_DEF|- !x. Counter_LA_s2 x = 1<=x
e_minus (Prefix) :EventID Counter_GA_DEF |- !x. Counter_GA x = 0<=x
link (Prefix): 'a ObjectID # 'b ObjectID -> bool ... 92
Proof in HOL
- ADD_MONO_LESS_EQ; - val r1 =
val it = |- !m n p. m + n <= m + p = n <= p : thm SYM (SPEC (--`Counter_number obj s1`--)
- ADD_0; Counter_LA_s1_DEF);
val it = |- !m. m + 0 = m : thm val r1 =
- SPEC (--`Counter_number obj s1`--) |- 0 <= Counter_number obj s1 =
(SPEC (--`0`--) Counter_LA_s1 (Counter_number obj s1): thm
(SPEC (--`1`--) - val r2 =
ADD_MONO_LESS_EQ)); SYM (SPEC (--`1 + Counter_number obj s1`--)
val it = |- 1 + 0 <= 1 + Counter_number obj s1 = Counter_LA_s2_DEF);
0 <= Counter_number obj s1: thm val r2 =
- val lemma1 = snd (EQ_IMP_RULE it); |- 1 <= 1 + Counter_number obj s1 =
val lemma1 = Counter_LA_s2 (1 + Counter_number obj s1): thm
|- 0 <= Counter_number obj s1 ==> - val step1 = REWRITE_RULE [r1, r2] lemma2;
1 + 0 <= 1 + Counter_number obj s1 : thm val step1 =
-SPEC (--`1`--) ADD_0; |- Counter_LA_s1 (Counter_number obj s1) ==>
val it = |- 1 + 0 = 1 : thm Counter_LA_s2 (1 + Counter_number obj s1) :
- val lemma2 = REWRITE_RULE [it] lemma1; thm
val lemma2 = |- 0 <= Counter_number obj s1 ==>
1 <= 1 + Counter_number obj s1
93
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.
94
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’,…
95

Object Modellling Technologies

Enviado por

Dados do documento

Descrição original:

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Object Modellling Technologies

Enviado por

Direitos autorais:

Formatos disponíveis

Fundamental Concepts in Object-

Factory Sales dept.

Ｗ⇒Ｗ module B module C module D

Design Ｄ⇒Ｄ ' (novalue))

Programming, Test (message "done")

• How do we describe the world?

• Class Hierarchy, Inheritance, “is a”

Reqrmnts Analysis Dynamic model Design Coding

company division section

Object Model for classes in the e1/e2, u=f(v)

• Notations to describe every aspects of

• Use Cases describe a rough sketch of

Show that drink

Drink customer drink not available

use case U collaboration

use case description class Button class Drink class Disp

1 ． the actor depresses an op1 op1 op1

Employee Employee Employee

Class Employee Objects instantiated from

• Link : Relation among objects instantiated

Person workat Company

Person workat Company

Joe Smith∈Person Simplex Co.∈Company

・ If OR1―O2 for some O1∈C1,O2∈C2

• When (O1,O2)∈R, we write O1 ー O2

B inherits attributes and operations

Monitor System box Mouse Keyboard

Reacting to events from outside, OA send events to OB and OC

having copy copy

copy copy copy

Object of D has parts which are objects of B,C and E.

Fluores- Incandes- Base Cover Switch Wiring

Ballast Twist Starter Socket

– Utilize class A in class B

• Description of individual objects

s = ( attr1:12, attr2:5, L1:O1, L2:O3 )

• Object become active reacting by receiving

State Diagram = (STATE, EVENT,Trans, Sinit)

North/south time-out[cars in N/S left lanes] North/south

time-out time-out time-out

right button down

Action for pop-up menu

State1 event （ attributes ） [condition]/action State2

action: sending output events changing attribute values.

Ignition Transmission Brake Accelerator

Transmission push R Accelerator

Print(file) [printer free]

・ Shows possible sequence(s) of messages among objects

Remove Send postscript

(1) Object Constraint Language OCL

(2) Formal Approach to OO Analysis

• Mileage Handling company

Req.. Analysis Dynamic model Design Coding

Model unification in design

Long and costly feedback

Modeling support Object model

Req. Analysis Dynamic model Unification Unified model

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 82

Dynamic model for Counter (statechart after unification)

　　 use case description class Button class Drink class Disp

・ If OR1―O2 　 for some O1∈C1,O2∈C2