D /1992/2376/32

ONDERZOEKSRAPPORT NR 9226

Event Concurrency Analysis in

Object- Oriented Models

by

Guido DEDENE

Monique SNOECK

O.ABSTRACT

EvENT CONCURRENCY ANALYSIS IN

OBJECT-ORIENTED BUSINESS MODELS

Prof. Dr. Guido DEDENE Drs. Monique SNOECK

Katholieke Universiteit Leuven Faculty of Economics and Applied Economics

Dekenstraat, 2 B-3000 Leuven

Belgium Tel : 00 32 16 28 57 10 Fax : 00 32 16 28 57 99

e-mail: fdbaa30@ccl.kuleuven.ac.be

This paper discusses the impact of an Object-Oriented systems development approach,

M.E.RO.DE., on the concurrency of Event types in the life of Object types. Conditions are

derived such that appropriate declaration of Relationship Object types disable deadlocking

for Business Event types in Object-Oriented Business Models. The obtained results allow

the construction of Business Models with a higher degree of consistency in the

specifications as opposed to other modelling techniques. The definitions and results are

illustrated with examples.

Keywords :Object Oriented Analysis, Business Modeling, Formal Specifications,

Requirements Analysis, Software Engineering, Methodologies, Software Quality

Assurance.

1. INTRODUCTION

Encapsulation is a fundamental characteristic of Object Orientation : it expresses the fact

that information is the duality of data and process. Because of this integrating duality,

Object-Oriented Business Models open promising perspectives for higher quality software

development [DEDENE 91]. A major driver in this process is the detection of

inconsistencies in the Model specifications as early as possible in the life cycle

(BOEHM 91]. Experimentation with prototyping in early Object-Oriented Analysis

techniques revealed that easily conflicting specifications can be constructed that result in

deadlocking Models. Relying on the prototyping and testing process to detect such

fundamental misspecifications is not acceptable from an economical as well as a formal

viewpoint.

From an information architecture viewpoint, Business Modelling is a higher level of

abstraction than design modeling or implementation modeling (ZACHMAN 87). Because of

this classical deadlock prevention results cannot be extended in a straightforward way at

the level of abstraction of Business Modeling. In fact, at that level there is no ~oncept of

resource sharing, a traditional source of deadlock. This should not be confused With

Business Models in which Business Resource are shared. Because at the Business

Modeling Layer of abstraction there is no concept of interobject communication [DEDENE

92). classical protocol validation or concurrent programming results cannot be used either.

In fact Business Objects only rely on polymorphism to react jointly to Business Events.

Hence new approaches are needed which use the nature of the Object Type declarations as

a basis for deadlock prevention.

