Tutorial presented at TOOLS EUROPE 1995

(1)

O

BJECT

O

RIENTED

A

NALYSIS ACCORDING TO

M.E.R.O.DE.

Tutorial presented at TOOLS EUROPE 1995

Dr.M. Snoeck Prof. dr. G. Dedene Katholieke Universiteit Leuven Dept. of Applied Economic Sciences Naamsestraat 69, 3000 Leuven, Belgium

Tel. 32 16 32 66 11 Fax. 32 16 32 67 32

Email: [email protected] [email protected]

Abstract

Object Orientation has as primary goal to improve the software construction process. Object Oriented analysis, design and software construction should yield software of a high quality: software that is reliable, maintainable, extensible, adaptable. However, delivering large OO software systems in a qualitative way is a significant challenge. Scaling up requires formal precision of the semantics of the modelling techniques and languages used by the development team. And when the target system contains an abundance of parallelism, the problem of validation becomes unfeasible if it is not supported by formal techniques. With the incorporation of formal techniques in the development process, we can expect significant benefits in terms of software quality.

For this reason, one might expect a high level of formality in current OOAD methods [4]. Unfortunately, most current OOAD methods are characterised by a low level of formality. The M.E.R.O.DE. methodology addresses this void. By making use of algebra, the methodology has been provided with a formal basis at several levels with a significant improvement of the quality of the software development process as a result.

1. An overview

M.E.R.O.DE. is an acronym for Model-driven Entity Relationship Object oriented DEvelopment. In M.E.R.O.DE. the specifications of information systems are build in two layers. The first layer is the conceptual model, also called "Business Model". It describes the exact functioning of the business in terms of object types, event types, sequence constraints and general constraints. This model acts as the basis for later information system development: in the Design Model (second layer), information systems are defined as a collection of functions that interact with the business model in order to satisfy the information needs of the end-users. Output functions will, for example, gather information on attribute values and present them to the user as reports on screen or paper. Interactive functions will collect information from the user and pass it to the business model by triggering business events. An overview of the approach is given in figure 1.

(2)

Specifications function 1 function 2 function 3 function 4 function 5 Business Model Design Model Implementation 1 Implementation 1 Implementation n Implementation 2

figure 1: Specifications according to M.E.R.O.DE.

2. The Business model

2.1. The static schema

The business model describes the exact functioning of the business in terms of object types, event types and relationships between object types and event types. Object types are the encapsulation of static and dynamic aspects. The static aspects of object types are described by means of the entity relationship modelling technique and an existence dependency graph (EDG). The semantics of the existence dependency graph are a subset of the semantics of the ER-model. This existence dependency graph will be used to establish consistency between the static and dynamic schema. Both entity types and relationship types are considered to be object types. The existence dependency graph establishes an existence dependency relationship between object types. An object (called 'marsupial') is existence dependent on an other object (called 'mother') if the life of the first object is always embedded in the life of the latter.

DEFINITION 1

Let P and Q be object types. P is existence dependent of 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 occurrence q of type Q. p is called the marsupial (P is the marsupial object type) and q the mother (Q is the mother object type).

For example, a loan of a book can only be created if the corresponding book exists. As long as a loan exists, it always refers to the same book. And finally, a loan-object cannot continue to exist if the book to which it refers is destroyed. The life of a loan object (this is the span between its creation and its destruction) is always embedded in the life of a particular book object. Therefore theobjecttype LOAN is existence dependent of the object type BOOK. By definition, this existence dependency partial ordering is derived from the ER-schema by means of the following rules:

- Each relationship type R is existence dependent on the participating entity types.

(3)

in [7]. When a relationship type R is weak on an entity type E, E is said to be existence dependent on the other participating entity types.

The existence dependency graph also defines the cardinality of the existence dependency relation. This cardinality defines how many occurrences of the marsupial object type can be dependent of one mother object at one point in time. In general these cardinalities are the same as those that are usually modelled in the ER-schema, provided that this ER-schema reflects reality at one point in time. In other words, it must be a time-sliced ER-schema. Due to particular information needs and the resulting database design, cardinalities of the ER-schema can be different from the cardinalities of the existence dependency graph.

EXAMPLE 1

MEMBERs can borrow BOOKS. Ay a particular point in time a BOOK can be borrowed by at most one MEMBER (figure 4). If a history of LOAN is kept to cover information needs, the ER-schema will be as in figure 4. In both cases the cardinality of the existence dependency relation between

BOOK and LOAN is 1, as shown in figure 2.

BOOK M LOAN 1 MEMBER

figure 3: time-sliced ER for the library

BOOK N LOAN M MEMBER

figure 4: NON time-sliced ER for the library

In a M.E.R.O.DE. business model, the ER-schema must be time-sliced, that is, the ER-schema must model cardinalities as they are at one point in time, and thus LOAN must be modelled as a one to many relationship

type. In the information design model the relationship type LOAN can be a many to many relationship type.

NOTATION

P (1)<- Q if P <- Q and an occurrence q of Q can have at most one existence dependent occurrence of P at one point in time.

P (n)<- Q if P <- Q and an occurrence q of Q can have more than one existence dependent occurrence of P at one point in time.

EXAMPLE 2

In the previous example: LOAN (1)<- BOOK en LOAN (n)<- MEMBER

GRAPHICAL REPRESENTATION

The ER-schema is drawn according to the notations of Chen [3]. The existence dependency graph contains all entity types and non-weak relationship types of the ER-schema. A mother object type is placed above the marsupial object type and the two are connected with a line. The existence dependency graph must be acyclic. The cardinalities are written next to the line that connects the mother and the marsupial object type.

BOOK MEMBER

LOAN

1 M

(4)

2.2. The dynamic schema

2.2.1 The Object Event Table

The dynamic schema defines event types and object type behaviour. The universe of event types in the model is called A. By means of the Object Event Table (OET), a subset of A is assigned to each object type. This subset is called the alphabet of an object type P and is denoted S_AP. In addition S_AP is partitioned in three mutually disjoint sets: {c(P), m(P), d(P)} is a partition of S_AP with

c(P) = {a ∈ A | a creates an occurrence of type P} ⊆ S_AP m(P) = {a ∈ A | a modifies an occurrence of type P} ⊆ S_AP d(P) = {a ∈ A | a destroys an occurrence of type P} ⊆ S_AP

The dynamic aspects of object types are described by means of two diagrams. In the first place, an object-event-table (OET) identifies the relevant event types and specifies which kinds of event create (c), modify (m) or destroy (d) occurrences of a particular object type.

EXAMPLE 3

The partitions of the alphabets of the object types BOOK,

MEMBER and LOAN are as follows:

S_ABOOK = {acquire, catalogue, borrow, renew, return, sell, lose}

with c(BOOK) = {acquire},

m(BOOK) = {catalogue, borrow, renew, return}, d(BOOK) = {sell, lose}

S_AMEMBER = {enter, borrow, renew, return, lose, leave} with c(MEMBER) = {enter},

m(MEMBER) = {borrow, renew, return, lose}, d(MEMBER) = {leave}

S_ALOAN = {borrow, renew, return, lose} with c(LOAN) = {borrow},

m(LOAN) = {renew}, d(LOAN) = {return, lose}

