object modellling technologies

8/14/2019 object modellling technologies

1/95

1

Fundamental Concepts in Object-

Oriented Methodology

Takuya Katayama

JAIST


2/95

2

Hi !

Myself

Prof. at Japan Advanced Institute of Science and

TechnologyWorking 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/95

3

Agenda

Fundamental Concepts in Object-OrientedMethodologies

Objects, Classes, Structures among ClassesBehavior of Objects, State, State charts

UML

Some Topics in OO MethodologiesConstraints and OCLProving Constraints


4/95

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

5


Our Word is a collection of collaborating

entities

Factory

Factory

workers

President

Engineers Scientists

Sales dept.


6/95

6


Organize software according to the

structure of the world

Factory

Management

Object

Worker

Object

Design Object

Management Information

Object

Sales

Dept.

Object

Laboratory Object


7/95

7

Program

Requirement analysis,Specification, Design

Programming, Test

Platform '

(defun(rcs-write

(if (error-occurred (write-current-file))(if buffer-is-modified

(do-checkout (current-buffer-name))))

(novalue))(do-checkout c-buf co-fname

(setq c-buf (arg1))(setq co-fname (arg 2))

(if ( | (file-exists (concat "RCS/" c-buf ".v"))(progn(messsage "please wait, nowlooking ")(execute-monito- command

(concat ...(message "done")

Design '

a

b

ec

d

f

module B module C module D

module A

module E

Problem

'

RealWorld

'


8/95

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

9

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 eventsto 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/95

10

Attribute: position,color,...

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

Behavior: e/move, e

Communication via events


11/95

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

12

object: Thai

Myanmar

ShinodaTan

class:

Country

class:

People

abstraction

instantiation

Laos

lives-in

Objects and Classes

Indonesia


13/95

13

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


14/95

14

Two Major Issues in Object-

Oriented Methodology

Object-Oriented Analysis/Design

BOOCH, OMT, UML, Catalysis methodsConstraints, Formal Approach, Analysis

Patterns,Unified Process,

Object-Oriented ProgrammingOO languages: Smalltalk, C++, Java Design Patterns, Frameworks , Class Libraries


15/95

15

Typical Object-Oriented

Development Process

Dynamic model

Object model

Analysis Design CodingReqrmnts

Analysis models

Architecture design

Choice of impl. strategy

Object design

Coding in OO

language

Analyzingrequirement


16/95

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

employee

mai

n sub1

sub2

sub3

x

yz

Object Model for classes in the

world and their relationship

Functional Model for data flow in the world

Dynamic Model for behavior

description of each object

e1/e2, u=f(v)

s1 s2


17/95

17

UML

Notations to describe every aspects ofsoftware development

From business systems to industrialembedded systems

Unified notations in Booch method, OMTmethod(Rumbaugh), OOSE method(Jacobson)

Becoming a standard language of softwareengineer


18/95

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

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

20

Use Case Diagram

Insurance Salesperson

Sign an insurancepolicy

Process sales

statistics

Process customer

statisticsCustomer

Insurance System

Use cases :specifies functions ofsystem

Actor :human, machine,

interacting with the system


21/95

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

22

Insert coins

Enough coinsinserted?

Show that drink

can be chosen

Choose drink

Deliver drink

drink not available

drink available

Show that drinkis not available

Drink customer

Use cases are described

by activity diagrams if they

are well-defined.


23/95

23

use case description

1 the actor depresses anbutton

2 action 1 is executed3 a message is sent to

the actor4.

class Button

op1op op

class Drink

op1op

class Disp

op1op op

use case U collaboration

In OO development, use cases are used to find

objects. Functions represented by the use cases

are realized as collaborations among the objects.

discover classes


24/95

24

Class Diagrams

Classes in the system + Relations

Relations among classes

Inheritance

Aggregation

Association

Dependency

Realization


25/95

25

Class and Object

Employee

name:Stringpos:String

Objects instantiated fromthe class Employee

Class Employee

promote

Employee

name:Smithpos:eng

promote

Employee

name:Sharppos:chief eng

promote


26/95

26

Link and Association

Link : Relation among objects instantiated

from classes

Channel for event transmissionAccess path for data access/navigation

Joe Smith

workat

Simplex Co.

Person Company


27/95

27

Association : Relation between classesAbstraction of links between objects

Person

workatCompany

Joe Smith Person Simplex Co. Company


28/95

28

Link and Classes

If O1O2 for some O1 C 1,O2 C 2then

C1C2

R C 1C2

C represents objects instantiated from the class C

R

R


29/95

29

Direct Products of Sets and Relations

Direct Product

C1C2 O1,O2 O1 C 1 O2 C 2

Relation R between C1 and C2 : R C 1C2 Parent relation P HumanHuman

P={(x,y) | y is a parent of x, x,y are in Human}

Devisor relation D NN, N:the set of natural numbers

D={(m,n) | n=km for some k in N}

When (O1,O2) R, we write O 1 O2R


30/95

30

Association and Multiplicity

LineL1

LineL2

Line

L3

LineL4

Line

L5

PointP1

PointP1

L2

L3

L1 L4L5

P1 P2

Linename

Pointname

2..* 0..*

Intersect


31/95

31

Inheritance

Equipment

name

manufacturerweightcost

Pumpsuction pressuredischarge pressureflow rate

Tankvolumepressure

Heat exchangersurface areatube diameter.

Diaphragm pump

diaphragm material

Floating roof tank

diameterheight

Diaphragm pumpname=P101manufacture=Simplexsuct pressure=1.1 atmdiaph material=Teflon

Plunger pump

Attributes and operations

are inherited from super

classes


32/95

32

Inheritance

A method for classifying classes according to their generality

Inheritance is not an association

A

B

super class

subclass

B inherits attributes and operations

from A

Attr*(B)=Attr*(A) Attr(B)

Op*(B)=Op*(A) Op(B)

where,

Attr*(C):attributes effective at C Attr(C):attributes defined in C Op, Op*: similarly


33/95

33

Aggregation

Computer

Monitor System box Mouse Keyboard

Chassis CPU RAM Fan

1..*

1..* 0..1


34/95

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

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.

A

B C


35/95

35

2. Operations of the object OA of the classA is delegated to its parts OB,OC

OA Attr A

OC Attr C

Attr BOB

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

36

Person paragraphdocument character

copy copy

having copy copy

copy

An Example of Delegation

***


37/95


38/95

38

Lamp

Fluores-

ent Lamp

Ballast Twist

mount

Starter

Incandes-

cent Lamp

Socket

Cover WiringSwitchBase


39/95

39

Recursive Aggregation

program

block

compound

sentence

simple

statement

program: = block

block::=simple statement compound statementcompound statement::= block

A A AA AAA

**


40/95

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

41

Realization

Class B is a realization of A

B is more concrete

A is more abstract

R: mapping B A

class A class BR


42/95


43/95

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

44

State Diagram

Description of individual objects

Fundamental concepts

event, state, scenario, event trace, state transition, statetransition diagram, operation, action

Advanced concepts nested transition diagram, generalized state,

concurrency, event dispatching, synchronization ofconcurrency


45/95

45

Event and Event Trace

Event

Stimulus which an object transmit to other

objectsObject reacts to events and perform associated

tasks

Event has no duration time.

Event may have attributes, which represents itscontents


46/95

46

Event Trace

Sequence of events

Scenario Sequence of events observe when the system

performs some function

Event Trace Diagram/Sequence Diagam


47/95

47

An Event Sequence in a Telephone System

caller-lifts-receiver

dial-tone-begins

dial(5)

dial(1)

connection-broken connectin-broken

caller-hangs-up

Caller Phone line Callee

callee-hangs-up

event

object


48/95

48

State

Status of object at a certain time

Represented by attribute values and links

attr1=12,attr2=5

O1 C 1O2 C 2

O3

C

3

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

L1L2

s state(C 2)=V(attr1)V(attr2)C1C3


49/95

49

Behavior of Object and Its State

Object become active reacting by receivingevent.

On receiving events, the object performsoperation and change its state. It performsthe same operation at the same state.

It remains in the state until it receives newevents.


50/95

50


dial-tone-begins

dial(5)

dial(1)

connection-broken connectin-broken

caller-hangs-up

Caller Phone line Callee

callee-hangs-up

eventobject

state


51/95

51

Characterization of State

Sequence of events leading to the state from

the initial state

Sinit S

e1 e2

e3

S{e1e2e3.... | S0 S }e1e2e3....


52/95


53/95

53

acceptable input events next states

S

S1

S2

e2

e1


54/95

54

State Diagram

Input Event+Next state style description ofthe behavior of objects

State Diagram = (STATE, EVENT,Trans, Sinit)STATE: a set of states

EVENT: a set of events

Trans: STATEEVENTSTATE

Sinit : initial state


55/95

55

State Diagram for Phone line

Idle

Dial tone

Dialing

Time-out

Connected Disconnected


dial(n)

callee-hangs-up

time-out

caller-hangs-up

dial(n) time-out


56/95


57/95

57

Transition with Actions

Idle Menu visible

right button down

/display pop-up menu

right button up

/erase pop-up menucursor moved

/highlight menu item

Action for pop-up menu


58/95

58

Unstructured State Transition

Diagrams

State1do: Activity

State2do: Activity2

event attributes [condition]/action

action: sending output events changing attribute values.

It does not have duration.activity: operation done in a state.

It may have duration


59/95

59

Generalized State

Neutral Reverse

First Second Third

downshift

upshiftstop

push N push Fpush N

push RTransmission

Forward

downshift

upshift


60/95

60

Generalized State

Neutral Reverse

First Second Third

downshift

upshiftstop

push N push Fpush N

push RTransmission

Forward

downshift

upshift


61/95

61

Aggregation and Concurrent State Diagram

Neutral Reverse

First Second Thirdupshift

downshift downshift

upshiftstop

push N push Fpush N

Car

Ignition Transmission Brake Accelerator

push RTransmission

Off Starting On

turn key to startif Transmission in Neutral

release key

turn key off

Ignition

On

Off

Accelerator

Off

On

Brake

depress releaseForward


62/95

62

Sequence Diagram

:Computer :PrinterServer :Printer :QueuePrint(file)

Print(file) [printer free]

Print(file)

[printer busy]

Store(file)

Shows possible sequence(s) of messages among objects Inter-object behavior


63/95

63

Collaboration Diagram

Computer

PrinterServer

Queue

Printer

1:Print(file)[printer busy]

1.2: Store(file)

[printer Free]

1.1: Print(file)


64/95


65/95

65

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

WindowHandler(whnd.cpp)

CommHandler(comhnd.cpp)

MainClass(main.cpp)

WindowHandler(whnd.obj)

CommHandler(comhnd.obj)

MainClass(main.obj)

Graphicslib

(graphics.dll)

Client

Program(client.exe)


66/95

66

Deployment Diagram

Machines, programs and connections

Graphicslib

(graphics.dll)

ClientProgram

(client.exe)

MachineA Gateway

MachineB Fujitsu

NetC


67/95


68/95

68

Constraints and OCL

Constraints

Description of systems and services using theirproperties

Usually, constraints are described by the results of theservices 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


69/95

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

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

71

Membership

ServiceLevel

LoyaltyProgram

enroll(c:Customer)

ProgramPartnernumberOfCustomers:Integer

Customername:Stringtitle:StringisMale:BooleandateOfBirth:Dateage:Integer

Servicecondition:BooleanpointsEarned:IntegerpointsBurned:Integerdescription:String

Transaction

points:Integerdate:Dateprogram():LoyaltyProgram

CustomerCardvalid:BooleanvalidFrom:DategoodThru:Date

color:enum{silver,gold}printedName:StringLoyaltyAccountpoints:Integerearn(i:Integer)burn(i:Integer)isEmpty():Boolean

Date$now:DateisBefore(t:Date):BooleanisAfter(t:Date):Boolean=(t:Bate):BooleanBurning Earning

0..*0..*

0..*

1..*

1..* partners

0..*

delivered

Services

0..* 0..*

0..*

program

availableServices

0..*

actualLevel

card

card

transactionstransactions

transactions

0..*cards

owner

1..*{ordered}

0..1

C


72/95

72

Membership

ServiceLevel

LoyaltyProgram

enroll(c:Customer)




Transaction




Date$now:DateisBefore(t:Date):BooleanisAfter(t:Date):Boolean=(t:Date):BooleanBurning Earning

0..*0..*

0..*

1..*

1..* partners

0..*

delivered

Services

0..* 0..*

0..*

program

availableServices

0..*

actualLevel

card

card


transactions

0..*cards

owner

1..*{ordered}

0..1

Customerage>=18

CustomerCardvalidFrom.isBefore(goodThru)

C t


73/95

73

Membership

ServiceLevel

LoyaltyProgram

enroll(c:Customer)




Transaction





0..*0..*

0..*

1..*

1..* partners

0..*

deliveredServices

0..* 0..*

0..*

program

availableServices

0..*

actualLevel

card

card


transactions

0..*cards

owner

1..*{ordered}

0..1

printName in CustomerCard is the concatenation ofname and title of Cutomer which holds it.

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

C t


74/95

74

Membership

ServiceLevel

LoyaltyProgram

enroll(c:Customer)


Customername:Stringtitle:StringisMale:BooleandateOfBirth:Dateage():Integer


Transaction





0..*0..*

0..*

1..*

1..* partners

0..*

deliveredServices

0..* 0..*

0..*

program

availbleServices

0..*

actualLevel

card

card


transactions

0..*cards

owner

1..*{ordered}

0..1

Program partner wants to restrict total pointsis less than 10000 points.

LoyaltyProgram

partners.deliveredServices.transaction->select(oclType=Burning)->collect(points)->sum


75/95

75

Defining operations by Pre-, Postcondition

precondition specifies condition when the

operation could be triggered.postcondition: specifies condition which holds

after the operation.

Pprecondition postcondition

Customer


76/95

76

Membership

ServiceLevel

LoyaltyProgram

enroll(c:Customer)


Customername:Stringtitle:StringisMale:BooleandateOfBirth:Dateage():Integer


Transaction


CustomerCardvalid:BooleanvalidFrom:DategoodThru:Datecolor:enum{silver,gold}printedName:StringLoyaltyAccountpoints:Integer

earn(i:Integer)burn(i:Integer)isEmpty():Boolean


0..*0..*

0..*

1..*

1..* partners

0..*

deliveredServices

0..* 0..*

0..*

program

availbleServices

0..*

actualLevel

card

card


transactions

0..*cards

owner

1..*{ordered}

0..1

LoyaltyAccount::isEmpty()pre : -- nonepost : result = (points=0)


77/95

77

A Formal Approach to Object-Oriented Analysis


78/95

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 theoverall quality of final products.

So-called formal methods do not consider practices of OOmethodologies seriously.

Object-orientation of formal methods

Formalization of practical OO methodologies is needed.


79/95

79

Current OO Methodology

Dynamic model

Object model

Analysis Design CodingReq..

Informal description, probably inconsistent

and inconsistent

(diagrams +natural language)

Model unification in design

/coding phase in human brain

Usually, requirements are

inconsistent,

incomplete,

imprecise,

Long and costly feedback

F l OO M h d l


80/95

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 provingtechniques

Transformation from the unified models to software architecture

Software architecture + implementation model => source codes


81/95

81

Formal OO Methodology(what we have done)

Req. Dynamic model

Object model

Analysis Unified model

Formal analysis models in ML

Unification

Modeling support

Verification/

prototypeexecution

Determination

of softwarearchitecture

Softwaregeneration

Implementation

condition

Software

(2) Consistency Verificationusing theorem proving system HOL

(1)ML-based executionenvironment

Unification mapping


82/95

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,

Opr. f1,f2,

e1/act,e2

Attr. b1,b2,

Opr. g1,g2,

e1/act,e2e1 e1

constraint: a1+a2 = b1+b2


83/95

Counter

number

Counter.number:=0

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

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


(statechart after unification)Dynamic model forCounter

Class Counter

s2

s1


84/95

Counter

number

Counter.number:=0




s2

s1

constraint Counter.number0


85/95

Counter

number

Counter.number:=0




s2

s1

Prove Counter.number0

Counter.number0

Counter.number1


86/95

Counter

number

Counter.number:=0

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


s2

s1

Prove Counter.number0

Counter.number0

Counter.number1

(1) Counter.number0 at S1 Counter.number1 at S2i.e. Counter.number0 (Counter.number+1)1

(2) Counter.number1 at S2 Counter.number0 at S1i.e. Counter.number1 (Counter.number10)


87/95

Counter

number

Counter.number:=0




s2

s1

Counter.number0 Global Assertion

Counter.number0

Counter.number1

Local Assertion

(3) Counter.number0Counter.numberCounter.number0


88/95

88

Axioms

Six Axioms:

Local invariant axiom

Global invariant axiomEvent output axiom

Event communication axiom

Inheritance axiomAggregation axiom

I h it A i


89/95

89

Inheritance Axiom

GA1GAn

1 i nsi.GAi( [oi][si]) V1 i ns.GAi( [o][s])

Let a class c be a super class of c1,, cn, and o and oi beinstantiated from c and ci.

C

C1 C2GA1 GA2

GA1VGA2


90/95

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

Constructed models


91/95

Repository

Constructed models

Prototyper Verifier

Generated ML codes Generated axioms

Generation of axiomsGeneration of MLcode for prototyping

Model Editor

Generation of Axioms


92/95

92

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 1ObjectID 1

Term constants:

s1 (Prefix) :Counter StateID

s2 (Prefix) :Counter StateID

Counter_number (Prefix):

Counter ObjectID -> Counter StateID -> num

inc(Prefix) :num -> numCounter_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 -> boolobj (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


93/95

93

Proof in HOL

- ADD_MONO_LESS_EQ;val it = |- !m n p. m + n


94/95


95/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, weneed Abstract domain libraries

Theorems about Banking System, Hotel,

Reuse of proof steps Domain specific proof tactics

Proof tactics for Banking System,

Date post:	30-May-2018
Category:	Documents
Upload:	urvipatil
View:	218 times
Download:	0 times

object modellling technologies

Documents