In the M.E.R.O.DE. approach [VERHELST 92J[DEDENE 92][SNOECK 91] object orientation

is achieved through the encapsulation of event structures and constraints into Entity

Relationship models. extending the approach of [RUMBAUGH 91]. Object types are

basically sets of Event types which are structured using classical structure primitives as in

- 2 -

J.S.D. [JACKSON 83]. This paper uses an algebraic approach to build the Object-oriented

specifications in such a way that they avoid sequence conflicts that would result in

deadlocks. In fact. the main theorem of this paper proves that under some strong, but

nevertheless not unrealistic conditions. Business Models can be constructed which do not

contain deadlocking specifications. A key element in the discussion is the lattice structure

that is introduced to classify Object types in M.E.R.O.DE. Business Models. This lattice

structure is induced by the natural partial ordering relation that follows from the algebraic

properties of the structure primitives that are used for Event type modeling.

The use of mathematics in systems analysis and in particular in Business Modeling might

be surprising. However, as mathematical definitions are unambiguous, they provide a

powerful reference mechanism for defining Object types. Object type behaviour, Business

behaviour rules. and proof mechanisms for correctness and consistency. Moreover

transformations that preserve consistency and correctness can be defined. These

transformations are the basis of the building of efficient executable systems in order to

enable transformation based implementation.

The proposed approach relies heavily on algebraic structures. and in particular the

properties of idempotent semi-rings ([COHN 74). [KUICH 86)). This paper will reuse many

of the results known on those kinds of structures in algebra for checking the consistency of

Object Type behaviour declarations. The apparent abstraction capabilities that seem to be

required at first sight to access these mathematics is rewarded by the simplicity and

transparency of the final obtained specifications. In this way the consistency checking is

the framework for evaluating and building CASE-environments for M.E.R.O.DE.

- 3 -

2. PROBLEM DESCRIPTION

In M.E.RO.DE. objects are modelled through Object types. Executing a system means

that object instances of Object types are created and deleted dynamically. The object

instances behave conforming their defined Object type. When execution starts no object

instance exists (all objects must be created) and when execution ends, all objets must have

terminated successfully (all objects must be deleted). An object is deadlocked if it is waiting

for an event that can not occur any more (e.g. because it will always be rejected by at least

one other object).

Deadlock occurs when two or more objects are executed in parallel and these objects imply

contradicting sequence restrictions on events. This is illustrated by means of specification

for a library circulation system :

Before one can borrow a book he must make a reservation for that book.

If a person wants to borrow a book that already is on loan, he can make a reservation for

that book. If a book is on shelf, it can be taken along immediately.

These specifications would give rise to the following Behaviour rules :

MEMBER= .... (reserve.borrow) .....

BOOK= .... (borrow.reserve +borrow) ....

Clearly in this library it is impossible to borrow a book ! If one wants to borrow a book, it

must be reserved first (sequence restrictions of MEMBER): but to reserve a book it must

already be in loan (sequence restrictions of BOOK). In this case the sequence conflict leaps

to the eyes, but it is easy to imagine more hidden forms of conflicts (e.g. when the conflict 1s

spread over three or more object types). The process algebra developed in this paper allows

to track conflicts by means of (automatable) calculations.

- 4-

3. THE M.E.R.O.DE. BUSINESS MODELING FORMALISM

3.1 Basic Definitions

3.1.1 Object expressions

Consider a set A of Business Event types within a predefined universe of discourse. (The

determination of the universe of discourse is handled at the scope modeling layer of

abstraction in the Zachman framework [ZACHMAN 87].) Denote by R(A) the set that is

generated by imposing two operations on A: the sequence "." and the selection"+". These

operations correspond to the classical structure primitives for Regular Expressions and

satisfy the following laws :

x+y=y+x (x + y) + z = x + (y + z)

(x . y) . z = x . (y . z)

X.l=l.X=X

(commutativity of+) (associativity of+)

(associativity of .) ( 1 is a neutral, called the "do-nothing" Event type)

The following distributivity laws hold:

(x + y) . z = x . z + y . z

X . (y + z) = X . y + X . Z

A set equipped with two operations satisfying the above laws is called a semi-ring (KUICH

86]. Moreover the selection+ is an idempotent operation (Hobson's choice):

X+X=X

Consequently R(A) is an idempotent semi-ring.

The neutral element for the selection operator is defined as 0 and can be interpreted as a

deadlocked object. In fact. 0 is an absorbing element for the sequence :

- 5 -

x + 0 = x = 0 + x and x.O = 0 = O.x

The event types that are used in the regular expressions are called the alphabet of the

expression. cp is the forgetful mapping that maps every expression in R(A) onto the subset

of A of event types involved in the expression :

<p : R(A) ------> 1lA)

such that cp(a) ={a} cp(x + y) = cp(x) u cp(y) cp(x . y) = cp(x) u cp(y) <p(O) is not defined

aE A

x. y E R(A) x. YE R(A)

A meta-syntactical operator can now be introduced for describing the iteration structure

primitive:

x* = Lxi ie IN

where xi= x.xi-1, xi = x and xO = 1. R*(A) is the notation for R(A) enriched with iteration

constructs.

3.1.2 Object types

In M.E.R.O.DE. Business Model Object types are in a first approach, by definition, elements

of 1lA) x R*(A), which is also denoted by <1lA). R*(A)>. (In fact later on an extra condition

will be imposed on elements of <1lA). R*(A)> in order to ensure liveness in the sense that

Object types that only exist at one point in time are avoided.) It is important to notice that

a Business Object type is more than just the set of Business Event types to which the

Object type participates: it also is a structured expression involving the Business Event

types and the algebraic operators defined in the previous section.

The formal definition is the following :

- 6 -

Definition 1

A Object Type is a pair <a,e> of <~A). R*(A)> such that

a ~A. e e <il.A). R*(A)>. e * 0 and <p(e) ~ a

Two selectors SA and SR are defined to project the Object Type respectively on its alphabet

and object expression: SA<a.e> =a and SR<a.e> = e

In a natural way, operators on Object types can be introduced, similarly to those on object