event type ENTER LEAVE ACQUIRE CATALOGUE SELL LOSE BORROW RENEW RETURN

figure 5: OET for the library

The relation between event types and object types is represented by means of the object-event-table (OET). This table contains one row per event type and one column per objet type. A 'C', 'M' or 'D' on a row-column point of intersection indicates that this particular event type is an element of respectively c(P), m(P) or d(P), where P is the object type corresponding to the column (see figure 5).

2.2.2 The Sequence Restrictions

Each object type can impose sequence restrictions on the event types in its alphabet by means of a structure diagram or an equivalent mathematical expression. The structure diagram or expression that defines the behaviour of an object type P must contain all and only the event types in S_AP. The partitioning of the alphabet in creating, modifying and destroying event types imposes a default life cycle which must be respected by the sequence restrictions.

The structure diagram is drawn according to the notations of JSD [11]. In this kind of diagrams a '*' indicates the iteration of a structure and a 'o' indicates an alternative in a selection structure. A '-' in a box symbolizes the do-nothing event.

(5)

a + b means do a or do b a.b means do a followed by b

a* means do a zero, one or more times.

The universe of event types A is extended with a special 'do nothing' event type, denoted by '1'. This event type is neutral for the sequence: 1.a = a = a.1. An object type P is a pair <α,e> with

α a subset of A, called the alphabet of P

e a regular expression over A,+,.,* determining the behaviour of P

The alphabet and regular expression of an object type can be selected by means of two selectors S_A and S_R: if P = <α,e>, then S_AP= α and S_RP = e.

EXAMPLE 4

For the library example the sequence restrictions are as follows: S_RBOOK = acquire.catalogue.(borrow + renew + return)*.(sell + lose) S_RMEMBER = enter.(borrow + renew + return + sell + lose)*.leave S_RLOAN = borrow.(renew)*.(lose + return)

2.3. Object interaction schema

In M.E.R.O.DE. object interaction is defined by means of common events. In this way, the object interaction schema is a subset of the dynamic schema

2.4. Consistency checking between the three schemas

The static and dynamic schema are dual perspectives of the same reality and must thus be consistent with each other. Therefore the semantics of the existence dependency graph must also be a subset of those of the dynamic schema. This means (among other things) that for each object in the ED graph there is one column in the Object Event Table and one JSD-diagram (and vice versa). An additional requirement is that a mother object type has to participate in all event types in which one of its marsupial object types participates: P <- Q ⇒ S_AP ⊆ S_AQ. This can be explained as follows. Existence dependent objects can not participate to any event without the mother object having knowledge of this event. By including the alphabet of the marsupial object type in the alphabet of the mother object type, sequence restrictions that concern event types of different marsupials can be specified in the behaviour of the mother. In this way also all possible places for information gathering are identified, which does not mean that all object-event routines will have a meaningful content. This way of working is surely not the most efficient one, but efficiency improvements are part of the implementation of the business model.

This requirement has as consequence that the alphabet of a relationship type always is a subset of the alphabet of the entity types it relates. On the other hand, when two (or more) object types share a number of common event types, it makes sense to demand that this communication between object types be modelled by a common marsupial object type. Possibly, the shared event types can be spread across more than one marsupial.

As sharing only one event type never can be the cause of deadlock, it is not required (but still allowed) to model a common relationship in this case. The ED relation between object types adds two constraints on the behaviour of an object type:

1) If P is existence dependent on Q (P <- Q), objects of type P can not do anything without an object of type Q participating. Moreover, the earliest a marsupial can be created is at the same time its mother is created and reversely, it cannot exist after its mother has been destroyed. Therefore:

P <- Q implies S_AP ⊆ S_AQ and c(P) ⊆ c(Q) ∪ m(Q) and m(P) ⊆ m(Q) and d(P) ⊆ d(Q) ∪ m(Q) 2) The lifecycle of P must be more deterministic than the life cycle of Q. This means that each sequence of events that is accepted by P also must be accepted by Q. Any sequence of events from S_AP that is not accepted by Q will always be rejected and can for this reason be dropped from the definition of P. The relation "more deterministic than" is denoted by the symbol "≤" and has been mathematically defined as follows.

(6)

∀ a ∈ A : a\B = 1 ⇔ a ∉ B and a\B= a ⇔ a ∈ B Let e, e' be regular expressions over A then

