The object-event table: A useful technique in object-oriented domain modelling

Transcription

1 The object-event table: A useful technique in object-oriented domain modelling M. Snoeck Abstract This paper proposes the object-event table as a useful technique for modelling interaction between domain object types. The technique is based on an object interaction concept where objects interact by being jointly involved in events rather than by sending messages to each other. This way of modelling object interaction is very well suited for conceptual modelling and it can easily be transformed to message passing schemes at design time. A significant advantage of this specification technique is that it can be modelled by means of an objectevent table and, more important, that inspecting this object-event table allows verifying important aspects of the internal consistency of the specifications. This paper also presents the formal definition of the object-event table, of object behaviour, of object interaction and of the all the presented verification rules 1. Introduction The technique of the object-event table proposed in this paper has to be seen in the context of domain modelling. Domain modelling is an essential requirement capturing activity, prior to information systems modelling. It captures the essence of the domain, that is, all domain requirements that have to be respected by a potential information system. For example, a domain model for a pharmacy will specify that some medicines can be sold freely, while others can only be delivered on doctor's order. A Dutch pharmacy model has to specify that the pharmacist is allowed the replace the medicine on the prescription by a cheaper equivalent. A Belgian pharmacy model should however specify that such a replacement is not allowed. A domain model contains all such "business rules" that govern the domain and is a good starting point for information systems development since it already contains an essential part of system requirements. Domain models are also useful in other contexts such as, for example, in the context of business process re-engineering. In the case of object-oriented conceptual modelling, domain requirements will be formulated in terms of business or enterprise object types, associations between these object types and the behaviour of business object types. The definition of desired object behaviour is an essential part in the specification process. On the one hand, we have to consider the behaviour of individual objects. This type of behaviour will be specified as methods and statecharts for object classes. On the other hand, objects have to collaborate and interact. Typical techniques for modelling behavioural aspects are interaction diagrams or sequence charts, collaboration diagrams, and activity diagrams. These techniques are all based on the concept of message passing as interaction mechanism between objects. Our argument is however, that in the context of domain modelling, message passing is too much implementation biased. We propose an alternative communication paradigm, namely, object interaction by means of joint involvement in business events. This type of communication is modelled with an object-event table. Let us illustrate this with an example. In the context of a library, we can identify (among others) the two domain object types MEMBER and COPY. A relevant event type in this domain is the borrowing of a copy. This event affects both domain object types: it modifies the state of the copy and it modifies the state of the member. When using message passing as interaction mechanism, two scenarios are possible. Either the member sends a message to the copy, or the copy sends a message to the member (see Fig. 1). If in addition a LOAN is recognised as a domain object type as well, then the borrow-event will create loan objects. In this case, three objects 1

2 are simultaneously involved in one event and should be notified of the occurrence of the borrowevent. With message passing, this leads to 9 possible interaction scenarios as depicted in Fig. 2. If four objects have to synchronise on the occurrence of one event, we already have 48 possible message passing scenarios. Of course, from a systems design perspective, some scenarios can be considered more adequate than others. Domain modelling should however never be concerned with design aspects and business domain modellers should not be burdened with design considerations. COPY borrow MEMBER COPY borrow MEMBER Fig. 1. Two possible scenarios for borrowing a copy C M L C L M M C L M L C L C M L M C C M L M L C L M C Fig. 2. Possible scenarios when three objects are involved in a single event The alternative that we propose in this paper is to model only the essence of the interaction: some objects are affected by events, others are not. How exactly objects are notified of the occurrence of an event is a matter of implementation. When using object-oriented technology this will be done with messages, but when using more traditional technology, procedure calls can do as well. To model which objects are involved in which event types, we can use a very simple technique: the object-event table. Fig. 3. shows a possible object-event table for the library example. The table clearly shows that a cr_member event affects only the member object, that the acquisition of a copy only affects a copy, but that the borrowing and return of a copy affect a member, a copy and a loan object. MEMBER COPY LOAN cr_member acquire borrow return Fig. 3. An object-event table for the library As explained in the following sections, the object-event table allows much more than simply indicating which types of objects are affected by which types of events. It is in fact a powerful tool for checking important aspects of the internal consistency and coherence of specifications. The next section will elaborate on the notion of business events and how it integrates well into the object- 2