expressions and having the same properties :

<a,e> + <a' ,e'> = <a u a'. e + e'>

<a,e> . <a' ,e'> = <a u a'. e.e'>

<a,e>* = 1: <a.e>i = <a.e*> i E IN

This implies that + is commutative. associative and idempotent on <~A). R*(A)>. The

neutral for choice is <0,0>. The sequence is associative, left and right distributive through

+, has <0.1> as neutral and <A.O> as an absorbing element. Thus <~A). R*(A)>.+,. is a

idempotent semi ring as well.

Example : Library Circulation

0 M b E j c M L

e 0 B 0

c p E A event type t y R N

ENTER X

LEAVE X

ACQUIRE X

CATALOGUE X

SELL X

LOSE X X X

BORROW X X X

RENEW X X X

RETURN X X X

- 7 -

A= {enter, leave, acquire, catalogue, sell, lose, borrow, renew, return}

SR_COPY = acquire.catalogue.[borrow +renew+ return)*.[sell +lose]

SA(COPY) ={acquire, catalogue, borrow, renew, return, sell, lose}

SRMEMBER = enter.[borrow +renew+ return+ lose)* .leave

SA(MEMBER) ={enter, borrow, renew, return, lose, leave}

SRLOAN = borrow.[renew]*.[return +lose)

SA(LOAN) ={borrow, renew, return, lose}

The above expressions denote in a very compact way the lifecycle of the Object Types. In

addition the expressions can be interpreted as Business Object Type behaviour in a

straightforward way.

3.2 Object type Concurrency Behaviour

This section will introduce a formalism for describing parallel behaviour of Business Object

Types in order to obtain to the main results of this paper.

3.2.1 Object type Scenario's

Let be given an Object type P E <1lA), R*(A)>. The set of Object type Scenario's L(P) is the

set of all possible finite sequences of event types belonging to the alphabet of P that cover a

possible life of P. A possible finite sequenceS for an Object type is hence an element of A*

of finite length that consists of Event Types in SAP. the sequence . as operator, and cover a

full life of P. Scenario's are the equivalent at the Business Modeling level of abstraction of

Regular Languages based on Regular expressions. Scenarios should not be confused with

traces as used in CSP [HOARE 87).

- 8 -

Example

If P = <(a,b,c},a.b*.(a+c)> then L(P) = (a.a. a.c. a.b.a. a.b.c, a.b.b:a, ... }

The attentive reader will note that the mapping

L: <1lA), R*(A)> ~ 1{A*) : P ~ L(P)

actually is a suljection. Business Object types are however only relevant in the way that

they give rise to the same valid sequences of Business Event types. This is again an

interesting difference in discussing structures at the Business Modeling level of abstraction

as compared to the Design and Implementation Modeling layers, where both syntax and

semantics are crucial. Since Business Event types constitute the granularity of Object type

life cycles, only the syntax of the expressions is relevant.

A number of operators will now be introduced on sets of Object type Scenario's. First of all,

the concatenation operator establishes sequences of scenario's:

a.b.b "b.c.a = a.b.b.b.c.a

By means of the concatenation a formal definition of scenario's can be developed :

L(a) = {a} if a E SAP

L(l) = { 1 }

L(P + Q) = L(P) u L(Q)

L(P.Q) = L(P) . L(Q)

= { s " t I s E L(P) and t E L(Q))

- 9 -

In order to analyze Object types which don't share the same set of Event types in their

alphabet. a projection operator\ is introduced as follows:

\ : <1lA). R*(A)> x D(A) --t <1lA). R*(A)> : (P,B) --t P\B

such that

(P.Q)\B = P\B. Q\B

(P + Q)\B = P\B + Q\B

and for every a E a

<a, a> \B = <a, a> iff a E B

<a,a>\B = <a,1> otherwise.

Moreover

Example

MEMBER\SALOAN = l.[borrow +renew+ return+ 1]*.1 =[borrow+ renew+ return]*

This projection operator can also be ported to Scenario sets. Let be given an Object type P

with alphabet a and a subset B of A The projection operator \ on sets of scenarios is the

unique operator that commutes with the projection \ on <1lAl. R*(A)> in such a way that

L(P\B) = L(P)\B

It can easily be seen that

PROPERlY l

l) L(P)\B\C = L(P)\(B n C) = L(P)\C\B,

2) L(P)\B = { l } if B n SAP = 0.

Ill

- lO-