(e + e')\B = e\B + e'\B and (e.e')\B = e\B . e'\B and (e*)\B = (e\B)* Let P be an object type, α⊆ A and e a regular expression over A

such that P = <α,e> then P\B = <α∩ B, e\B>

This projection operator is used to define the relation "more deterministic than" on object types: P is more deterministic than Q ⇔ P ≤ Q ⇔ P + Q\S_AP = Q\S_AP

EXAMPLE 5

LOAN is existence dependent of BOOK and MEMBER. And hence LOAN≤BOOK, MEMBER: S_RBOOK\S_ALOAN

= acquire.catalogue.(borrow + renew + return)* .decatalogue.(sell + dispose + lose)\S_ALOAN = (borrow + renew + return)*.(1 + lose) and S_RMEMBER\S_ALOAN

= enter.(borrow + renew + return + sell + lose)*.leave\S_ALOAN = (borrow + renew + return + sell + lose)*

Both expressions are less deterministic than S_RLOAN.

2.5. Refining the business model

2.5.1 Business Object Abstract Data Types

Once the static and dynamic aspects of object types are defined, the business model is further refined by defining attributes for object types and specifying what happens to an object type when a particular event type occurs. This results in the definition of an abstract data type per object type which contains the state vector for that object type and one method per event type to which this object participates. A method for a Business object class is a set of operations on object attributes, using object as well as event attributes. For example, the method for the creation of an object class will initialise all the object attributes. The general layout of an abstract data type is as follows:

MEMBER

state vector:

code : unique identification of person; name : name of this person;

address : address of this person; zip : postal-code of the city;

category : depending on the category, persons have different authorities; number_in_loan :counts the number of books this person has in loan. event-methods:

...

MEMBER.modify-member (input-code; input-name; input-address; input-zip; input-category) code := input-code; name := input-name; address := input-address; zip := input-zip; category := input-category; ...

figure 6: Abstract Data Type for MEMBER

2.5.2 Additional business rules

(7)

and the conditions that contain object class attributes which constrain the event type. An example could be a rule that limits the number of books in loan to 10:

borrow: MEMBER.number_in_loan < 10

These conditions may involve event attributes as well as object attributes of all the object classes involved in the rule. Graphically this can be represented by enumerating this type of rules and attaching them by means of "flags" to the involved object types.

3. Design model

The design model, in M.E.R.O.DE. also called function model, defines how information functions provide the end-users of the information system with input and output facilities. The functions are designed as a layer on top of the business model. Two types of functions can be identified:

Information functions provide output to the end-user with some predefined screen- or print-layout. Interacting functions generate events that are transmitted to the business model.

Examples of functions for the library are F1 = register a new member

F2 = catalogue a new book F3 = register a loan

F4 = For each member who has a loan that is more than a week overdue, print a letter to remind him/her to return the book.

F5 = print a list of all books that should have been returned yesterday.

Both information and interaction functions are allowed to inspect the state vector of objects in order to retrieve information. This is depicted by means of a diamond connected to the function and to the object type. A double bar across the connection between diamond and object type indicates that the function inspects the state vector of more than one object type occurrence. Events are depicted as circles. The design model with the five functions defined earlier is shown in figure 7. This figure also demonstrates that functions are modular components independent of each other, that can easily be plugged in and out the business model.

MEMBER 1 LOAN M BOOK

Business Model

F1

F1-req F2-req

F3-req F4-req _F5-req

F2 letters list F3 F4 F5

(8)

Functions never introduce essential changes to the business model, However, at this stage application object types and event types can be defined. These are event types and object types that are required to fulfil information needs, but which are not essential to the business functioning.

A final element in the design model is the definition of transaction objects. Events are atomic units of handling which do not always keep the database in a consistent state (e.g. the deletion of a member while there are still loans registered for this person). Therefore transactions are defined. Basically, transactions produce streams of correct event messages that leave the database in a consistent state.

4. Technology Model

In an ideal situation, an Object operating system should be available to execute directly the Business Model specifications, without an explicit translation into an implementation. A PROLOG-based prototype of such an environment has been developed [14]. However, such technology is not commercially available today. As a consequence, a Business Model must be translated into an implementation model to map it on existing Information Technology. In this section the example of figure 8 will be used to indicate the implementation options.

Event1 Event1_Attrib BR1 C Event2 Event2_Attrib BR2 M Event3 Event3_Attrib BR3 E Event4 Event4_Attrib BR4 M C Event5 Event5_Attrib BR5 M M Event6 Event6_Attrib BR6 M E Object Class A A_Attributes Object Class B B_Attributes

(9)

4.1. An EVENT-based

implementation

In this transformation, "horizontal" cuts are taken in the Object-Event Table to implement the Business Model (figure 9). This means that the event types are takes as the basis for structuring the implementation of Business Models.

As a consequence, the object classes are dismembered, and all the methods from the abstract data types are grouped by event type. The state vectors are grouped into a file system, or in database management systems. Figure 10 suggest the components of such an implementation.

In this implementation, a procedure is constructed for each event type. This procedure contains all business rules, which are to be satisfied before an event of that type can be accepted, and all the methods (which must be performed once all business rules are satisfied).

The triggers of the implemented business models are call of business procedures, whereby all event attributes are included by means of communication zones. All the dismembered information is stored in a database, which can only be accessed through the business procedures.

The above diagram can easily be the starting point of the implementation of an object-oriented business model in a traditional CASE-tool. In this implementation procedure, the object relationship diagram can be transformed into a DBMS-schema, according to the classical rules for data base design. Classical normalisation rules apply as usual.

The major advantage of this approach lays in the fact that it is possible with all types of technology, varying from very advanced to very traditional. Even in every third generation language and file system it is possible to implement a Business Model this way.

figure 9: Horizontal cuts

Event1 Event2 Event3 Event4 Event5 Event6 Event1_Attrib Event2_Attrib Event3_Attrib Event4_Attrib Event5_Attrib Event6_Attrib BR1 BR2 BR3 BR4 BR5 BR6 C M E M M M C M E Message Call Procedure Using Comm. Zone

Name Comm. Zone Procedure OBJ_A OBJ_B

(10)

4.2. An OBJECT-based implementation

In this implementation approach, the object class abstract data types are taken as the basis for the implementation. Any Object-Oriented programming language that handles Abstract Data Types can be used for this type of implementation. Of course, support for persistent objects facilitates the complete integration with the long-term storage of objects.

figure 11: Vertical cuts

The base principle for this implementation is the use of bottom objects as the starting point for accepting event messages. In fact, each event type enters the business model implementation in the lowest (bottom) object (which participate to the event type) in the EDG. Next a bottom-up approach is used to transmit messages to all the higher level object classes (which participate to the event type) in the EDG. For the given example, this leads to the implementation diagrams in figures 11 and 12.

There are obviously a number of alternatives for the location of the business rules and to make sure that object classes which participate together to an event type react simultaneously. In the above example, the business rules of an event type could be attached to the abstract data type of the bottom object classes of that event type. If necessary, one object class inspects the state vector of other object classes to obtain the necessary information. Some OO-languages, like EIFFEL [12], provide support for a large variety of business rules directly. In some other Object-Oriented languages, additional methods have to be included to Abstract Data Types for all the business rules.

Event1 Event1_Attrib BR1 C Event2 Event2_Attrib BR2 M Event3 Event3_Attrib BR3 E M M M Object Class A A_Attributes Abstract Data Type A

Event4 Event4_Attrib BR4 C Event5 Event5_Attrib BR5 M Event6 Event6_Attrib BR6 E

Object Class B B_Attributes

Abstract Data Type B

(11)

A mixed implementation could check all the business rules by means of additional transaction object classes (one per event type). These transaction classes inspect the necessary object classes and only send correct, accepted event messages to the implemented business model. An obvious advantage is the fact that many Object-Oriented Presentation Shells (ObjectVision, ObjectView, VisualAGE, and so on) allow fast implementations along this scheme.

These implementation alternatives can even allow a mixing of OO-technology and conventional technology. As an example, an OO-presentation shell can be used for the GUI-based transaction handling. On the other hand object dismemberment can be used for the event handler, and the objects stored in a conventional DBMS. A natural mapping on CLIENT/SERVER technology is also possible. If wanted, the transaction handling can take place on CLIENT technology. The event handler and the business objects can be located on SERVER technology to facilitate easy consistency.

5. Deadlock

The business model models static and dynamic aspects separately. The static aspects are modelled by means of an ER-schema and an existence dependency graph. Dynamic aspects are modelled by means of an Object Event Table and JSD-diagrams. Object interaction happens by means of common events (as in JSD) and is in this way incorporated in the definition of object behaviour. More specifically, behaviour of object types is specified by defining for each object type a set of event types to which objects of this type can participate (Object Event Table). In addition restrictions can be imposed on the possible sequences of event types (JSD diagrams). For example in the definition of an object type BOOK, we can specify that a book first must be catalogued before it can be borrowed. Most conceptual schemas define more than one object type and different object types can participate to the same event types. For example, the event type 'borrow', concerns a MEMBER

as well as a BOOK. This means that different object types might impose conflicting sequence restrictions on common event types. In this case we have a deadlock. This can be illustrated by an example taken from Belgian legislation:

When a house is acquired, a deed of sale has to be signed. Property law prescribes full payment of the transaction's amount on the spot. In order to obtain the necessary funding most buyers need to contract a loan. In general, banks are only willing to contract a loan provided a first mortgage can be hold on a property. At its turn a mortgage can only be held on a property that is already owned by the mortgagor. Hence, anyone who acquires his first property and needs a loan to fund the acquisition is faced with a problem of circular prerequisites: the deed can not be signed before funding is available, but the funding can not be made available before the deed has been signed.

Stated in terms of objects and events, we would have something as

A LOAN is a sequence of the events "sign_mortgage", "sign_loan_contract" and "pay".

A MORTGAGE is a sequence of the events "show_purchase_deed" and "sign_mortgage". (The mortgagor can certify his ownership by showing a signed purchase deed.)

A OWNERSHIP is a sequence of the events "pay", "sign_purchase_deed" followed by an iteration of "show_purchase_deed".

A general and intuitive definition of deadlock follows from the assumption that objects and systems are finite. DEFINITION 2

A conceptual schema is deadlock free if it is possible to create at least one system consisting of at least one occurrence of some object type of the conceptual schema. In addition to the restrictions imposed by the conceptual schema, a system must satisfy the three following restrictions :

a. Each object must be created (systems starts as an empty set). b. Eventually each object must be destroyed (objects have finite lifes). c. Possibly all objects can be destroyed (system ends as an empty set).

(12)

definitions to be combined into one single set of sequence restrictions for the whole system. In order to do so, a mathematical model is needed that defines operations on object types.

The next paragraphs refine the concept of business model and illustrate it with a library example. Section 6 will define the process algebra which formally defines object types and their operations. The library example is used to illustrate the definitions. As the problem of deadlock only concerns the behaviour of objects, the definitions will mainly concentrate on the conceptual dynamic schema. A very short definition of the conceptual static model is given because one concept from it, existence dependency, is used for the deadlock checking purpose.

6. The Process algebra

6.1. The conceptual level

Behaviour of object types is defined in terms of sequence restrictions on event types. These sequence restrictions are expressed by means of structure diagrams, which are nothing else than a graphical representation of regular expressions. Regular expressions are in turn an algebraic formalism equivalent with Regular Languages and Finite State Machines [1]. This means that any statement which can be proved for regular expressions is also true for regular languages and Finite State Machines (and vice versa). Before defining object types and operations on object types, the definitions of regular expressions are reviewed.

6.1.1 Regular expressions

Let A be the universe of relevant event types in the UoD. Two special event types are defined: the "do nothing" event type, denoted by the symbol '1' and the deadlock event type denoted by the symbol '0'. Regular expressions over A are built by means of the operators '+' (selection) and '.' (sequence). The set of regular expressions over A, denoted R(A) is then defined as follows.

DEFINITION 3

R(A) = {e | e is a regular expression over A} where e is a regular expression over A if and only if (a) e = 0 or (b) e = 1 or (c) ∃ a ∈ A: e = a or (d) ∃ e', e" ∈ R(A) such that e = e' + e" or e = e'.e" The two operators '+' and '.' satisfy the following laws:

Let e, e', e" ∈ R(A), then (1) e + 0 = e

(2) e + e = e (3) e + e' = e' + e

(4) e + (e' + e") = (e + e') + e" (5a) 1.e = e

(5b) e.1 = e

(6a) e.0 = 0 (6b) 0.e = 0

(7) e.(e'.e") = (e.e').e" (8) e.(e' + e") = e.e' + e.e" (9) (e' + e").e = e'.e + e".e

Iteration, denoted by '*' is a meta-syntactical operator which can be defined by means of selection and sequence:

DEFINITION 4

e*

= ∑

ei _{where e}0_{= 1, e}1_{= e and}∀_n∈_{IN, n}≥_{2: e}n_{= e.e}n-1 i ∈IN

R*(A) is the set of regular expressions over A, built by using the operators '+', '.' and '*' R*(A),+,. is an idempotent semi-ring.

(13)

as e. Obviously deadlock is an absorbing state for a process and thus can never be followed by any action. Therefore 0.e = e (law (6b)). The expression e.0 describes a process that first behaves like e and then deadlocks. At least this process can undertake some meaningful actions and therefore most process algebras define that e.0 ≠ 0. This way of working is for example mandatory when the process algebra is used to study the behaviour of an implementation. However, when specifying business processes we are only interested in correct behaviour, this is, processes and systems that behave correctly up to the end of their lives and never deadlock. At the business specification level, e.0 is just as bad as 0 and therefore in M.E.R.O.DE. e.0 = 0 (law (6a)).

Law (8) states that choices are always made as late as possible. Suppose the following definitions for a book reservation in a library:

RES1 = reserve.cancel + reserve.borrow

RES2 = reserve.(cancel + borrow)

In the absence of law (8) the interpretation of RES1 is different from RES2. According to RES1, when a reserve event is offered to the system, a choice must be made between the reserve.cancel and the reserve.borrow branch. But of course it is not possible to foresee at the time the reservation is created wether this reservation will be cancelled or followed by a borrowing of the book. If the first alternative is chosen and a borrow event is offered to the system, the system will either deadlock or it must be allowed to backtrack up to the point where the wrong choice was made. The specification RES2 better reflects what is really intended: a reservation is created by a reserve event which will be followed either by a cancel event or a borrow event. The difference between the two expressions is further clarified by their implementation as Finite State Machines1 in figures 14 and 14. If the first alternative is choosen for RES1, the current state is state '1' after accepting the 'reserve' event in both machines. But in the FSM for RES1 only a 'cancel' event can bring the machine in an accepting state, while in the FSM for RES2 both a 'cancel' and a 'borrow' event will be accepted when the machine is in state '1'.

reserve cancel reserve borrow 0 1 2 3 reserve borrow cancel 0 1 2

figure 13: Finite State Machine for RES1. figure 14: Finite State Machine for RES2.

In fact, specifying sequence restrictions at the conceptual level comes to the specification of sets of allowable scenarios for objects. This is formalized by the following set of definitions.

Every regular expression defines a Regular Language, this is a set of scenarios over A. A scenario (or sentence) is a sequence of event types from A, where '^' acts as the concatenation operator and 1 as the empty scenario:

DEFINITION 5

(1) A* is the set of scenario's over A. A* is defined by (a) ∀ a ∈ A, a ≠ 0 : a ∈ A*

(b) Let s, t ∈ A*, then s^t ∈ A* (c) ∀ s ∈ A*: 1^s = s = s^1

1

(14)

(2) The regular language of a regular expression is a subset of A* defined by L(0) = ý

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) ∪ L(e).L(e).L(e).L(e) ∪ ...

