RUBIS wo~ks on a R-schema (RUBIS-schema) which is a decla~ative specification of the IS, made using the fo~mal specification language called PROQUEL (PROg~amming QUE~y Language) [ 34 ]. The R-schema p~ovides a conceptual desc~iption of both the static and dynamic aspects of the IS to be built. It is based on the REMORA model [1]. The static IS aspects a~e modelled by ~elations while ope~ations (elementa~y actions on an object) and events (elementa~y state changes t~igge~ing one o~ seve~al ope~ations) allow the modelling of the dynamic aspects of objects. Thus, the R-schema is a collection of ~elations, ope~ations and events specifications. In this schema the tempo~al aspects of the application a~e also taken into account; they a~e modelled by using the time types and functions p~ovided by the RUBIS Time Model.

RUBIS includes th~ee diffe~ent inte~faces as compute~ aided design tools:

a G~aphic Inte~face using an icon-based ~ep~esentation of the R-schema concepts. - an Expe~t helping the conceptual schema.

Design Tool wo~king on a semantic network, and designe~ to cr-eate, validate and imp~ove the - a Menu Inte~face based on the PROQUEL language.

The G~aphic and Menu based inte~faces a~e both devoted to expe~ienced designe~s while the Expe~t Design Inte~face can be used by ~elatively unexpe~ienced analysts o~ designe~s.

P~ototyping in RUBIS is achieved by the Tempo~al P~ocesso~ which manages tempo~al aspects of the specification and by the Event Processor which manages event recognition and synchronization. 80th P~ocesso~s use the PROQUEL inte~p~eter.

Thus the PROQUEL Inte~preter, the Event P~ocessor and the Tempo~al Processo~ are the key tools for prototyping information systems with RUBIS. They have been implemented as extensions of a Relational DBMS [2] •

The global architecture of RUBIS is given in section 2 with a brief desc~iption of the diffe~ent RUBIS system modules.