The projection operator applies equally to individual Scenario's, such that

a \B = a if a E B and a \B = 1 if a E: B

(sAt) \ B = s\B At\B

3.2.2 Object type concurrency

Concurrency of Business Object types can now be described by means of the parallel

composition operator 11. This operator on Business Object types uses Scenario sets and the

smjective nature of L. The parallel composition operator is defined as follows I :

P II Q = <a,e> II <a',e'> =<au a', e"> such that

L(P II Q) = L(e") = { s E (au a')* I s\a E L(P) and s\a' E L(Q)}

It follows from this definition that II is an associative, commutative and idempotent

operator on <1{A), R*(A)>. However. II is not distributive through the selection.

Consequently, the interpretation of the element 0 in R*(A) can be revisited: 0 gives rise to

the empty set of scenario's (which should not be confused with the do-nothing scenario 1).

More precisely

L(O) = 0

and moreover

L(P) = 0 if and only if

and

1. From the definition follows that individual stmvation of an object as component of a

system leads to system deadlock.

- 11 -

The following summarizes the elementary properties of II and the effect of projection:

PROPERIY2

For P, Q, R e <1lA). R*(A)> holds

1) SAP = SAQ => (P+Q) II R = PIIR + QIIR

2) SAP = SAQ => L(P II Q) = L(P) n L(Q)

3) <0,1> II P = P

PROPERIY3

For P, Q e <1lA). R*(A)> and B subset of A such that SAP n SAQ c B holds

L(P II Q)\B= L(P\B II Q\B)

4. OBJECT TYPE CLASSIFICATION AND LATTICE STRUCTURE

1111111

1111111

Polymorphism in M.E.R.O.DE. is expressed through the fact that Object Types share Event

Types when they participate simultaneously to these Event Types. In the Library

Circulation example, the Event type "RENEW" is shared by the Object types MEMBER,

COPY and LOAN. In addition, Event type sharing is key for the recognition of Relationship

Object types. In M.E.R.O.DE. Relationship Object types are defined to be Object types that

model the life of the shared Event types.

Example

LOAN is a relationship Object type, that relates a MEMBER Object type with a COPY

Object type. This can graphically be represented as follows:

- 12-

The cardinality M indicates that one MEMBER can have LOAN relationships with many

COPY Object types at one point in time.

This definition results in a classification of Object types in R*(A). Relationships Object

types correspond to Object types whose alphabet is a common subset of the alphabets of

the Object types participating in the Relationship type. The question rises whether this

classification is consistent with the idempotent semi-ring structure defined before.

It is known [KUICH 87, DEDENE 90] that on idempotent semi-rings there is one and

exactly only one partial ordering relation that is consistent with the semi-ring structure. On

an abstract semi-ring, the definition of the partial ordering relation is given by

x~y if and only if x+y=y

and this would be a valid definition on the set of finite regular expressions on a given

alphabet A. Similarly, the partial ordering on <~ftA), R*(A)> is given by

P ~ Q if and only if P+Q=Q

~defines a lattice structure on <P(A),R*(A)>. The supremum and infimum of two elements

(v and A) are given by the following operators :

- 13-

given <a,e>. <a',e'> E <P(A),R*(A)>,$; then

supremum {<a,e>. <a',e'>} = <a.e> v <a',e'> = <a,e> + <a',e'>

infimum {<a,e>, <a',e'>} = <a.e>" <a',e'> =<an a', en e'> 2

II

The main properties of this partial ordering are summarized in the following property

[DEDENE 90] :

PROPERIY4

Given <a,e>, <a',e'>, <a",e"> E <1tA),R*(A)>,$; then

(1) if <a,e> $; <a',e'> then

(a) <a.e>+<a",e"> $; <a',e'>+<a",e">

(b) <a,e>.<a",e"> $; <a',e'>.<a",e">

(c) <a",e">.<a,e> $; <a",e">.<a',e'>

(d) <a,e>* $; <a' ,e'>*

(2) <a,e> + <a',e'> = <0,0> ¢=> <a.e> = <a',e'> = <0.0>

(3) <a,e> $; <a,e>*

(4) <a,e> $; <a.P max( a)> with

n Pmax(a) = ( L ai )* where a= {a1 .... , an}

i=O

(5) <a,e> $; <a',e'> ¢=>a c a' and e $; e'

II

By using the projection operator, the partial order can be extended so that it copes with

