Event Concurrency Analysis in Object-Oriented Models by · Event Concurrency Analysis in...
Transcript of Event Concurrency Analysis in Object-Oriented Models by · Event Concurrency Analysis in...
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: [email protected]
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-