3 oriented paradigm. Section 3 will then define the object-event table in more detail and give some basic consistency checking rules. Section 4 will then proceed to some more advanced capabilities of the object-event table. Finally, in section 5 we present a case study. Section 6 concludes with a conclusions. 2. Business Events 2.1 Definition The use of the object-event table to model object interaction implies that the notion of event plays a central role. As we are concerned with domain modelling, we will only consider business events and, for example, not consider information systems events like keyboard and mouse actions. More in particular, candidate business events should satisfy the following properties: A business event of a certain type occurs or is recognised at one point in time; its possible duration can be abstracted. A good example is the event pay. When we include pay in the list of relevant event types, it refers to the moment at which the activity of paying terminates. For example, consider a payment in cash. Such an activity will last a certain time: the customer has to take his/her wallet, count money, but the actual duration of all this is of no interest for the model. In an enterprise modelling perspective, the pay event occurs at the moment the activity of paying terminates. A counterexample is the activity of owning a property: you cannot make abstraction of the duration of the ownership. In fact at least two event types are involved in an ownership: buy and sell that indicate the start and the end of the ownership. Being in a state (like owning 1 million) is never an event. It is the change of state that is an event (like going from owning 1 million to owning 2 millions). A business event matches something that happens in the real world within the universe of discourse; it is not just an information system event. For example release mouse button or push mouse button is not acceptable in an enterprise model. Events that happen within the universe of discourse remain relevant for the enterprise model, even if there is no information system. A business event is not decomposable, it cannot be split into sub-events. Consider for example an association where members can register and are allowed to pay their membership fee later. Some members however announce themselves as member by directly paying their membership fee. In that case, become a member is an event type and so is pay membership fee. But become a member by paying membership fee is not: it is a combination of the previously mentioned event types. The grouping of event types to transactions or tasks can be dealt with in the information system or workflow-modelling phase. Business event types should preferably be designated with the infinitive of a verb rather than with a conjugated tense: pay but not pays. In this paper they will be written in italics. 2.2 Modelling object behaviour with events Although in the object-oriented paradigm only objects play the central role, putting events forward is not in contradiction with current object-oriented practice. Indeed, most object-oriented methods use a state and transition-based formalism to specify behaviour such as finite state machines or statecharts [2, 4, 6, 9, 11, 12]. In such formalisms the different states of an object are taken as starting point and the transitions describe how objects can go from one state to another. The triggers of these transitions are events. It is however also possible to take the events as starting point to model the behaviour of an object. In general, events are not allowed to occur in a random order during the life cycle of an 3

4 object. For example, a book can not be returned if it has not previously been borrowed. In order to specify the sequence constraints an object imposes on events, the object is equipped with a description of allowed sequences of event types. The latter are described by means of a regular expression, or a Jackson Structure diagram [8]. From a mathematical point of view however, both techniques are equivalent with Finite State Machines [5],. Fig. 4. depicts how sequence, choice (exclusive and exhaustive selection) and iteration are modelled in each of these techniques. In [13] algorithms are given for transformation between these three representations. EVENT BASED FORMALISMS STATE BASED FORMALISMS Regular expression JSD diagram Finite State Machine A is a sequence of first B, then C and then D. A = B.C.D B A C D B C D A is a choice between B, C and D. A = B + C + D B A C D B C D OR B,C, D A is an iteration of B. A = B* A B * B A is do-nothing A = 1 A _ & Fig. 4. Natural Language, Regular Expression, JSD and Finite State Machine specification for sequence, selection and iteration The conclusion is that events combine well with the state-based formalisms used for modelling the behaviour of an individual object type. No matter whether states or events are taken as starting point, in both cases you end up with a state based formalism where events are triggering the transitions from one state to an other. In the remainder of this paper we will use regular expressions to specify object behaviour. In the context of domain modelling, this technique is most of time sufficiently expressive. For more complex behaviour, more elaborated techniques can be used such as Harel Statecharts [6]. For the library example, the following regular expressions are given: COPY : acquire.classify.(borrow+renew+return)*.(lose + remove_copy) MEMBER: enter.(borrow+renew+return + lose)*.leave LOAN: borrow.(renew*).(return + lose) 4

5 2.3 Modelling interaction with events In order to model object interaction adequately in a conceptual model, we propose to use the formalism of synchronous participation to events. For the library example this means that the member, the loan, and the copy object types are provided with a method called ' borrow' that describes the effect of the borrow-event on the object. It is agreed that objects have to synchronise on common events. This means that when a borrow-event occurs and is accepted, all three methods will be executed simultaneously 1, provided each involved object is in a state where the borrow-event is acceptable. This way of communication is similar to communication as defined in the process algebras CSP [7] and ACP [1]. Message passing is more similar to CCS [10]. 3. The object-event table: a simple modelling technique Because of the concept of communication by means of common events, an enterprise model is not only composed of enterprise objects, but also of business events. Let us assume that, for the library example, relevant domain object types are MEMBER, COPY and LOAN. As relevant business event types we identify enter (a new member joins the library), leave (a member leaves the library), acquire (a new copy is acquired), classify (a copy is classified), borrow (a copy is borrowed by a member), renew (a loan is renewed), return (a copy is returned to the library), remove_copy (a copy is removed from the library), and lose (a copy is lost rather than being returned). For each of these business events, we can identify the domain objects that are involved in the event. In addition, it is also possible to indicate the nature of the involvement. For example, when a copy is borrowed (borrow), there is one copy that is involved, one member and one loan. The borrow-event will modify the state of the copy, modify the state of the member and create the loan. This can easily be documented by means of the object-event table by putting C' s, M' s and E' s for indicating respectively the creation, modification and end of an object. For the library example this results in the object-event table of Fig. 5. MEMBER COPY LOAN enter C leave E acquire C classify M borrow M M C renew M M M return M M E remove_copy E lose M E E Fig. 5. OET for the library example 1 There exist various mechanisms for the implementation of such synchronous execution of methods. The discussion of these is however beyond the scope of this paper. 5