Object types with different alphabets :

2. Define e n e' as following : L(e n e') = L(e) n L(e'). e n e' is regular because the set of

regular sets is closed under intersection (see [AHO 73] theorem 2.8, p. 129).

- 14-

P ::::;• Q if and only if

This defines a partial ordering relation on <~A), R*(A)> that is fully consistent with the

semi-ring structure.

Example

It can easily be checked that in the above example

LOAN ::::;• MEMBER and

LOAN ::::;• COPY

The Business interpretation of the partial ordering relation can also be seen from the

example. An Object type Pis smaller than another Object type Q if and only if Pis more

deterministic, i.e. is subject to stronger behaviour rules than Q. Object types in the bottom

of the Business Object type ordering structure are the most deterministic in the Business

Model, as the LOAN Object type in the above example.

The main properties of this partial ordering relation can be summarized as follows :

- 15-

PROPERIY5

Given <a.,e>, <a.',e'>, <a.",e"> E <1{A),R*(A)>,:5: then

(l) if <a.,e> :5:' <a.' ,e'> then

<a..e>* :5:' <a.',e'>*

(2) <a.,e> :5:' <0,0> ~ <a.,e> = <0,0>

(3) <a.,e> :5:' <a.,e>*

(4) <a.,e> $' <a.,P max:( a.)> with

n

Pmax:(a.) = ( I: a1 )* where a= {a 1 •... ,an} i=O

(5) <a.,e> :5:' <a.',e'> =>a ca.'

1111

An alternative partial ordering structure can be introduced by replacing the selection

operator with the parallel composition :

P:5:"Q~PIIQ=P

:5:" is a partial ordering on <1lA). R*(A)>. As a consequence

This partial ordering also induces a lattice structure on <1lA), R*(A)>. The infimum and

supremum of two elements is given by the following operators :

if a, bE R*(A),i ; then

supremum {P,Q} = P v Q = (P + Q) \ (SAP n SAQ)

infimum {P, Q} = P" Q = P II Q

- 16-

The minimal element in the lattice is <0.0> and the maximal is <0,1>. for V P E <.1-lA).

R*(A)> : <0.0> II P = <0.0> and <0,1> II P = P

Moreover, since every subset M of R*(A) has an infimum and a supremum. <1-l.A). R*(A)>.~~~

is a complete lattice.

It is tedious but straightfoxward to demonstrate the following result [SNOECK 92] :

THEOREM 1

V M c <.1-lA). R*(A)>:

inf(M) = II p and sup(M) =( L P) \ n SAP Pe M Pe M Pe M

Ill

The main properties of this partial ordering are summarized as follows :

PROPERIY6

Given P, Q, R E <.1-lA), R*(A)>.~~~ then

(1) ifP ~~~ Q then

(a) P II R ~~~ Q II R

(b) P.R~~~ Q.R

(c) RP ~~~ RQ

(d) p• ~II Q*

(2) p ~II p•

(3) P ~~~ <SAP,Pmax(SAP)> with

n

P max( SAP)) = ( ~ ai )"' where SAP = {a 1 •...• an} 1=0

II

- 17-

Denote by M(C) = <{C}, R*(A)> with C c A . the set of all processes with the same alphabet

C. In particular, V P E M(C): SAP = C. In this case the two partial orderings $:; and $:;"

define the same lattice structure on M(C).

In M(C),$; inf{a,b} = a 11 b and sup{a,b} = a + b

In M(C).~ inf{a,b} = a 11 b = a II b and sup{a,b} = a + b

and a + b E M(C) and a 11 b E M(C)

The maximal element in M(C).~ and in M(C).~" is <C.Pmax(C)>, the minimal is <C,O>.

The defmition of Object types and Relationship Object types as they are treated in

M.E.R.O.DE. can now be refined :

DEFINITION 2

A Business Object type that participates to Event types belonging to a Business Event

type set A is characterized by an element <a,e> E <1lAl. R*(A)> such that for each a E a

there exists an element bE a such that

<{a,b}, a.b> ~· <a,e> or <{a,b}. b.a> ~· <a,e>

This means that every Event type in the life of an Object types has either a predecessor or a

successor. This definition ensures that the Object type has a real life. The event types of

the alphabet can be partitioned in creators (Create(P)), destructors (Delete(P)) and mutators

(Mutate(P)}. The definition of Relationship Object types can also be refined as follows.

- 18 -