Section 3 p~esents how to specify the R-schema using the PROQUEL language. Then, the pape~ focusses in section 4 on one of the th~ee inte~faces, namely the Expe~t Design Inte~face. The Event P~ocessor is detailed in section 5. ( { 2. RUBIS ·ARCHITECTURE The architecture of the RUBIS system is presented in figure 2.1. This displays the three major aspects of the system, which arel 1. The (meta) data mananagement tools which handle the prototype database and the specification database (containing the R schema) . 2. The R-Schema design interfaces and the Validation Module. 3. The proto typing tools - the Application Monitor, the Event Processor and the Temporal Pr-ocessor-.

Each of these three aspects is introduced in turn. ( specification ,,, o .

: . . ....EVENT .......

PRotEssqR ·..T.EM.PORAL.;: <PRbc~S:SOR ........ .. -:--:. <..:. .. .:: .:: .. : ..... :.:-'

In this section, we detail the R-schema specification using the PROQUEL language. First, we can remark that the description of the R­ schema can be made incrementally: - first, the static sub-schema can be described with relation specifications (introduced by DEFINE RELATION), - second, a first version of the dynamic sub-schema can be obtained by specifying dynamic transitions (these specifications are introduced by DEFINE EVENT), - third, the dynamic sub-schema can be completed by operation, condition and factor specifications (respectively introduced by DEFINE OPERATION, DEFINE CONDITION and DEFINE FACTOR).

We illustrate this process by considering the framework automated subscription-library management system. The introduced center around the following relational schema: for an examples

copy (BOOK», COPY», ACQDATE, PRICE, CP STATUS) SUBSCRIBER (SUBSC»,NAME,ADDRESS,SUBDATE,SUBSC_STATUS,NUMCOPIES) REQUEST (REQ#, SUBSC», REQDATE, REQTYPE, BOOK», REQ_STATUS) LOAN (LOAN», LOANDATE, BOOK», COPY#, REQ»)

NOTICE (NTC#, NTC_DATE, LOAN», SUBSC») The meaning of the attributes (when not obvious) will be given in the examples. * The message "LOAN REQUEST" is described in PROP. It consists of a request number, a book number, the subscriber number, and the request type (immediate, or hold). * The event predicate is specified in PRED. In the example, the "LOAN REQUEST" message is acceptable only if both the requested book and the subscriber are present in the database. * The TRIGGER specifies the result of the arrival of the loan request. Three cases are possible:

I 1) The request can be satisfied (c3 : a copy of the book is available), and the subscriber is in good standing (c1 his subscription is up to date, he has no outstanding late notice, and he has less than three books currently on loan). In this case, a loan is created (op1), the request is accepted (op2), the status for the book is set to "ON LOAN" (op3), and the number of copies on loan for this subscriber is incremented (op4).

* a subscriber may not borrow more than three books simultaneously; * a loan request is receivable if the subscriber is valid (his subscription is up to date and he has no overdue books); * if a request is type "hold", the unavailability of the requested book causes the request to be put on hold.

(

Nor 0' on (of AND N()']' 03 AND op6 opS

ON MESSAGE COMMENT "Arrival of a loan request" PROP ( num_req : INTEGER; num_book : INTEGER; num_subsc : INTEGER; type: (IMMEDIATE, HOLD); } PRED ( (EXISTS book WHERE book# = CONTEXT.num_book)

AND (EXISTS subscriber WHERE subsc# = CONTEXT.num_subsc)} TRIGGER ( IF c1 AND c3 THEN ( op1 ON loan; op2 ON request; op3 ON copy; op4 ON subscriber; }; IF c1 AND NOT c3 AND c4 THEN op5 ON request; IF NOT c1 OR (c1 AND NOT c3 AND NOT c4)

THEN op6 ON request; };

2) The request cannot be satisfied (there is no available copy), but the subscriber is in good standing and wishes to leave his request on hold. The demand is put on hold (op5).

3) The subscriber is not in good standing, or the request cannot be satisfied for an immediate request. In this case, the request is refused, but is still added to the database for statistical purposes (op6) .

The specification of an event in PROQUEl defines the structure of the associated dynamic transition. The elements defined in the TRIGGER (conditions and operations) are defined separately. This allows a progressive and modular description of the application. In addition, the same condition or operation may be shared by several dynamic transitions.

For example, figures 3.2 and 3.3 show the specification of condition cl and of operation opl.

COMMENT "The subscription is up to date, no pending late notices, and less than three books on loan" TEXT ( VAR $status : STRING;

VAR $ncopy : INTEGER; VAR $nolate : BOOLEAN; SELECT UNIQUE subsc_status, numcopies INTO $status, $ncopy

FROM subscriber WHERE subsc# = CONTEXT.num_subsc; $nolate := NOT EXISTS notice

WHERE subsc# = CONTEXT.num_subsc; RETURN ( $status="VAlIDE" AND $ncopy<3 AND $nolate ); Each specification is a module independent of the others. The variables declared in a module have scope within that module. All modules receive an implicit call parameter referenced by the keyword CONTEXT. This parameter designates the message/tuple for which the arrival/state-change generated the event. In the specifications of evl, opl and cl, CONTEXT represents the loan request message. When a distinction is necessa~y between the old and new value of the contex t (in the case of an in te~na1 even t, fo~ instance), the p~efixes OLD and NEW a~e used.

The II cantex til of a dynamic tr-ansi tion is in fact an implicit pa~amete~ passed to all PROQUEL texts which it contains. Not having to decla~e each passage of the context by pa~amete~ clea~ly simplifies the develope~'s specifications.

A condition co~~esponds to a boolean function. Its text is te~minated by the RETURN statement, which dete~mines the ~etu~n value of the condition.

Each ope~ation possesses an implicit exit pa~amete~ the two successive values of the tuple it modifies. If the state change gene~ated by the execution of the ope~ation gene~ates an inte~nal even t, this parameter serves as the "con tex t" for the dynamic t~ansition of the gene~ated event.

Figu~e 3.3 illust~ates the cont~ibution of the combined usage of va~iables and SQL que~ies. In the usual application development envi~onment, the develope~ must ~eso~t to a language using "embedded SQL" , with all the awkwa~dness this implies.

The meta-base is inc~emented p~og~essively with the a~~ival of new specifications. The ~elational mapping of the R-schema is thus automatic, and the meta-base can be manipulated using the PROQUEL que~y language. The designe~ can also use the p~og~amming aspects of PROQUEL to const~uct his own p~ocedu~es and tools fo~ often used que~ie5, validation checks on the meta-base, and 50 on. In RUBIS, PROQUEL constitutes one of the main facto~s of integ~ation.

The design of la~ge IS is a complex, ite~ative, long and tedious task that must be suppo~ted by tools. The idea of compute~ aided design tools is not new [22], [23], [ 24 ].

Such tools p~ovide help to memo~ize the ~esults of the modelling activities, to check consistency and completness, to p~oduce documentation and info~m the design team on the status of design. They help in the management of schemas, but little in thei~ p~oduction. Recent ~esea~ches have st~essed the models used fo~ building schemas and the languages used to specifying them. But none p~og~ess has been made on the p~ocess of p~oducing these schemas. We believe that a step fo~wa~d in the design of IS ~equi~es an effo~t of fo~malization of the intellectual p~ocess of const~uction of schemas in o~de~ to build softwa~e tool which b~ings a mo~e effective help in design.

We are conscious of the fact that design is a non algo~ithmic activity. It is a complex task which is not ve~y fo~mal and is full of ince~tainity. The expe~ienced designe~ maste~s the task of design because he uses, on the one hand, his fo~mal knowledge of the models, ( ( ( and on the other hand, his experience which enables him to recognize typical cases and to treat them by analogy, to be attentive to certain delicate aspects ...

The nature of the task of design, therefore requires an effort of formalization of, on the one hand the algorithmic part of the design (for example algorithm of normalization) and on the other, the heuristic part (experimental rules of designers).

In addition, if we wish to support the design process by a tool, it must be able to include both formal knowledge and experimental knowledge.

For all these reasons an expert system approach seems appropriate. This approach will allow us to reproduce the expert's attitude, to exploit experimental knowledge necessary to the mastering of design by combining it with more formal knowledge.

Our hypothesis was to define an expert system for aid to the design process. The help supplied by the tool relies on a knowledge base where the concepts and the formal rules governing their use are grouped together with the rules of experimental know-how of design experts. The quality of the expert system depends on the richness of its knowledge base.

To define this knowledge base we have sought to analyse the reasoning processes carried out by the designer during the design process in order to reproduce them in the expert system. 4.2 Expert design tool architecture and functions In order to help designers in the R-schema production, we have chosen to develop a tool which allows them to start with a semantic view of the application domain, which provides guidance and tutoring to improve and detail it and finally maps it onto elements of the R­ schema.

The overall architecture illustrated on figure 4.1.

of the expert design tool (EDT) is It shows that the EDT is organized around a semantic network which represents the conceptual schema content at the different steps of It shows that the EDT is organized around a semantic network which represents the conceptual schema content at the different steps of its design. It initially corresponds to a rough semantic view of the application domain, progressively corrected, completed and detailed before it can be mapped onto relations, events and operations of the R-schema.

The manipulation module allows the designer to create, modify or delete elements of the semantic network.

Using the query module, the designer can be inform on the current version of the conceptual schema. MANIPULATION

MODULE

MODULE

NETWORK

The Semantic Network Transformer (SNT) is the most intelligent part of the interface. The SNT is intended to behave like an expert designer. Using its own design knowledge, it detects inconsistencies, incorrectness and incompletnesses, infers decisions and provides the designer with alternative solutions for improving the current version of the conceptual schema.

The SNT is organized as an expert system with a knowledge base and an inference engine. The knowledge base transformer includes a fact base (which is the semantic network) and a rule base including diagnosis rules, mapping rules and improvement rules. As the interface is implemented with PROLOG, the inference engine is the prolog interpreter.

We focus in the following on the SNT. We introduce in turn the semantic network and the transformer knowledge base.

The semantic network ~s an oriented and labelled graph. It comprises 5 types of node and 3 types of edge. Nodes and edges can be labelled. The 5 types of node correspond to the 5 predefined objects on which we suggest designers to concentrate on.

The 3 types of edge represent the 3 predefined associations among objects we propose to investigate during the design process. The two main design principles underlying the semantic network architecture are the following: a) reality can be easily illustrated on figure 4.2.

percieved in a causal way as have par-ticularstate changes r-egar-ded as

tr-~ mOd;/

( (

Event, Oper-ation and Enti ty ar-e 3 pr-edefined types of node of the semantic network. We added domain and text types node in or-der- to deal with pr-oper-ties of event, oper-ation and entity.

b) r-eality is composed of complex objects. A way to deal with the complexity of complex objects is to use aggr-egation, generalization and gr-ouping abstr-action for-ms. They cor-r-espond to the 3 types of edge of the semantic networ-k.

Aggr-egation, gener-alization and gr-ouping apply on event, oper-ation, domain and entity nodes. This means that the semantic view of an application domain we pr-opose to descr-ibe thr-ough the semantic network is a hierarchy of complex events, operations, domains and entities.

Let us detail and examplify the semantic networ-k types of node and types of edge using the following gr-aphical notation.

THE NODES 4.3.1 Semantic meaning of nodes - A domain node r-epr-esents a data type. It is used for- the r-epr-esentation of entity pr-oper-ties, oper-ation par-ameter-s and event contexts. A book number, a subscriber name are examples of domains. - An entity node modelizes an entity type of the application domain, such as a book, a request, a subscriber ... - An operation node represents an action type. The action of a given type modify entities belonging to the same type. For- example a request analysis, a new book insertion are described in the semantic networ-k with oper-ation nodes. - An event node descr-ibes state changes of the r-eal wor-Id that tr-igger- executions of similar- oper-ations. A book is just ar-r-ived, instance of book becomes available, ar-e examples of event types.

THE EDGES aggr-egation edge gr-ouping edge gener-alization ) edge - A text node is a predicate declaration that completes the description either of an operation (triggering condition of an operation for instance) or of an event (event predicate) or of an entity (entity constraint). If the real situation is that a copy can be loaned only if (a) "the copy is available and the subscriber is in good standing", the condition (a) should be described in the semantic network using a text type node.

The aggregation, grouping and generalization abstraction forms are respectively represented by the "a", "r" and Il g " edges. "a", "r" and "g" edges apply to domain, entity, operation and event nodes. - An aggregation edge (edge a) may be defined either between two nodes of the same type or between two nodes of distinct types. On example 1, subscribers are described as aggregate objects with 3 components: SUBSC#, NAME and ADDRESS. (

I I

SUBSCRIBER ~(a,id)

a ~

NAM Aggregate components can be domain nodes or entity nodes. The "id" label precises the aggregate identifier (SUBSC# in the example). - A grouping edge (edge r) is defined between two nodes of the same type. In the example below, a book is defined as a complex object; one of its components (STOCK) is a collection object. Every member of the collection is a copy. This means that a book in a library has usually several copies. I BO~K# I a - A generalization edge (edge g) is used for the representation of a "i s-a" re I a tionshi p. An edge of type g is def ined between two nodes of the same type. For example a copy can have three possible states; used, available and reserved described as 3 object nodes related to the copy node by three "g" edges.

I COpy AIVAILABL EJ , g

RESERVEC NOTE: In order to reach a good conceptual schema (criteria for "good" schema are presented in [ 30 ]), we have associated constraints (or norms) to nodes and edges of the semantic network which are part of their definition. We illustrate some of the norms with examples. N1: Object identification We consider as a good design discipline to identify each object of a conceptual schema. Thus, any entity node must have an in-going "id" labelled edge (see example 1).

N2: Operation atomicity Operation atomicity (one operation is defined as acting on one and only one entity type) is required in the semantic network. Operation atomicity avoids ~edundancy in p~ocess desc~iption and thus inconsistency in process execution. Consequently an operation node is always origine of one "a" edge with an entity node as target node. N3: Node I edge types compatibility norms These norms avoid inconsistencies in the object constructions. The following figure represents the autorized edge types between two node types.

ENTITY OPERATION EVENT TEXT

a r g a a r g a a a r g a a a a a a r g

Cardinality norms are based on an extended notion of cardinality as introduced in the E/R Model [ 31 ].

Let f be a function coupled with a "a" or "r ll type edge. For two entity nodes (called A and B in the following), the f and f-1 functions can be characterized by the three following properties. - totalness. A function f is total (t) if and only if each instance of A is associated with at least one instance of B at any point of time, else the function is partial (p). - valuation. A function f is single (s) if and only if each instance of A is associated with at most one instance of B at any point of time, else the function is multiple (m). .:... permanency. The function is permanent (p) if and only if the set of instances of B associated to an instance a of A, at a time t is included in the set of instances of B associated to a at a time t' ( t ' > t ), else the function is variable (v).

All combinations of properties are not allowed. The matrix on figure 4.4 summarized valid combinations of cardinalities. For instance the <tmp, tsp> couple of cardinalities for a "r" edge is allowed. Let us take an example, the function between the nodes STOCK and BOOK is total (t), multiple (m) and permanent (p), its opposite is total (t), simple (s) and permanent (p). This function can be associated with an "r lt edge in the network.

tsp tsv

a a r tmp a tmv a psp a psv a pmp a pmv a tsp tsv tmp tmv psp psv pmp pmv

In order to help the designer to progressively improve the content of the semantic network during the design stage, the semantic network transformer uses essentially three classes of rules: diagnosis rules, improvement rules, mapping rules. Let us concent~ate and examplify the two fi~st classes (mapping ~ules a~e used to map nodes and edges of the semantic netwo~k onto R-schema elements and a~e quite usual). 4.4.1 Diagnosis ~ules Diagnosis ~ules playa double ~ole; they automatically detect e~~o~s in the semantic netwo~k and p~opose one (o~ seve~al) solution(s) to co~~ect each type of e~~o~.

Thus, using diagnosis ~ules, the t~anfo~me~ is both a p~eventive and a c~eative tool.

E~~o~ detection is based on six design aspects, to which we have associated six g~oups of diagnosis ~ules.

- (a) object identification,

(b) entity st~uctu~ation, - (c) event and ope~ation st~uctu~ation,

(d) semantic netwo~k consistency, - (e) semantic netwo~k completeness,

(f) semantic netwo~k co~~ectness.

Rules of type (a) and (b) a~e illust~ated by examples.

Figu~e (1) desc~ibes pa~t of a semantic netwo~k which will be detected as inco~~ect because of the non-identification of the AUTHOR enti ty node (the object identification no~m N1 is violated). rJo~i1 a (3 ) Thus, the SNT will p~opose two alte~native acceptable solutions: - Eithe~ to t~ansfo~m AUTHOR into a domain node (2), - o~ to leave AUTHOR as an entity node, but necessa~ily identified by a domain node (AUTHII) (3).

The diagnosis / co~~ection p~ocess is an inte~active one. The SNT I will fo~ instance in the p~evious case, explain to the designe~ (if ~equi~ed) that in the fi~st solution autho~s will be conside~ed only as p~ope~ty of books and not as independant entities.

In the following example the semantic netwo~k content illust~ated in ( I ), means:

6 <pmv,p~ a

SUBSCRIBER (1) a

a a

(2 ) a a SUBSCRIBER is an agg~egate entity node and a component entity node fo~ the object COPY. The ca~dinalities of the ~elationship a~e as follows: - <psv> a copy may be used by any subsc~ibe~, a copy may be used at most one subsc~ibe~, a copy may be used by distinct subsc~ibe~s at distinct times. - <pmv> a subsc~ibe~ may bo~~ow any book, a subscriber may borrow several books, a subsc~ibe~ may bo~~ow diffe~ent books.

This content is detected as inco~~ect (the type of the a~c is not valid acco~ding the cardinality no~ms).

Thus the SNT proposes an alte~native description (2). The new entity LOAN is introduced as an aggregate entity with the two COPY and SUBSCRIBER entity nodes as components. The cardinalities of the two new edges are <pmp,tsp) and <pmp,tsp>; that is acceptable according to entity structuration rules.

Of cou~se the interactive process will be activated in orde~ to complete the description of the new node LOAN.

These rules aim at giving facilities to improve the semantic netwo~k content. Cont~a~ily to diagnostic ~ules, imp~ovement rules apply on valid parts of the semantic network.

Basically these rules are formalization of design expert heuristics infered from the designer practical experience. They are based on pattern recognition and suggest for each initial pattern of the semantic network a more sophisticated one (or several alternative ones) according to some specific design discipline.

For instance as we will illustrate sophisticate the representation of later the SNT can try to

enti ty classes using specialization; or it can suggest a more complete representation of entities based on temporal reasoning; or even combine these two aspects.

Improvement rules relate to: historization of entities and relationships, specialization (of entity, event and operation types), behaviour completion, - domain structuration.

Similarly to diagnosis rules, improvement rules identify a specific pattern in the semantic network and propose to the designer one or several improved representations pointing out some, may be; forbidden or undertaken design problem. Let us give two examples of semantic network transformations.

Situation (1) corresponds to a pattern identified with a <tsp, psp) couple of cardinalities.

<tsp, psp) t a I LOAN I (1)

g /

""g

(2 ) In this example, two entity nodes REQUEST and LOAN are aggregated in such a way that: - a loan is associated with one and only one request; furthermore a loan is always associated with the same request (tsp) ,

a request may be "not accepted"; thus it is not associated to a loan (ps p) .

The SNT proposes to improve the description presented in (1). This solution suggests to distinguish "accepted requests" and "waiting requests" that have, probably, different and specific operations and events. Following this line the designer can complete the new network. For instance he can add the operation node ACCEPTANCE WAITING REQUEST. This new operation node is defined on REQUEST WAITING. In this context, the designer must find the event type that triggers this operation type. In the example, the event type is COPY BECOMES AVAILABLE. Finally the designer reaches a more complete .and precise description of reality summarized as follows:

(3 ) ACCEPTE REQUEST g a

aC r--.......--_,

ACCEPTANCE OF WA .I..T I NG REQU.JEST

, I COpy BECOMES

AJVAILABILE The following example relates to behaviour completion historization of entities. Let us consider situation ( 1 ) : and (a) This rule suggests to the designer to describe the behaviour of the entity type STOCK. STOCK is a collection object. Every member of the collection is a copy.

LOST_COPY and NEW_COPY.

proposes two modification events on STOCK: (b) On this new representation, the SNT can apply a new improvement rule which suggests to the designer to memorize the lost copies. The new proposed representation (3) uses the generalization/ specialization structure.

a

/ - / ( a a

I" " i

g .---"-----j ~OST_COP1Y g

During the design process, the EDT drives actively and intelligently the designer, and progressively improve the semantic network until reaching a satisfactory solution for the designer and for the EDT. Then, the semantic network can be mapped onto R-schema elements, which can be used by the prototyping tools.

Information System prototyping is based on an automatic management of the database dynamics specified in the R-schema.

This involves : automatic recognition of events; automatic triggering of appropriate operations when an event occurs; - operation execution control;

event synchronization.

To attain such an automation, we have chosen to a) use a relational DBMS to deal with - managing the relations of the meta-base corresponding to the

R-schema specification; - executing operations texts and evaluating factors, conditions and predicates this requires an interpreter more powerful than a simple SQl interpreter. b) develop a mechanism able to : recognize an event; determine which operations to execute; - trigger and control operations execution;

synchronize event-chaining.

This mechanism is similar to the inference engine of a forward chaining expert system, whose cyclic function is to : - test the rule premisses; - choose a candidate rule; - execute the action-part of the rule; and which possesses a rule-chaining strategy.

The mechanism we propose is composed of four units managing all kinds of events.

the temporal processor recognizes temporal events; the event processor recognizes internal events and processes all events and their synchronization; the PROQUEL interpreter executes all texts of predicates, conditions, factors and operations when required by the event processor; - the application monitor allows to introduce instances of external events as test cases for prototyping. We focus now on the event processor which is the key part of the proto typing tool.

The event processor fulfils three main functions takes into account external and temporal events; processes events; orders them.

The first function is based on a FIFO management of the Message Queue. The second function consists of a meta-base search for appropriate conditions, factors and operations that will be evaluated or executed by the relational DBMS. These two functions do not presen t any major difficulties, as opposed to the third function, presented in the following section.

The chosen strategy for event synchronization is based on the induction notion, and on the use of the induction graph, which is derived from the R-schema. The induction notion is used to point out the ordering of events from the R-schema.

An event EVi inducts an event EVj, if and only if

EVi triggers OPn which modifies the relation recognized by EVj, - an occurrence of EVi, followed by the execution of OPn can produce an occurrence of EVj.

Graphically, the situation is the following \ " -, OPn

\ EV i ><:,...,--------< "./

Rk b----The notation used to represent an induction is

- nodes representing R-schema events, directed edges representing inductions, weights on the edges, which represent operations and are used as "induction condi tion-s".

The Induction Graph construction is accomplished in two steps: - an automatic step, producing the Maximal Induction Graph, a manual step transforming the Maximal Induction Graph into the Induction Graph. The Maximal Induction Graph can be automatically deduced from the Rschema - "a priori possible chainings" are obtained by analysing the ON, TYPE and TRIGGER parts of event and operation specifications. For a given event EVi, the chain is composed of all those events ascertaining relations modified by the operations triggered by EVi, in order to keep only "structurally possible chainings", the occurrence of each operation's TYPE (INSERT, DELETE, UPDATE) is checked within the ON part (i.e the category) of the internal event(s) it seems to induce. So, impossible chainings like "a product deletion produces a new availability" will be removed from the graph.

presents the induction graph corresponding to our case

2nd STEP The designer then manually modifies the Maximal Induction Graph, until he obtains the final Induction Graph.

During this step, the designer removes all the chainings that seem impossible to him from the graph. For example, EV4 ("loan request") seems to induce EVe ("copy availability"). This is because EV4 triggers a modify operation on COpy (ope) and EVe recognizes insertions or modifications of the COPY status.

In reality, an EV4 occurrence will never generate an EVe occurrence since ope always put the COPY status to "LOANED", and EVe only recognizes modifications setting a COPY status to "AVAILABLE". This kind of "false induction" cannot be detected automatically since it involves a semantical interpretation of predicates, conditions, factors and operations.

The final Induction Graph is an optimized and generally non-connected graph, which contains only "semantically possible chainings". Figure 5.2 presents the Induction Graph corresponding to the Maximal Induction Graph of figure 5.1.

If there are cycles in the Induction Graph, they are detected automatically, and the designer is asked to a confirm an "impossible endless loopll. EV3

EV6 OP5l~

~P8 ~EV4 EV8

EV7

Given an exte~nal or temporal event to be processed, the chosen strategy is based on a llbreadth-first" traversa I of the even t Induction sub-graph. ** The

induction sub-graph of an event is the maximal connected component, whose root is the event concerned.

8y using this kind of sub-graph when an external or temporal event EVi occurs, the Event Processor can lear"n immediately what "the set of internal events it will probably have to process" is. This set of internal events is called the EVi Induction Class and is written C(EVi). For example, referring to figure 5.2, the EV1 Induction Class is :

C(EV1) = { EV3, EV4, EV6, EV7, EV8 ) ** The internal event sequence construction is based on a breadth­ first traversal of the Induction sub-graph.

EV4

EV7 1s t 2nd 3rd c yc Ie: EV 1 cycle: EV3 + EV4 cycle: EV6 + EV7 + EV8 For example, if EV1 occurs, the complete processing cycle will include It means that within each cycle, all events from the same level are processed.

(

OP5/ ( EV6

EV3"' ~7 'EV8

EV1 ~ ~ )

) 2nd cycle ) 3rd cycle

The "breadth-first" strategy (e.g EV1, EV3+EV4, EV6+EV7+EVSl has a real advantage over a "depth-first" (EV1, EV3, EV6, EV4, EV7) or a "random" strategy (EV1, EV3, EVS, EV4, EV7, EV6). In fact, this strategy permits optimal management of the input/output implicit parameters. Idle time between gener-ation of an "oper-ation output parameter", and its use as input parameter to process the event induced by this operation, is minimal.

Internal events are recognized as soon as "noticeable state changes" occur (in fact just after all operations triggered at the same level have been executed); and these events are processed as soon as they are recognized (i.e during the next basic cycle of the event processor).

In this manner, there is no parameter waiting for use during a complete basic cycle. This is not true with other strategies; for instance, in the "depth-first" strategy, the EV4 input parameters must be kept in memory as long as EV3 and EV6 are still being processed.

The purpose of the Induction Graph is an optimization of the Event Processor work. For example, refering to figure 5.2, during the processing of ev2, if OP4 isn't in the list of operations to execute, a whole part of the EV2 Induction sub-graph can be pruned off

O~EV~ EV~

EV5 opS \

OP9!

~p~ EV7

EV9

EVI0

.. avoidance of useless predicate tests (EV5, EV9, EVIO), - avoidance of useless parameter recording, - an earlier freeing of resources ("read-Iocked" relations for predicate, condition and facto,.- evaluation; "write-locked" relations for ope,.-ation execution).

It appears smaller and the empty processed. ) that an external or temporal Induction Class will become smaller after each basic cycle, and will finally reach state. (another external or temporal event will then be At any moment, the Event Processor knows what it is processing and what it must deal with next; so it controls the whole process fully. USING THE PROTOTYPE During the experimentation of the prototype, the Event Processor displays a trace of what it is doing : which events are currently processed or waiting, which conditions are true, which operations have to be executed, and so on.

Analysing this t~ace, the designe~ can easily detect if things a~e going w~ong (bad ~esult fo~ a condition, database e~~o~ on a p~edicate evaluation, occu~~ence of a w~ong event, ... ) and immediately co~~ect the e~~o~s, modifying the specifications th~ough one of the design inte~faces.

Applying an ite~ative st~ategy, the designe~ will p~og~essively ~efine his specifications until the behaviou~ of the p~ototype is fully co~~ect fo~ him and fo~ the end-users. b. CONCLUSION In this pape~, we have p~esented an integ~ated compute~ aided tool socalled RUBIS, fo~ designing and p~ototyping Info~mation Systems. ( The RUBIS-schema is a decla~ative specification of the IS, made using the fo~mal specification language called PROQUEL (PROg~amming QUE~y Language). The R-schema p~ovides a conceptual desc~iption of both the static and dynamic aspects of the IS to be built. The static IS aspects a~e modelled by ~elations while operations (elementa~y actions on an object) and events (elementa~y state changes t~igge~ing one o~ seve~al ope~ationsJ allow the modelling of the dynamic aspects of objects. Thus, the R-schema is a collection of ~elations, ope~ations and events specifications. In this schema the tempo~al aspects of the application a~e also taken into account; they a~e modelled by using the time types and functions p~ovided by the RUBIS Time Model.

RUBIS includes three different interfaces as compute~ aided design tools: a G~aphic Inte~face, an Expe~t Design Tool wo~king on a "complex object" desc~iption of the application domain and a Menu Inte~face based on the PROQUEL language.

The G~aphic and Menu based inte~faces a~e both devoted to expe~ienced designe~s while the Expe~t Design Inte~face can be used by ~elatively unexperlenced analysts or designers.

P~ototyping in RUBIS is achieved by the Tempo~al P~ocesso~ which manages tempo~al aspects of the specification and by the Event P~ocesso~ which manages event ~ecognition and synch~onization. Both P~ocesso~s use the PROQUEL inte~p~ete~.

A fi~st ve~sion of RUBIS is ~unning on SUN Wo~kstation, unde~ the UNIX system. P~ototyping tools a~e w~itten using the C language, and design tools a~e using the X-Windows system. The expe~t design inte~face is pa~tly w~itten in P~olog.

Cu~~ent developments a~e leading towa~ds - the development of a functional debugge~ fo~ the p~ototyping aspects; - the extension of PROQUEL to a ~eal pe~sistent language; - the p~ovision fo~ the implementation of code gene~ato~s which will t~anslate the PROQUEL specifications into a ta~get "embedded language" (Pascal/SQL, C/QUEL, ... J; - the development of a graphical interface to manipulate the