6 3.1 Formal definition of the object-event table Let A be the universe of relevant event types and O be the universe of relevant domain object types for the given domain. Then the object-event table is simply a table with one row per identified business event type and one column per identified enterprise object type and which can be defined as follows: T O A {' ', C, M, E} such that P O, a A : (P,a,' ' ) T or (P,a,C) T or (P,a,M) T or (P,a,E) T Each cell in the table indicates whether an object type is involved in an event type or not. In this way, a subset of event types is assigned to each object type. This subset is called the alphabet of an object type P and is denoted S A P. It contains all the event types that are relevant for that particular object type. In addition the alphabet of P is partitioned in three mutually disjoint sets: c(p), m(p) and e(p) with c(p) = {The set of event types that create an occurrence of type P} S A P m(p) = {The set of event types that modify an occurrence of type P} S A P e(p)= {The set of event types that end an occurrence of type P} S A P Formally P O: c(p) = {a A (P,a,' C' ) T} m(p) = {a A (P,a,' M' ) T} e(p)= {a A (P,a,' E' ) T} S A P = c(p) m(p) e(p) For the given library example this means that A ={enter, leave, acquire, classify, borrow, renew, return, remove_copy, lose} O = {MEMBER, COPY, LOAN} The partitions of the alphabets of the object types COPY, MEMBER and LOAN are as follows: S A COPY = {acquire, classify, borrow, renew, return, remove_copy, lose} with c(copy) = {acquire} m(copy) = {classify, borrow, renew, return} e(copy) = {remove_copy, lose} S A MEMBER = {enter, borrow, renew, return, lose, leave} with c(member) = {enter} m(member) = {borrow, renew, return, lose} e(member) = {leave} S A LOAN = {borrow, renew, return, lose} with c(loan) = {borrow} m(loan) = {renew} e(loan) = {return, lose} 6

7 3.2 Simple consistency checks with the OET The tabular form allows for some easy integrity checks. The relevant life of a domain object type has a certain duration that can be delimited by two events: one event when the object enters the domain of interest and one event when the object leaves the domain of interest. As a result, for each object type there should be at least one creating and one ending event type. So, per column (object type), there is at least one row (event type) with a C and at least one row with an E. The effect of an event on an object is always unique: an event either creates, modifies or ends an object. If there are two or more possible effects, these should be modelled by means of different events. Each identified event type must be relevant for at least one object type: so on each row there is at least one column with a C, an M or an E. Formally: c(p), e(p) c(p), m(p), e(p) are pairwise disjoint a A: P O: a S A P or equivalently: {S A P P O } = A To go one step further in consistency checking we have to check the integrity between what is specified in the object-event table and what is specified in the individual behaviour definitions of object types. Indeed, the object-event table defines the alphabet of an object and partitions this alphabet in creating, modifying and ending event types. These elements have an influence on what can be considered a valid behaviour definition of an object type. In the first place, there is the alphabet rule. Alphabet rule The JSD-diagram, regular expression or finite state machine that defines the behaviour of an object type P must contain all and only the event types for which there is a C, M or E in the column of P in the OET. As said before, the partitioning of the alphabet in creating, modifying and ending event types imposes a default lifecycle. This default lifecycle must be respected by the sequence constraint definition. Default lifecycle rule The events in c(p), m(p) and e(p) must appear as creating event types, modifying event types or ending event types respectively in the sequence restrictions of the object type P. This means that the sequence constraints imposed by the JSD-diagram, regular expression or finite state machine must not violate the default lifecycle of create, modify, and end. 3.3 Formal definition of object behaviour In order to define these consistency-checking rules more formally, we need to elaborate on the formal definition of object type behaviour. The finite state machine or regular expression of an object type defines a set of valid scenarios over its alphabet. A scenario is a sequence of event types, e.g. borrow^renew^return. If iteration operators are used in the life cycle expression, the number of valid scenarios for an object type is infinite. Assume, for example, that the life-cycle specification of a LOAN object is as follows: LOAN = borrow.(renew*).(return + lose) 7