DEFINffiON 3

A Relationship Object type R relating Business Object types P 1.P2 •... P n is a Business

Object type that satisfies the following property

Moreover. the referential integrity rules included in the semantics of the data model

imply that for 1 ~ i ~ n

Create(R) c Create(Pi) u Mutate(Pi)

Mutate(R) c Mutate(Pi)

Delete(R) c Delete(Pi) u Mutate(P1)

Moreover if two Relationship Object types R 1 and R2 relate Business Object types

P1.P2 , ... Pn then

DEFINITION 4

An Object model :M is a set of Object types, each represented by an element of <1lA).

R*(A)>. thus :M c <1lAl. R*(A)>. A Object model is consistent if there exist at least one

instantiation of this model. An instantiation is a set of successfully terminated Object

type instances

As <1lA), R*(A)>.~" is a complete lattice. inf :M exists. If inf :M-:~= 0, then :M is consistent, i.e.

there exists at least one instantiation of M. This instantiation is more precisely a system

where there is exactly one instance of each Object type.

- 19-

A consistent Business Model is by definition a model that satisfies the definitions 1, 2, 3

and 4. The consistency demand is a strong rule that requires a lot of discipline in the

building of Object Oriented Business Models in M.E.R.O.DE .. It shows that constructing a

consistent Object Oriented Model involves more than just the specification of an Entity­

Relationship diagram with some related create, delete and update processes. Moreover, the

partial ordering structures provide a guide-line for building up the Object type behaviour

rules. In fact the Entity-Relationship diagram can first be transformed into a dependency

graph, showing relationship Object types and existence dependent object types. Next the

regular expressions for the Object types can be specified bottom up in the dependency

graph. In case a situation is encountered that violates definition 3, the Business Model is

inconsistent.

In conclusion, the above definitions show how M.E.R.O.DE. is realising the absolute duality

of data and process. Data relations imply relations on the regular expressions and vice

versa : both can not be isolated as being independent views of the Business.

5. EXAMPLES

The following example, originally taken from [WIJSEN) demonstrates the implications of the

proposed consistency rules on Object-Oriented Business Models. At first sight the following

"Business Model" for the interaction between CELLs and VIRUses appear to be correct.

VIRUS= reproduce.break-out.[invade.reproduce.break-out]• .invade.destroy

CELL= propagate.[invade.destroy]*.(propagate + (invade.break-out))

INFECTION= invade.[break-out +destroy)

- 20-

In fact. the Relationship Object type INFECTION is not smaller than CELL and VIRUS and is as

such an invalid Relationship Object type. The following adapted Model is correct and indeed

also more natural, since Object types cannot have 'infinite' life-cycles.

VIRUS = reproduce. [invade+reproduce+break-out)* .(die+destroy)

CELL= propagate.[invade+destroy)*.(propagate +break-out))

INFECTION= invade.[break-out +destroy)

This example shows also that Behaviour Business Rules should not be embedded in higher

elements in the Object type dependency graph, as has been done in the COPY Object type in

the first example of this paper. The final example is a simplified Business Model for a Hotel

Administration:

HoTEL= Open.(tempora:ry_res + cancel_tempora:ry_res + confirm_res + cancel_res +arrive+

no_arrival + create_room + destroy_room + deterrnine_roomtype + check_in +

consume+ invoice+ dun+ pay)*.close

ROOMIYPE =create_roomtype.(tempora:ry_res + cancel_tempora:ry_res + confirrn_res +

cancel_res +arrive+ no_arrival)*.destroy_roomtype

RooM= create_room.(deterrnine_roomtype +arrive+ check_in +consume+ invoice+ dun+

pay) •. destroy _room

RESERVATION= tempora:ry_res.(cancel_tempora:ry_res + confirm_res.(cancel_res + arrive +

no_arrival))

CUSTOMER= create_customer.(tempora:ry_res + cancel_tempora:ry_res + confirm_res +

cancel_res + check_in + pay + arrive + no_arrival)* .remove_ customer

GUEST = register_guest.(arrive + check_in + consume + invoice + dun + pay)• .remove_guest

CONSUMPTION = consume.invoice

- 21 -

STAY= Arrive.check_in.(consume)*.(invoice)*.(dun)*.pay_bill

The Entity Relationship Model and the dependency graph of the Business Object types are

given in the next two figures.

HOTEL ROOMTYPE RESERVATION CUSTOMER