From this definition it is clear that more than one regular expression can define the same Regular Language. For example, L(RES1) = L(RES2), namely

L(reserve.borrow + reserve.cancel) = L(reserve.(borrow+cancel)) = {reserve^cancel, reserve^borrow} This means that L(.) is a surjection on

P

(A*) that defines an equivalence between regular expressions: L(.) : R*(A)

By laws (1a) to (9) regular expressions with equal languages are identified: for example, L(e.0) = ∅ = L(0) and thus e.0 = 0 (law (6b)).

Process theories can be classified according to the level to which they identify processes as is done in [17]. Language equivalence identifies less than trace equivalence. Indeed, the trace sets of a + ab and ab both equal to {1, a, ab} and these two processes are thus identified in trace semantics. The language of these two processes are not equal: L(a + ab) = {a, ab} and L(ab) = {ab}. Compared to δ-trace equivalence (where deadlock is an observable event), language equivalence identifies more and less. It identifies less because in δ-trace semantics the processes a + a.0 and a.0 are identified (they both have δ-trace-set {1, a, a.0}) while in M.E.R.O.DE. they are different. But M.E.R.O.DE. also identifies more: the processes a.0 + a.b.0 and a.b.0 are equal in M.E.R.O.DE. while these processes have different δ-trace-sets: {1, a, a.0, a.b, a.b.0} and {1, a, a.b, a.b.0} respectively. Language equivalence always identifies more than failure-equivalence, ready equivalence and bisimulation equivalence [17].

6.1.2 Object types

The definition of an object type consists of two parts: its alphabet and the regular expression that defines the sequence restrictions the object type imposes on the event types from its alphabet.