8 That is, a loan is created when a copy is borrowed. The loan can possibly be renewed an arbitrary number of times. Finally, the loan comes to an end when the copy is returned to the library or when it is registered as lost. The set of valid scenarios for LOAN is: {borrow^return, borrow^lose, borrow^renew^return, borrow^renew^lose, borrow^renew^renew^return, borrow^renew^renew^lose, } The set of valid scenarios defined by an object type is called the language of the object type. The partitioning of the alphabet in creating, modifying and ending event types also implies some default life cycle expression and an associated set of scenarios. The default life cycle expression is a choice between the creating event types, followed by an iterated choice of modifying event types, and finally followed by a choice between ending the event types. The regular expression that defines this default lifecycle can be written as: (Σ c(p)).(σ m(p))*.(σ e(p)) 2. The behaviour definition of an object type can put additional constraints on this default life cycle but should never violate this default lifecycle. Putting additional constraints means that scenarios are removed from the language of the object type. In other words, the language defined by the regular expression of the object type must be a subset of the language defined by the default life cycle. Formal Definitions Let A be the universe of event types. R*(A) is the set of all regular expressions over A where e is a regular expression over A if and only if (a) e = 1 or (b) a A: e = a or (c) e', e" R(A) such that e = e' + e" or e = e'.e" or e = (e' )* An object type P O is a tuple <α,e> <P(A), R*(A)>. α is the alphabet, which we denote by S A P and e is the behaviour definition denoted by S R P. Each regular expression defines a set of scenarios, called the language (1) A* is the set of scenario' s over A. A* is defined by (a) 1 A* (b) a A: a A* (c) Let s, t A*, then s^t A* (d) s A*: 1^s = s = s^1 (2) The regular language of a regular expression is a subset of A* defined by L(1) = {1} a Α : L(a) = {a} e, e' R*(A): L(e + e' ) = L(e) L(e' ), L(e.e' ) = L(e).L(e' ), L(e*) = L(e)* where L(e).L(e' ) = { s^t s L(e) and t L(e' )} and L(e)* = {1} L(e) L(e).L(e) L(e).L(e).L(e)... The alphabet rule and the default life cycle rule can then be defined as follows: 2 If c(p) = {c 1, c 2,, c n } then Σ c(p) = c 1 + c c n. Similary for Σ m(p) and Σ e(p). 8

9 Alphabet rule ϕ(s R P) = S A P. where ϕ : R*(A) P(A): e ϕ(e) such that ϕ(1) = Ø ϕ(a) = {a} ϕ(e + e' ) = ϕ(e) ϕ(e' ) ϕ(e. e' ) = ϕ(e) ϕ(e' ) Default lifecycle rule P O : L(S R P) L (Σ c(p).(σ m(p))*.σ e(p)) 3.4 Modelling object interaction Application domains are but rarely composed of a single object. Most domains are described in terms of multiple enterprise objects that somehow interact with each other. As a result, the behaviour of the domain as a whole is a composition of the behaviour of the individual enterprise objects. Modellers should be able to validate this global enterprise model behaviour against end-user specifications. Therefore, both end-users and analysts must be able to truly understand the effects of object interaction. This section explains how common events define the general behaviour of a system composed of many objects. These objects run concurrently and have to synchronise on events in which they jointly participate. This means that only those scenarios will be accepted where all involved objects agree on the sequence of events. In order to achieve this synchronisation, events are broadcasted to the whole set of enterprise objects. When an event is broadcasted to the enterprise model, each involved object checks his state and whether the event is allowed to occur. If all involved objects agree, in each object, the transition associated with the event fires. If one of the involved objects disagrees, the event is rejected. In order to be able to calculate the behaviour of a system composed of many concurrent objects, a parallel-operator can be defined. This operator expresses the fact that when two objects run concurrently, only those scenarios are valid where both objects agree on the sequence of common events. To define this operator in a formal way, we first need to define a projection /B on scenarios and languages that will be used to isolate the common events: Formal definition of the projection: Let B A. Then 1\B = 1 a A : (a\b = 1 a B) and (a\b = a a B) s, t A* : (s ^ t)\b = s\b ^ t\b, L A* : L /B = {s/b s L} Formal definition of the parallel operator: Let P, Q be object types The alphabet of P Q is the union of the alphabets: S A (P Q) = S A P S A Q and the behaviour of P Q is defined by an expression e" R*(A) such that L(e") = { s (S A P S A Q)* s\s A P L(P) and s\s A Q L(Q)} 9

10 We illustrate the effect of parallel composition by means of a small example. Suppose we have the following definition for the object types COPY and LOAN: COPY = acquire.classify.(borrow + renew + return)*.(remove_copy + lose) LOAN = borrow.(renew)*.(return + lose) Assume that the object relationship graph specifies that a copy can have at most one loan at one point in time. Hence, during its life a copy will participate zero, one or more times to a loan, which is an iteration of loan. To find out what the set of accepted scenarios would be we thus must calculate the parallel composition of COPY and the iteration of LOAN. The behaviour of a copy that can be on loan zero, one or more times consecutively is: COPY (LOAN)* = COPY [borrow.(renew)*.(return + lose)]* = acquire.classify.[borrow.(renew)*.return]*.[remove_copy + borrow.(renew)*.lose] Fig. 6. depicts the same expression calculated by means of finite state machines. It is worth noticing that when finite state machines are used for behaviour specification, the behaviour of a composite system can be calculated automatically. Calculting this composite behaviour also allows to check it for undesirable behaviour such as e.g. deadlock [5]. Deriving the behaviour of a composite system where message passing is the paradigm for object interaction, is much more difficult, if not impossible. FSM for COPY acquire classify borrow, renew, return removecopy lose FSM for LOAN FSM for LOAN* borrow, fetch return, lose borrow renew renew return, lose FSM for COPY LOAN* acquire classify removecopy borrow, return lose renew Fig. 6. Calculating the behaviour of a copy on loan. 10

11 4. Advanced consistency checking with the object-event table 4.1 Existence dependency More advanced consistency rules are based on the comparison of the object-event table with the structural (static) relationships that exist between object types. More in particular, the notion of existence dependency plays an important role. It is defined as follows: Definition Let P and Q be object types. P is existence dependent on Q (notation: P Q) if and only if the life of each occurrence p of type P is embedded in the life of one single and always the same occurrence q of type Q. p is called the dependent object, (P is the dependent object type) and is existence dependent on q, called the master object (Q is the master object type). A more informal way of defining existence dependency is as follows: If each object of a class P always is associated with minimum one, maximum one and always the same occurrence of class Q, then P is existence dependent on Q. The result is that the life of the existence dependent object can not start before the life of its master. Similarly, the life of an existence dependent object ends at the latest at the same time than the life of its master ends. This is illustrated in Fig. 7. Time Life span of a master Possibilities for life span of an existence dependent object = Start of life = End of life Fig. 7. Life span of master and dependent object Example The life span of a loan of a copy is always embedded in the life span of the copy that is on loan. Indeed, we cannot have a loan for a copy if the copy doesn t exist. And the lifecycle of the copy cannot end as long as the lifecycle of the loan is not ended. In addition, a loan always refers to one and the same copy for the whole time of its existence. Hence the object type LOAN is existence dependent on the object type COPY. The concept of existence dependency is very similar to the concept of weak entity as defined by P. Chen [3] and to the concept of composition as defined in UML [11]. The concept of existence dependency is presented in full detail in [14]. The same paper also demonstrates that any data model can be reformulated in terms of existence dependency such that object types are related through the existence dependency relationship only. The general idea is that relationships between objects either express existence dependency or they do not. In the latter case, the relationship is in itself considered as an object type that is existence dependent on the object types it relates. For example, the relationship between an ORDER and its ORDER LINEs expresses existence dependency: the order lines depend for their existence on the order they are part of. The relationship ' assigned_to' between a DEPARTMENT and an EMPLOYEE does however not express existence dependency: both the employee 11

12 and the department can exist independently of each other. In this case, the assignment of the employee to the department is considered as an object type ASSIGNMENT, which is existence dependent on both EMPLOYEE and DEPARTMENT. 4.2 Advanced consistency checking rules In what follows we will demonstrate that the concept of existence dependency strongly interacts with the object-event table. The first consideration is that is that a master object type is always involved in all event types in which one of its dependent object types participates. This can be explained as follows. When an existence dependent object is involved in an event, its master objects are automatically involved in this event as well. For example, a state change of a loan, e.g. because of the return of the copy, automatically implies a state change of the related copy and member: the copy is back on shelf and the member has one copy less in loan. By including the alphabet of the dependent object type in the alphabet of the master object type, all possible places for information gathering and constraint definition are identified. For example, the borrow method of the class MEMBER is the right place to update the number of copies a member has in loan and to check a rule such as a member can have at most 5 copies in loan at the same time. The borrow method of the class COPY is the right place to count the number of times a copy has been borrowed. At implementation time, methods that are empty because no relevant business rule was identified, can be removed to increase efficiency. In addition, by including the event types of the dependent object types in the alphabet of the master, sequence constraints that concern event types of different dependent object types can be specified as part of the behaviour of the master. For example, let us assume a library where books can be reserved. This can be modelled by means of an additional object type RESERVATION that is existence dependent on COPY and MEMBER. Sequence constraints such as a reservation can only be made for copies that are on loan relate to more than one object type, namely to LOAN and RESERVATION. They can be specified as part of the behaviour of a common master of these object types, COPY in the given example. Propagation rule If P is existence dependent on Q, the alphabet of P must be a subset of the alphabet of Q. Formally P Q S A P S A Q. The next consideration is that the life cycle of a dependent object and its master object are strongly interrelated. Indeed, a dependent object type cannot be created before its master exists nor can it exist after its master has been ended. Creating an existence dependent object means that either the master is created at the same time (e.g. creating the first order line creates the order) or that the master object type already exists (e.g. opening an account for an existing customer). In the latter case, the creation of a dependent object type modifies the state of the master. Since the alphabet of the dependent object type is a subset of the alphabet of the master object type, this means that the set of creating event types of the dependent object type is a subset of the creating and modifying event types of the master. Modifying a dependent object type always modifies the state of the master. Finally, ending a dependent object type also modifies the state of the master. If the last dependent object type is ended, then the master can be ended at the same time or later. We call these constraints the type of involvement rule. Type of involvement rule If in the column of an existence dependent object type a row contains a C then on the same row a C or M must appear in the column of each master object type. If in the column of an existence dependent object type a row contains an M then on the same row an M must appear in the column of each master object type. 12

13 If in the column of an existence dependent object type a row contains an E then on the same row an E or M must appear in the column of each master object type. Formally P Q c(p) c(q) m(q) m(p) m(q) e(p) e(q) m(q) Notice that the type of involvement rule subsumes the propagation rule. As said above, when a relationship between object types does not express existence dependency, it is considered as an object type on its own, existence dependent of the object types it relates. As a consequence of the propagation rule, the alphabet of such a relationship object type always is a subset of the alphabet of the object types it relates, because it is existence dependent on these object types. Moreover, when two (or more) object types share a number of common event types, we can assume that this indicates the existence of a relationship between these object types. We can thus require that when object types share some common events, these event types be modelled as the alphabet of a relationship between these object types. Sometimes, the shared event types can be spread across more than one existence dependent object type, such as in the case of RESERVATION and LOAN. We call this rule the relationship rule. 3 Relationship rule When two object types share two or more event types, the common event types must be in the alphabet of one or more common existence dependent object types (relationship object types). Formally P, Q M : #(S A P S A Q) 2 and (S A P S A Q or S A Q S A P) R 1, R 2,... R n M: i {1,...,n}: R i P,Q and S A R 1... S A R n = S A P S A Q Finally, the most advanced form of consistency checking is the comparison of the lifecycle expression of a dependent object type with the life cycle expression of its master object type. As already said, a dependent object cannot exist without its master. As a result, a dependent object will always exist in parallel with its master object type. As in addition the alphabet of the dependent object type is a subset of the alphabet of the master object type, the dependent and the master object have to synchronise on all events in the alphabet of the dependent. According to the definition of the -operator, both object types will run concurrently and such a system will only accept sequences of events that satisfy the sequence constraints of both P and Q. As a result, any scenario of an existence dependent object that is not acceptable from the point of view of its parent object will always be rejected. It can thus be removed from the life cycle definition of the existence dependent object type. It thus seems sensible to demand that a parent object type Q can accept all scenarios of its existence dependent object type P. We say that the existence dependent object type P must have more stringent sequence constraints than or must be more deterministic than the parent object type Q. The difference between the general case and the case in which P is more deterministic than Q is depicted in Fig. 8. As a result, when an object type has more than one parent object type, the set of scenarios accepted by the existence dependent object type is a subset of the intersection of the sets of scenarios accepted by all its parent object types. In this sense, the existence dependent object type acts as a contract between the parent object types: for the common event types it defines the set of scenarios that will be accepted by all participants. For the library example LOAN is a contract between MEMBER and COPY (see Fig. 9.). 3 For a more elaborated motivation and explanation of this rule and for the illustration with examples, we refer to [13]. 13

14 General case Scenarios accepted by Q Scenarios accepted by P Scenarios rejected by P Scenarios accepted by P Q Scenarios rejected by Q P existence dependent of Q and satisfying the restriction rule Scenarios accepted by Q Scenarios accepted by P Scenarios rejected by P Scenarios accepted by P Q Fig. 8. Restriction rule for existence dependent object types Scenarios accepted by MEMBER Scenarios accepted by BOOK Contract Area Scenarios accepted by the contract LOAN Fig. 9. LOAN as a contract between MEMBER and COPY 14

15 How can this relationship more deterministic than be checked? The basic idea is to project the sequence constraints of the master object type on the set of common event types (that is, the alphabet of the existence dependent object type) and see if these sequence constraints are less stringent than those of the existence dependent object type Definition An object type P is more deterministic than an object type Q (which is written as P Q) if the alphabet of P is a subset of the alphabet of Q and if the scenarios of P are all acceptable for Q. Formal definition of more deterministic than P Q if and only if S A P S A Q and L(P) L( Q\S A P) Example With the sequence constraints as defined in section 2.2 and LOAN existence dependent of COPY and MEMBER, we have: COPY = acquire.classify.(borrow + renew + return)*.(sell + lose) MEMBER = enter.(borrow + renew + return + lose)*.leave LOAN = borrow.(renew)*.(return + lose) The alphabet of LOAN is a subset of the alphabet of COPY. In order to compare the scenarios defined by COPY and LOAN, the expression of COPY is projected on the alphabet of LOAN: COPY\S A LOAN = acquire.classify.(borrow + renew + return)*.(sell + lose)\s A LOAN = (borrow + renew + return)*.(1 + lose) Apparently, the scenarios defined by LOAN are all acceptable for COPY. As a result, LOAN COPY: LOAN is more deterministic than COPY. The same reasoning applies to MEMBER: MEMBER\S A LOAN = enter.(borrow + renew + return + lose)*.leave\s A LOAN = (borrow + renew + return + lose)* Which is also less deterministic than LOAN and thus LOAN MEMBER. The full definition of the process algebra associated with these concepts can be found in [5, 13]. 5. Case study: An employment agency This section presents a small case-study to illustrate the use of the object-event table and the benefits one obtains by checking all the consistency checking rules. Companies can offer vacant jobs through an Employment Agency. Persons can apply for vacant jobs and the Agency will match candidates against available jobs. The Employment Agency is responsible for selecting candidates and for managing all personal data of employees of the contracted companies. Fig. 10 represents the object-relationship schema. The object type VACANCY denotes a particular position in a company that can be either vacant or occupied. A job is the actual employment of a person for a vacancy. As a result, JOB is a one to one optional relation between PERSON and VACANCY. As a person can apply for several vacancies at a time and several persons can apply for the same vacancy, an APPLICATION is a many to many association between PERSON and VACANCY. Notice that with this schema, a person cannot combine several part-time jobs as JOB is a 1-to-1 15

16 relationship. As both JOB and APPLICATION are associations that do not express existence dependency, they are object types. PERSON VACANCY 0..1 * 0..1 * JOB APPLICATION Fig. 10. EDG for the employment agency Fig. 11 represents the object-event table. Notice how each object type has at least one creating and one ending event type and how each event type has a single effect on at least one object type. The sequence restrictions are as follows: VACANCY PERSON JOB APPLICATION cr_vacancy C e_vacancy E offer M apply M M C refuse M M E hire M M C E fire M M E retire M E E cr_person C Fig. 11. OET for the employment agency S R VACANCY = cr_vacancy.[offer. (apply + refuse)*.hire.(fire + retire)]*.e_vacancy PERSON, JOB, and APPLICATION have a default life-cycle: S R PERSON = cr_person.(apply +refuse + hire + fire)*.retire S R JOB = hire.(fire + retire) S R APPLICATION = apply.(refuse + hire) These sequence constraints satisfy the alphabet rule: each event type that is marked for an object type in the object-event table also appears in the behaviour definition of the object type. Also the default life cycle rule is satisfied: creating event types appear as creators in the behaviour definition, modifying event types appear as modifiers and ending event type appear as final events. Also the propagation rule, the type of involvement rule and the realtionship rule are satisfied. Indeed, JOB and APPLICATION are existence dependent on both PERSON and VACANCY. Their alphabets are subset of the alphabets of PERSON and VACANCY and the type of involvement is respected as well. Finally, we see that the set of common event types of PERSON and VACANCY is covered by the alphabet of the relationship object types JOB and APPLICATION. The behavour definition of VACANCY means that when a vacancy is offered, people can apply and be refused until someone is hired. When this person retires or is fired, the vacancy is offered again. This sequence constraints definition for VACANCY does however not satisfy the restriction rule. Indeed 16

17 S R VACANCY\ S A APPLICATION = (apply + refuse)*.hire which is NOT less deterministic than S R APPLICATION Indeed, the specification of vacancy implies that for each offer, eventually someone is hired. It must however be possible that nobody is hired for a vacancy. The new sequence constraints for VACANCY are as follows: S R VACANCY = cr_vacancy.(offer. (apply + refuse)*. [1 + (hire.(fire + retire)] )*.e_vacancy Now the specifications satisfy the restriction rule for APPLICATION and PERSON, for APPLICATION and VACANCY and for VACANCY and JOB. Namely, S R APPLICATION S R PERSON \ S A APPLICATION = 1.(apply + refuse + hire + 1)*.1 = (apply + refuse + hire)* S R VACANCY \ S A APPLICATION = 1.(1.(apply + refuse)*.[1 + hire.(1 + 1))*.1 = ((apply + refuse)*.(1 + hire))* S R JOB S R VACANCY\ S A JOB = 1.(1.( hire + fire + retire)*)*.1 = (hire + fire + retire)* However, PERSON and JOB do not satisfy the restriction rule: S R PERSON \ S A JOB = 1.( hire + fire)*.retire = (hire + fire)*.retire By including the event type retire in the object type JOB, it is required that a person always be employed at the moment (s)he retires. This does not reflect reality and thus the specification of PERSON must be adapted as follows: S R PERSON =create_person.(apply + refuse + hire + fire)*.(retire + retire_unemployed) The retire_unemployed event type must be added to the OET as well. Now all the specifications satisfy all consistency checking rules. 17

18 6. Conclusion This paper has presented a tabular technique for modelling object interaction between object types in an object-oriented conceptual model. The originality of the technique resides in the fact that it is based on the concept of joint involvement in business events as means of object interaction. The paper argues that this interaction paradigm is better fit for conceptual modelling purposes than message passing. Current interaction modelling technique are strongly based on the notion of message passing. It is not so much these specification techniques than the underlying concept that is a problem. Indeed, the concept of message passing is bound to a particular information system design and implementation technology, while in conceptual modelling we want to be independent of information system considerations and certainly from design and implementation options. The conceptual model should capture the domain knowledge independently of possible information system concerns. In addition, the concept of message passing forces the modeller to think sequentially even when sequence is not relevant. Finally, message passing is programming language concept: it assumes the realisation of a model with an object-oriented programming language. As a consequence, message passing can hardly be considered as a conceptual modelling technique: it is too much biased by implementation considerations. Additional and major advantages of the proposed technique are the simplicity of the representation and the possibilities it offers for checking the integrity of the specifications. The concisitency checking rules allow to check the integrity between the object-event table and the behaviour definitions of object types and even with the structural aspects of the object model. This type of integrity control is lacking in current object-oriented analysis and design methods. Finally, the formal definition also illustrates how this communication paradigm makes it easier to grasp the overall behaviour of a system composed of many concurrent objects. Since domain modelling is mostly done in very close collaboration with domain experts and these people are not necessarily acquainted with information modelling techniques, precise and easy-tounderstand notations for specifying and analysing the required behaviour of domain objects are more than welcome. It is of major importance that domain experts are able to understand and validate a model. In addition, behaviour and interaction modelling techniques should by no means contain design or implementation options. A domain model should be completely independent of information technology. As a final remark, it is also possible to integrate the concept of the object-event table with generalisation and specialisation as demonstrated in [13]. 7. References 1. Baeten, J.C.M., Procesalgebra, Kluwer programmatuurkunde, Booch G., Object Oriented Analysis and Design with Applications, Second Edition, Benjamin/Cummings, Redwood City, CA, Chen P.P., The Entity Relationship Approach to logical Database Design, QED information sciences, Wellesley (Mass.), Coleman D., Arnold P., Bodoff S., Dollin C., Gilchrist H., Hayes F., Jeremaes P., Object-Oriented Development, The FUSION Method, Prentice Hall, Englewood Cliffs, N.J., Dedene G., Snoeck M., Formal deadlock elimination in an object oriented conceptual schema, Data and Knowledge Engineering, Vol. 15, 1995, pp Harel David, On visual formalisms, Communications of the ACM, Volume 31, Number 5, May 1988, pp

19 7. Hoare C. A. R., Communicating Sequential Processes (Prentice-Hall International, Series in Computer Science, 1985). 8. Jackson M.A., Systems development, Prentice Hall, englewood Cliffs, N.J., Jacobson Ivar et al., Object-Oriented Software Engineering, A Use Case Driven Approach, Addison-Wesley, Milner R., A calculus of communicating systems (Springer Berlin, Lecture Notes in Computer Science, 1980). 11. Rational Software Corporation, The Unified Modeling Language, Version 1.1, 1 September 1997, Rumbaugh J., Blaha M., Premerlani W., Eddy F., Lorensen W., Object Oriented Modelling and Design, Prentice Hall International, Snoeck M., Dedene G., Verhelst M., Depuydt A.M., Object-oriented Enterprise Modelling with MERODE, University Press, Leuven, Snoeck M., Dedene G., Existence Dependency, the key to semantic integrity between structural and behavioural aspects of object types, IEEE Transactions on Software Engineering, Vol. 24 No 4, April 1998, pp