ROOM

TA INVOICED-FOR

GUEST

CUSTOMER ROOMTYPE HOTEL

I I

I~ RESERVATION ROOM GUEST

I I

I STAY

- 22-

6. DISCUSSION

This paper starts to show some of the real power of the Object-Oriented Paradigm: the

ability to build more consistent Models to arrive at software that is correct as much as

possible as early as possible in the Software Development Life Cycle (BOEHM 81].

Elements of further research are the influence of extensions to the Entity-Relationship

Model and the added value of inheritance for Object types. Another interesting topic is the

search for implementation transformations that leave the deadlock-free property intact.

The obtained results are encouraging for Object-Oriented Systems Development. They

show that self-consistency of the specifications can go deeper than any level achieved

before in non-Object-Oriented Systems Analysis. Of course, the warning of Brooks

[BROOKS 87] saying that this is by no means a guarantee for conformity of the Business

Specifications should not be overlooked. However, if Aristotle was right there is still hope:

exactness is already there, it should only be discovered by the appropriate structured

thinking.

7. REFERENCES

[AHO 73]

[BOEHM 81]

[BROOKS 87]

Alfred. V. Aho, Jeffrey D. Ullman, "The theory of Parsing, Translation and

Compiling. Volume I : Parsing", Prentice Hall, Series in Automatic

Computation, 1972, 542 pp.

Boehm B., "Software Engineering Economics", Prentice Hall1990.

Brooks Fr. P.Jr., "No Silver Bullet", IEEE Computer April 1987

- 23-

[COAD 90)

[COHN 74]

[DEDENE90]

[DEDENE 91)

[DEDENE92)

[HOARE 87)

Coad R. & Yourdon E .. "Object Oiiented Analysis". Prentice Hall 1990.

Cohn P.M .. "Algebra", John Wiley & Sons 1974

Dedene G .. "On the mathematical foundations of an object-oliented

Business modelling approach", L.I.R.I.S. K.U.Leuven research note 1990.

Dedene G.. "Productive Application Development using an Object­

Oriented Business Modeling Approach". Keynote lecture for 2th

International Conference on Repository and AD/Cycle. Chicago, October

1991.

Dedene G., "A practical Approach to consistent Object-Oliented Business

Modelling", in Hablias H. (ed.). Proceedings of the 5th international

conference on Putting into practice Methods and Tools for Information

System Design, 23-25 Sept. Nantes (France). 1992

Hoare, C.A.R., Hayes I.J., Jifeng H., Morgan C.C., Roscoe. A.W., Sanders

J.W., Sorensen I. H .. Spivey J.M .. Suflin B.A.: Laws of Programming,

Comm. of the A.C.M .. 30(8). 1987.

[JACKSON 83] Jackson M., "System Development". Prentice-Hall1983.

[KUICH 86) Kuich. W .. Salomaa. A. "Semilings. automata. languages", Splinger

Berlin. 1986.

(RUMBAUGH) Rumbaugh J. et al., "Object oliented Modeling and Design", Prentice Hall,

Englewood Cliffs. N.J. 1991

(SHRIDAR 85) K.T. Shlidar and C.A.R. Hoare : JSD expressed in CSP, Technical

Monograph PRG-51, Oxford University Computing Laboratory, July

1985.

- 24-

[SNOECK 91]

[SNOECK 92]

Snoeck M., "Specificatie van een bedrijfsmodel uitgaande van een object-

gerichte entiteiten-relatie benadering en transformatie naar

bedrijfsgerichte uitvoerbare omgevingen", K.U.Leuven Department of

Applied Economic Sciences, Research paper 9114, 1991

Snoeck M .. 'Volgordeconflicten in M.E.R.O.DE.", L.I.R.I.S. K.U.Leuven,

Department of Applied Economic Sciences, research paper 1992, in

preparation.

[VERHELST 92] Verhelst M., "Objectgerichte Systeemontwikkeling: een praktische

aanpak met JSD en M.E.R.O.DE.", Kluwer. Deventer, 1992, 334 p. (an

English version from the same author is to be published).

[WIJSEN 91] Wijsen, J., Gegevensopvraag binnen de Object-Georienteerde Stelling,

intern rapport, K.U.Leuven, D.T.E.W., 1991.

[ZACHMAN 87] Zachman J .A, A framework for Information Architecture, IBM Syst.

Journ. vol 26 n" 3 1987.

- 25-