In order to define that an object type can only define sequence restrictions on event types from its alphabet, a "forgetful" projection ϕ is needed that omits the structure of a regular expression by mapping it to the set of event types occurring in the expression. ϕ is a morfism for all operators:

DEFINITION 6

ϕ : R*(A) →

P

_{(A): e}→ ϕ_{(e) suvh that} ϕ_{(a) = {a}}

ϕ(e + e') = ϕ(e) ∪ϕ(e') ϕ(e . e') = ϕ(e) ∪ϕ(e') ϕ(0) is not defined

DEFINITION 7

Let α⊆ A, e ∈ R*(A), then <α,e> is called a tuple over <

P

(A), R*(A)>

S_A(BOOK) = {acquire, catalogue, borrow, renew, return, sell, lose} S_R(BOOK) = acquire.catalogue.[borrow + renew + return]*.[sell + lose] S_A(MEMBER) = {enter, borrow, renew, return, lose, leave}

S_R(MEMBER) = enter.[borrow + renew + return + lose]*.leave S_A(LOAN) = {borrow, renew, return, lose}

S_R(LOAN) = borrow.[renew]*.[return + lose]

Note that the regular expression of an object type is defined to be different of deadlock. In this way deadlock can only occur when several object types are combined by means of the concurrency operator. Object types are indicated by means of capital letters like P, Q, R, ... The operators '+', '.' and '*' can be defined on object types too:

DEFINITION 8

Let <α,e>, <α',e'> ∈ <

P

(A), R*(A)>, then <α,e> + <α',e'> = <α∪α', e + e'> <α,e> . <α',e'> = <α∪α', e . e'>

<α,e>*

=

∑

<α,e>i_{where <}α_,e>i_{= <}α_,ei_> i ∈IN

= <α,e*>

These operations satisfy the same laws as for regular expressions and thus <

P

(A), R*(A)>,+,. is an idempotent semi-ring, with <∅,1> as neutral and <A,0> as absorbing element for '.'. The neutral element for '+' is <∅,0>. We can now give a formal definition of a conceptual schema

DEFINITION 9

A dynamic conceptual schema

M

,<- is a set

M

⊆ <

P

(A), R*(A)> and an existence dependency relation <-such that (1) ∀ P ∈

M

: ∃ Q ∈

M

: P <- Q or Q <- P and (2) <- is acyclic.

) with a finite algorithm. As explained earlier, it is the interaction of objects that can cause deadlock. We thus need a formal definition of object interaction, which is given in the following set of definitions.

(16)

DEFINITION 10 Let B ⊆ A. Then

For Regular Expressions: 0\B = 0

1\B = 1

∀ a ∈ A : (a\B = 1 ⇔ a ∉ B) and (a\B = a ⇔ a ∈ B)

∀ e, e' ∈ R*(A) : (e + e')\B = e\B + e'\B, (e.e')\B = e\B . e'\B, (e*)\B = (e\B)*

For Object Types:

∀ <α,e> ∈ <

P

(A), R*(A)> : <α,e>\B = <α∩ B, e\B>

When two object types run concurrently, only those scenarios are valid where both object types agree on the sequence of common event types:

DEFINITION 11

Let P, Q ∈ <

P

(A), R*(A)>

P || Q = <S_AP ∪ S_AQ, e"> with e" ∈ R*(A) such that

L(e") = { s ∈ (S_AP ∪ S_AQ)* | s\S_AP ∈ L(P) and s\S_AQ ∈ L(Q)}

The regular expression e" always exists as is proved by the theory on Finite State Machines [10, theorem 8-7, p. 252] and by the existence of an algorithm to calculate e". This ||-operator can be used to calculate the behaviour defined by composite conceptual schemas. For example, the behaviour of a book that can be on loan zero, one or more times consecutively is:

S_R(BOOK|| (LOAN)*)

(17)

borrow renew return, lose acquire _catalogue borrow, renew, return sell, lose FSM for FSM for BOOK LOAN acquire _catalogue FSM for BOOK borrow renew (LOAN)* sell return lose

||

borrow renew return, lose FSM for(LOAN)*

figure 15: calculating the behaviour of a book on loan.

From the definition it follows that the || operator is idempotent, commutative, associative and has <ý,1> as neutral and <A,0> as absorbing element.

6.2. The object level

Absence of deadlock is the ability to create systems consisting of occurrences of object types of the conceptual schema

M

. Such a system is called an instantiation of

M

. In this paragraph we define what is understood by occurrences of object types and event types, what an instantiation of a conceptual schema is and how we can trace the behaviour of such an instantiation.

Objects are occurrences of object types. Every object has a unique identity, which for simplicity is assumed to be a natural number. As there can be an denumerable infinite number of objects, we simply assume that the set of objects is the set of natural numbers IN. Objects can be classified into object types, and each object is of exactly one type. This is expressed by the classification function type(.) and its inverse function, called oids2(.),

2

(18)

which collects all objects of a same type, and which must be disjoint, because an object can be of at most one type:

DEFINITION 12

M

_{:IN> : t}→_{olist(t) such that}∀_P∈

M

_{: type(t)}∈_S

AP⇒∃! p ∈oids(P) : P:p ∈olist(t)

p in t ⇔ type(p):p ∈ olist(t) t:P = p ⇔ P:p ∈ olist(t)

Streams of events are the equivalent of scenarios at the object level: they are sequences of events with increasing time values. The set of all possible streams of events from a set S is denoted S* and the empty stream is denoted &.

DEFINITION 14

(a) & is the empty stream

(b) Let S ⊆ T, then S* = {s | s is a sequence of events from S with increasing time values}

The table in figure 16 illustrates the concept of events and streams. For example, for the fourth event it is true that 100 in 3, what means that the MEMBER with object identification 100 participates in this event. And also 3:BOOK = 001, which means that the book that is involved in the fourth event is the one with object identification 001.

t type(t) olist(t)

0 acquire {BOOK:001}

1 catalogue {BOOK:001}

2 enter {MEMBER:100}

3 borrow {MEMBER:100, BOOK:001, LOAN:301} 4 renew {MEMBER:100, BOOK:001, LOAN:301} 5 return {MEMBER:100, BOOK:001, LOAN:301}

6 leave {MEMBER:100}

7 sell {BOOK:001}

figure 16: A stream of events for the library

(19)

DEFINITION 15

(i) Let p ∈IN, s,t ∈ T*, t ∈ T, then a projection \p : T* (a) &\p = & (b) t\p = t ⇔ p in t and t\p = & ⇔¬(p in t)

(c) (s^t)\p = s\p ^ t\p

(ii) The type of a stream over T is a scenario over A. Let s, t ∈ T* then type : T* type(s^t) = type(s)^type(t) and type(&) = 1

(iii) S_Ap = {t ∈ T | type(t) ∈ S_A(type(p)) and p in t} L(p) = {s ∈ (S_Ap)* | type(s) ∈ L(type(p))}

For example, let s be the stream depicted in figure 16, then s\100 = 2^3^4^5^6

s\100 ∈ L(100)

type(s\100) = enter^borrow^renew^return^leave type(s\100) ∈ L(type(100)) = L(MEMBER)

7. Investigating deadlock in a conceptual schema

An instantiation of a model

M

is a non-empty set Ω of objects that have been created and successfully ended and a stream ω that is the sequence of events to which these objects have participated. Formally:

DEFINITION 16

An instantiation of a model

M

is a tuple (Ω,ω) where Ω ⊆ IN, Ω ≠ ý,

ω ∈ (

∪

S_Ap)*, ω ≠ & such that ∀ p ∈Ω : ω\p ∈ L(p)

p ∈Ω

I(

M

) = {(Ω,ω) | (Ω,ω) is an instantiation of

M

}

For example, ({001,100,301},ω) is an instantiation of the library model, where ω is the stream of events from figure 16. Indeed,

ω∈ (S_A001 ∪ S_A100 ∪ S_A301)* ω\001 = 0^1^3^4^5^7 ∈ L(001) ω\100 = 2^3^4^5^6 ∈ L(100) ω\301 = 3^4^5 ∈ L(301)

) ≠ ý ⇔ S_R(σ(

M

)) ≠ 0

PROOF

I(

M

) ≠ ý

⇒∃ (Ω,ω) ∈ I(

M

), ω≠ &

) ≠∅ QED

The development of the transformation σ is illustrated by means of the library example.

First, the existence dependency relation is extended with the notion of cardinality. Suppose the conceptual schema contains the object types MEMBER, BOOK and LOAN. LOAN is existence dependent of MEMBER and

BOOK (LOAN <- MEMBER, LOAN <- BOOK) but in addition, a member can have several loans outstanding at one point in time. This cardinality of 'many' is denoted as LOAN (n)<- MEMBER. A book can be only once on loan at one point in time, and thus in this case we have a cardinality of 'one', denoted LOAN (1)<- BOOK.

The most simple case is when the conceptual schema is a singleton: it contains only one object type definition. Instantiations of such a schema will contain an arbitrary number of objects of that type. As objects of the same type never synchronise3, the stream of such a system will be an interleaving of the streams of the individual objects. In order to describe this kind of behaviour at the type level, an interleaving operator (denoted as |||) is needed. In contrast with the ||-operator, the interleaving operator does not match common event types, but simply shuffles the scenarios of both operands.

DEFINITION 18.a

∀ a ∈ A, s ∈ A* define (a^s)₀ = a (head) and (a^s)' = s (tail) Let s, t, u ∈ A*, then

(1) s interleaves (t,u) ⇔ s interleaves (u,t) (2) 1 interleaves (1,1)

(3) s interleaves (t,u) ⇔ (s₀ = t₀ and s' interleaves (t',u) ) OR (s₀ = u₀ and s' interleaves (t,u')) Let P, Q ∈ <

P

(A), R*(A)>, then

P ||| Q = <S_AP ∪ S_AQ, e"> with e" ∈ R*(A) such that

L(e") = { s ∈(S_AP ∪ S_AQ)* | ∃ t ∈ L(P), u ∈ L(Q) : s interleaves (t,u)}

The regular expression e" always exists as is proved by the theory of Finite State Machines [10, theorem 8-7 p.252] and the existence of an algorithm to calculate e". Note that when two object types have no common event types they never synchronize and thus their parallel composition results in an interleaving. Note also that the interleaving operator is not idempotent, while the parallel operator is.

EXAMPLE 6

LOAN||LOAN = LOAN

LOAN|||LOAN = borrow.(renew)*.borrow.(renew)*.(return + lose).(renew)*.(return + lose)

3

(21)

<{borrow, return},borrow.return> || <{reserve, cancel}, reserve.cancel> = <{borrow, return},borrow.return> ||| <{reserve, cancel}, reserve.cancel> = <{borrow, return, reserve, cancel},

borrow.reserve.cancel.return + borrow.reserve.return.cancel + borrow.return.reserve.cancel + reserve.cancel.borrow.return + reserve.borrow.cancel.return + reserve.borrow.return.cancel>

In analogy with iteration a ~-operator is defined as follows : DEFINITION 18.b

Let R ∈ <

P

(A), R*(A)>

R~

=

∑

R~i where R~0 = <S_AR,1>, R~1 = R and ∀ n ∈ IN, n > 2 : R~n = R ||| (R~(n-1))

i ∈IN

Note that the ~-operator does not always yield a regular expression, as the language defined by R~ can not always be recognized by a machine with a finite number of states.

In case

M

is a singleton {P}, The transformation σ can thus be defined as follows: DEFINITION 19.a

σ({P}) = P~

Suppose

M

has two object types related by the existence dependency relation. In case of a cardinality of 'many', for example

M

= {MEMBER, LOAN}, LOAN (n)<- MEMBER, the mother object will have several (this is zero, one or more, but we never know how many) marsupials of the same type running concurrently. Seen at the type level, all these marsupials have the same alphabet, but they should not synchronise on common events. They thus are interleaving. This means that at the conceptual level, the behaviour of a system composed of the object types MEMBER and LOAN, can be seen as one single process with behaviour description (MEMBER ||

(LOAN~))~

In case of a cardinality of 'one', for example

M

= {BOOK, LOAN}, LOAN (1) <- BOOK, the mother object type will run concurrently with at most one marsupial at a time. It is however possible that several marsupial objects exist consecutively. The behaviour of a system composed of the object types BOOK and LOAN can thus be described by the expression (BOOK|| (LOAN*))~.

Suppose now

M

contains all three object types, namely

M

= {MEMBER, BOOK, LOAN}, LOAN (n)<- MEMBER, LOAN (1)<- BOOK

In this case any instantiations will have an arbitrary number of interleaving books running in parallel with an arbitrary number of interleaving members. The parallel operator must be used as some MEMBERs will synchronise with some BOOKs in case of loans. The behaviour of an instantiation of

M

can thus be described by

(θMEMBER)~||(θBOOK)~

where the transformation θ expresses the fact that MEMBER- and BOOK objects must take account of their existence dependent objects4. More particularly

θMEMBER = MEMBER||LOAN~ as the existence dependency has a cardinality of many and θBOOK = BOOK||LOAN* as the existence dependency has a cardinality of one

This situation is illustrated in figure 17, for a case with two members and two books. The lifes of the LOAN -objects have been projected on the time axes for the MEMBER- and BOOK objects to illustrate that loans are consecutive for books but can interleave for members.

4

. One might expect that this expression should be (θMEMBER)~|| (θ_BOOK₎~||₍_LOAN₎~_{. It can however be}

(22)

M E M B E R 1 0 0 M E M B E R 1 0 1 BOOK 000 BOOK 001 LOAN 300 _{LOAN 301} LOAN 302 LOAN 303 LOAN 304

figure 17: Instantiation of

M

= {MEMBER, BOOK, LOAN}

For an arbitrary conceptual schema, the definition of transformation σ starts at the top of the existence dependency graph and goes down one level in the existence dependency graph at each recursion step. There is no danger for infinite loops as the existence dependency graph is acyclic.

DEFINITION 19.b

P is a bottom object type of

M

⇔¬(∃ Q ∈

M

: Q <- P) P is a top object type of

M

⇔¬(∃ Q ∈

M

: P <- Q)

THEOREM 2

For any schema

M

and σ as defined above it is true that (i) ∀ (Ω,ω) ∈ I(

M

) : type(ω) ∈ L(σ(

M

THEOREM 3

M

is deadlock-free ⇔ S_R(σ(

M

)) ≠ 0 and S_A(σ(

M

)) = A QED.

)

σ'(

M

) is regular and can therefore be calculated by means of Finite State Machines in stead of Push Down Automata and Context Sensitive Grammars. This results in a significant reduction of the complexity factor, also because Finite State Machines can be minimized at each step in the algorithm.

(24)

Customers can make reservations for a particular roomtype. Reservations must be confirmed by a written letter. If such a letter is not received in time, the reservation is canceled. When a guest checks in for the first time, his details are registered. At the end of the stay, an invoice is send to the customer who made the reservation.

The ER-diagram: ROOM ROOMTYPE GUEST STAY RESERVATION CUSTOMER CONSUMPTION PAY S IS-OF FOR INVOICED-FOR BY 1 N 1 N N 1 1 1 N N 1 N

The existence dependency diagram:

(25)

The object event table :

CUST. ROOMTP RESERV. ROOM GUEST STAY CONS. PAYMENT

reserve M M C confirm M M M cancel M M D no-show M M D first-check-in M M D M C C next-check-in M M D M M C consume M M M C put-on-bill M M M D invoice M M M M C dun M M M M M pay M M M D D cr-room C file-room D ass-roomtype M M cr-roomtype C file-roomtype D cr-customer C file-customer D file-guest D

The sequence restrictions are specified as follows:

ROOMTYPE = cr_roomtype.(reserve + confirm + cancel + first_check_in + next_check_in + not_arrive + assign_roomtype)*. file_roomtype

RESERVATION = reserve.(cancel + confirm.(first_check_in + next_check_in + not_arrive))

CUSTOMER = cr_customer.(reserve + confirm + cancel + first_check_in + next_check_in + not_arrive + invoice + dun + pay)*.file_customer

ROOM = cr_room.(assign_roomtype + first_check_in + next_check_in + consume + put_on_bill + invoice + dun + pay)*.file_room

GUEST = first_check_in.(next_check_in + consume + put_on_bill + invoice + dun + pay)*.file_guest

PAYMENT = invoice . (dun)* . pay

STAY = (first_check_in + next_check_in). (consume + put_on_bill)* . invoice . (dun)* . pay

CONSUMPTION = consume.put_on_bill

Checking this schema for deadlock requires the calculation of: (τROOMTYPE)* || (τCUST)* || (τROOM)* || (τGUEST)* where

(26)

τGUEST = GUEST || (τSTAY)* τROOM = ROOM || (τSTAY)*

τSTAY = STAY || (CONSUMPTION*) || (PAYMENT)*

This calculation has been done by means of a prototype tool. An overview of the algorithms used in this tool can be found in appendix A and the result of this calculation can be found in appendix B. As we can see, the conceptual schema satisfies the condition of deadlock freedom: the resulting FSM is not empty and every event type occurs in the list of transitions.

However, the following modification introduces a (partial) deadlock in the conceptual schema: Guests who stayed at the hotel should always be registered as new customers if they wish so.

As we already have an event type "cr_customer", this modification is realized by adding the "cr_customer" event type as deleting event type for the object type GUEST:

GUEST = first_check_in.(next_check_in + consume + put_on_bill + invoice + dun + pay)* .(file_guest + cr_customer)

The same calculation as above has now a different result: Event types:

1 CR_ROOMTYPE 2 RESERVE 3 CONFIRM 4 CANCEL

5 FIRST_CHECK_IN 6 NEXT_CHECK_IN 7 NOT_ARRIVE 8 ASSIGN_ROOMTYPE 9 FILE_ROOMTYPE 10 CR_CUSTOMER 11 INVOICE 12 DUN

13 PAY 14 FILE_CUSTOMER 15 CR_ROOM 16 CONSUME 17 PUT_ON_BILL 18 FILE_ROOM 19 FILE_GUEST

States: 0 1 2 3

First state: 0

Final states: 0

Transitions (from state, to state, with event type (number & name)):

0 1 1 CR_ROOMTYPE 0 2 15 CR_ROOM 1 0 9 FILE_ROOMTYPE 1 3 15 CR_ROOM 2 0 18 FILE_ROOM 2 3 1 CR_ROOMTYPE 3 1 18 FILE_ROOM 3 2 9 FILE_ROOMTYPE 3 3 8 ASSIGN_ROOMTYPE

As we can see, a number of event types are missing in the transition list. This schema contains indeed a sequence conflict. According to the sequence restrictions imposed by the object type GUEST, the cr_cust event type can only occur after a cr_guest event type. But the existence of a guest requires the existence of a stay. And a stay requires the existence of a reservation, which in turn requires the existence of a customer. We have in fact a kind of circular wait, and no customer can be created. The specifications only allow to create rooms and roomtypes.

9. A Formalism For Object Behaviour

(27)

time event MEMBER BOOK LOAN 0 acquire 201 1 acquire 202 2 enter 101 3 borrow 101 201 301 4 decatalogue 201 5 enter 102 6 acquire 203 7 borrow 102 202 302 8 borrow 102 203 303 9 renew 102 202 302 10 return 101 201 √ 301

figure 18: event sequence for the library circulation example.

The second strategy can be achieved by creating a Finite State Automaton (FSA) for every object that is created, and calculate the parallel composition of this FSA with the current system. As a system can only contain a finite number of objects, adding a FSA for each created object thus never leads to an infinite number of states.

By calculating the effect of the creation of an object at run-time, we reduce the problem of unlimited interleaving to limited interleaving, which is regular.

In order to describe and analyze behaviour at the object level, we define a new kind of FSA, called Object Finite State Automata (OFSA). The need for a new definition arises from the fact that the set of events an object can participate in, is possibly infinite, where the definition of a classical Finite State Automaton requires a finite alphabet [1]. The OFSA will straightforwardly be derived from the classical FSA by making use of the object identification.

9.1. Object Finite State Automata

DEFINITION 21

A typed identificationlist ν is a set of pairs P:Ι, where Ι⊆ oids(P), P ∈

M

and

∀ P ∈

M

: ∃ I ⊆IN : P:I ∈ν⇒¬(∃ I' ⊆IN : I' ≠ I and P:I' ∈ν) <

A transition of the form ∆(q,&,()) = Q' is called an empty transition. A OFSA is called empty-free if ∆ does not contain empty transitions.

if M = (Σ, Q, ∆, q₀, F) is a OFSA, then a pair (q,w) in Q × (T\Σ)* is a configuration of M. q is the actual state of M and w denotes the string on the input tape where the first (i.e. leftmost) event in w is the event under the input head. A configuration of the form (q₀,w) is called initial and one of the form (q,&) final or accepting for any q ∈ F.

A move by M is represented by a binary relation

CD

_{on configurations. If q'}∈∆_(q,a,ν_{) and dom(olist(t)) =}

dom(ν) and ∀ P ∈ dom(olist(t)) : t:P ∈ν:P, then (q,t^w)

CD

_{(q',w) for all w}∈_(T\Σ_)*.

FM

_{is the reflexive}

transitive closure of

CD

_.

A stream w ∈ (T\Σ)* is accepted by M if (q₀,w)

FM

_{(q,&) for a q in F.}

The language defined by M is the set of all streams accepted by M :

L(M) = {w ∈ (T\Σ)* | (q₀,w)

FM

_{(q,&) for a q in F}}

Let M = (Σ, Q, ∆, q₀, F) be a nondeterministic OFSA. We say that M is deterministic if a) ∀ q ∈ Q, a ∈ Σ, ν ∈ <

M

:

P

(IN)>, ∆(q,a,ν) contains at most one element

b) ∀ a ∈Σ, q ∈ Q: if ∃ν₁, ν₂∈

<M

:

P

(IN)> such that ∆(q,a,ν₁) and ∆(q,a,ν₂) are defined, then ν₁ and ν₂ are disjoint:

dom(ν₁) = dom(ν₂) = {P₁, ... P_k} and ν₁:P₁×... ×ν₁:P_k∩ν₂:P₁×... × ν₂:P_k = ý

In thiscase we write ∆(q,a,ν) = q' in stead of ∆(q,a,ν) = {q'}

If M = (Σ, Q, ∆, q₀, F) is a deterministic OFSA then M is completely specified if ∀ a ∈Σ, and ∀ q ∈ Q : ∃ ν₁,...ν_k∈ <

M

:

P

(IN)> such that ∆(q,a,ν_i) is defined for 1≤i≤k and {ν₁,...,ν_k} is a partition:

dom(ν₁) = dom(ν₂) = ... = dom(ν_k) = {P₁, ... P_n} and {ν_i:P₁×... ×ν_i:P_n}₁_≤_i_≤_k is a partition of INn

Algorithms can be defined to make a OFSA empty-free, deterministic or completely specified. This algorithms are analoguous to the algorithms for classical FSA.

9.2 Operations on Object Finite State Automata

9.2.1 Sequence

Let M₁ = (Σ₁,Q₁,∆₁,q₁,F₁) and M₂ = (Σ₂,Q₂,∆₂,q₂,F₂) be two deterministic and completely specified OFSA5*. A new OFSA M such that L(M) = L(M₁).L(M₂) is constructed as follows:

M = (Σ₁∪Σ₂, Q₁∪ Q₂, ∆, q₁, F₂) such that

− ∀ a ∈Σ₁, ∀ q ∈ Q₁, ∀ν∈ <

M

:

P

(IN)> such that ∆₁(q,a,ν) is defined: ∆(q,a,ν) = ∆₁(q,a,ν)

− ∀ a ∈Σ₂, ∀ q ∈ Q₂, ∀ν∈ <

M

:

P

(IN)> such that ∆2(q,a,ν) is defined:

∆(q,a,ν) = ∆₂(q,a,ν) − ∀ q ∈ F₁ : ∆(q,&,{}) = {q₂}

5

(29)

9.2.2 Sum

Let M₁ = (Σ₁,Q₁,∆₁,q₁,F₁) and M₂ = (Σ₂,Q₂,∆₂,q₂,F₂) be two deterministic and completely specified OFSA. A new OFSA M such that L(M) = L(M₁) + L(M₂) is constructed as follows:

M = (Σ₁∪Σ₂, Q₁∪ Q₂∪ {q₀}, ∆, q₀, F₁∪ F₂) such that

− ∆(q₀,&,{}) = {q₁,q₂}

− ∀ a ∈Σ₁, ∀ q ∈ Q₁, ∀ν∈ <

M

:

P

(IN)>such that ∆₁(q,a,ν) is defined: ∆(q,a,ν) = ∆₁(q,a,ν)

− ∀ a ∈Σ₂, ∀ q ∈ Q₂, ∀ν∈ <

M

:

P

(IN)> such that ∆₂(q,a,ν) is defined: ∆(q,a,ν) = ∆₂(q,a,ν)

9.2.3 Iteration

Let M₁ = (Σ₁,Q₁,∆₁,q₁,F₁) be a deterministic and completely specified OFSA. A new OFSA M such that L(M) = L(M₁)* is constructed as follows:

M = (Σ₁, Q₁∪ {q₀, q_f}, ∆, q₀, {q_f}) such that − ∆(q₀,&,{}) = {q₁, q_f}

− ∀ a ∈Σ₁, ∀ q ∈ Q₁, ∀ν∈ <

M

:

P

(IN)> such that ∆1(q,a,ν) is defined:

∆(q,a,ν) = ∆₁(q,a,ν) − ∀ q ∈ F₁ : ∆(q,&,{}) = {q₀}

9.2.4 Parallel composition

Let M₁ = (Σ₁,Q₁,∆₁,q₁,F₁) and M₂ = (Σ₂,Q₂,∆₂,q₂,F₂) be two deterministic and completely specified OFSA. A new OFSA M such that L(M) = L(M₁|| M₂) is specified as follows:

M = (Σ₁∪Σ₂, Q₁× Q₂, ∆, (q₁,q₂), F₁× F₂) such that ∀ a ∈Σ₁∩Σ₂ :

(30)

9.3 OFSA derived from a FSA

Let P be an element of top(

M

) en let M = (Σ,Q,δ,q₀,F) be a deterministic and completely specified FSA which accepts L(P). For each i ∈ oids(P) an OFSA M_i which accepts L(i) can be derived from M in the following way: M_i = (Σ,Q ∪ {q_e},∆,q₀,F) where if δ(q,a) = q' then ∆(q,a,ν) = q' where ν = {P:IN | P ∈

M

and a ∈ S_AP and P ≠ type(i)} ∪ {type(i):{i}} ∆(q,a,ν) = q where ν = {P:IN | P ∈

M

and a ∈ S_AP and P ≠ type(i)} ∪ {type(i):IN\{i}} and ∀ a ∈Σ : ∆(q_e,a,ν) = q_e with

ν∈ = {P:IN | P ∈

M

and a ∈ S_AP}

This definition can be generalized for an arbitrary object type P. In case P ∉ top(

M

) the existence dependencies have to be taken into account: it must be ensured that

∀ j ∈IN such that i <-- j: [i in t ⇒ j in t]

DEFINITION 22

Let P ∈

M

and M = (Σ,Q,δ,q₀,F) a deterministic and completely specified FSA which accepts L(P). For each i ∈ oids(P), define

Parents(i) = {j ∈IN| i <-- j}

Parents(i) is the set of all objects from which i is existence dependent, directly or indirectly. Then M_i is defined as follows:

M_i = (Σ,Q ∪ {q_e},∆,q₀,F) where if δ(q,a) = q' then

∆(q,a,ν) = q' with

ν = {P:IN | P ∈

M

and a ∈ S_AP and P ≠ type(i) and ∀ j ∈ Parents(i) : P ≠ type(j))}

∪ {type(i):{i}}

∪ {type(j):{j} | j ∈ Parents(i)} ∆(q,a,ν) = q with

ν = {P:IN | P ∈

M

and a ∈ S_AP and P ≠ type(i)} ∪ {type(i):IN\{i}}

∀ j' ∈ Parents(i): ∆(q,a,ν) = q_e with

ν = {P:IN | P ∈

M

and a ∈ S_AP and P ≠ type(i) and P ≠ type(j'))} ∪ {type(i):{i}}

∪ {type(j'):IN\{j'}}

and ∀ a ∈Σ : ∆(q_e,a,ν) = q_e with ν= {P:IN | P ∈

M

en a ∈ S_AP}