=Paper=
{{Paper
|id=None
|storemode=property
|title=Information System Engineering: The RUBIS System
|pdfUrl=https://ceur-ws.org/Vol-961/paper28.pdf
|volume=Vol-961
|dblpUrl=https://dblp.org/rec/conf/caise/CauvetRL89
}}
==Information System Engineering: The RUBIS System==
https://ceur-ws.org/Vol-961/paper28.pdf
INFORMATION SYSTEM ENGINEERING
THE RUBIS SYSTEM
C. CAUVET *, C. ROLLAND *. J.Y. LINGAT **
* Unive~site Pa~is 1 UFR 06
17, Rue de la So~bonne
75231 PARIS Cedex 5 FRANCE
** THOM'6 33, ~ue Vouille
75015 PARIS FRANCE
ABSTRACT:
The pape~aims to p~esent a CASE system which is an integ~ated
compute~ aided tool so-called RUBIS, fo~ designing and
p~ototyping Info~mation Systems.
RUBIS is o~ganized a~ound the R-schema (RUBIS-schema), which
is a decla~ative specification of the Info~mation System (IS)
content, based on a conceptual model which emphasizes equally
the IS st~uctu~e and behaviou~.
Afte~ a b~ief ove~view of the RUBIS a~chitectu~e, we p~esent
th~ough examples how to const~uct the R-schema using PROQUEL:
the fo~mal specification language of RUBIS. Then, we
concent~ate on two diffe~ent aspects of RUBIS: the expe~t
design tool, which helps the designe~ to p~oduce the R-schema
fo~ a given application domain, and the p~ototyping tool,
which allows the execution of specifications on test case
data.
l
1. INTRODUCTION
The pape~ aims to p~esent an integ~ated compute~ aided tool so-called
RUBIS [33], fo~ designing and p~ototyping Info~mation Systems (IS).
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 Design Tool wo~king on a semantic network, and
helping the designe~ to cr-eate, validate and imp~ove the
conceptual schema.
- 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 paper is organized as follows:
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
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.
o
(
specification
,,,
1 experi7 ·,entation
I
.. ·APt:'~!9ATlqN .
. :... . MONITOR· : .
. ....EVENT ....... ·.TEMPORAL;:
.. . .
PRotEssqR
gr-ouping edge
( AC ) operation node 9 gener-alization
)
edge
/ EV / event node
CL> tex t node
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.
13
- 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.
4.3.2 Semantic meaning of edges
The aggregation, grouping generalization abstraction forms are
and
respectively represented by the "a",
"r" and g " edges. "a", "r" and
Il
"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.
(a,id) a
I BO~K# I
- 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
14
the copy node by three "g" edges.
COpy
g gt g
COpy I COpy , COPY
USED AVAILABLE
I
RESERVEC
J
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.
DOMAIN ENTITY OPERATI . EVENT TEXT
DOMAIN a r g a
(
ENTITY a r g a a
OPERATION a r g a
EVENT a r g
TEXT a a a a
Figure 4.3
15
,
N4: Cardinality norms
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 type edge. For two
ll
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
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 tmp tmv psp psv pmp pmv
tsp a a a a
tsv a a a a
tmp r
tmv
psp
psv
pmp
pmv
Figure 4.4
4.4 The transformer base of rules
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.
16
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).
(a,id)
(a,id)
BOOK
rJo~i1 8 AUT~OR
~€g (a,id) a a (3 )
(1 ) tB~KiJ
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
I identified by a domain node (AUTHII) (3).
The diagnosis / co~~ection p~ocess is an inte~active one. The SNT I
17
will instance
fo~ 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
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.
- 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 ; 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.
4.4.2 Improvement ~ules
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 later the SNT can try to
sophisticate the representation of enti ty classes using
18
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 <:,...,--------<
\
"./
OPn
Rk b-----
OPn
The notation used to represent an induction is EVi--)EVj
5.2 The Induction Graph construction
The Induction Graph uses the above notation. It contains
- 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.
22
1st STEP
The Maximal Induction Graph can be automatically deduced from the R-
schema
- "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.
(
Figure 5.1 presents the induction graph corresponding to our case
study.
(
Figure 5.1 A Maximal Induction Graph
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.
23
EV1
~ ~2
EV3 ~EV4
OP5l~ ~P8
EV6 EV8 EV7
Figure 5.2 Induction Graph
5.3 Internal event chaining strategy
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.
( EV1 ) 1st cycle
~ ~
( EV3"' EV4 ) 2nd cycle
OP5/ ~7 op8
( EV6 'EV8 EV7 ) 3rd cycle
Figure 5.3 : Internal event sequence
For example, if EV1 occurs, the complete processing cycle will
include
1s t c yc Ie: EV 1
2nd cycle: EV3 + EV4
3rd cycle: EV6 + EV7 + EV8
It means that within each cycle, all events from the same level are
processed.
24
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
So it permits:
.. 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 that an external or temporal Induction Class will become
smaller and smaller after each basic cycle, and will finally reach
the empty state. (another external or temporal event will then be
processed. )
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
25
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 so- (
called 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 inRUBIS is achieved by the Tempo~al P~ocesso~ which
manages tempo~alaspects 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;
26
- the development of a graphical interface to manipulate the
Semantic Network;
- the extention of the expert design interface to include
tutorial functionnalities.
REFERENCES
1[1J C. ROLLAND, C. RICHARD: The Remora methodology for information
'systems design and management in IFIP WG8.1 working conference on
." Information systems design methodologies: a comparative review" 1982
[2J BOUCHET and al. "Databases for Microcomputers : the PEPIN
Approach" ACM SIGMOD/SIGSMALLS, Orlando, Florida, Oct.1981.
[3J ROLLAND C, BENCI G, FOUCAUT 0 "Conception de Systemes
.d'Information : La Methode REMORA", Eyrolles 1987.
[4J BUBENKO J .A. "The temporal dimension in Information Processing"
( in Architecture and Models in Database Management, G.M. NIJSSEN, ed.
North-Holland (1977).
[5J WIEDERHOLD G., FRIES J.F., WEYL S. "Structured organization of
Clinical Databases" Proc. of AFIPS National Computer Conf., Anheim,
.1975.
;[6J BOLOUR A., ANDERSON T.L., DEKEYSER L.J. and WONG H.K.T. "The
,role of time in information processing : A survey" ACM SIGMOD RECORD
~ol. 12, nO 3, April 1982.
[7) SNODGRASS R. "The temporal query language TQUEL" ACM
Transactions On Databases Systems, vol. 12, nO 2, June 1987.
[8) NAVATHE S.B., AHMED R. "TSQL: A language interface for history
databases" AFCET-IFIP WG8.1 TAIS Conf., Sophia-Antipolis, France, May
1987.
[9J CODD E.F. "A Relational Model of Data for Large Shared Data
Banks" Communications of the ACM, vol. 13, nO 6, 1970.
[10) M.R. GUSTAFSSON, J .A. BUBENKO T. KARLSSON: "A Declarative
Approach to Conceptual Information Processing" in IFIP WG8.1 Working
Conference on "Information Systems Design Methodologies: a
comparative review" 1982.
[11) ANDERSON T .L. "Modeling time at the conceptual level" Proc.
2nd International Conf. on Databases, Jerusalem, June 1982.
[12) SNODGRASS R., AHN I. "A taxonomy of time in da tabases" Proc.
of ACM SIGMOD 85, Mar. 1985.
[13) ZLOOF M.M. "Query By Example: a database language" IBM
Systems Journal, vol. 16, nO 4,1977.
[14) OVERMYER R., STONEBRAKER M. "Implementation of a time-expert
in a Database System" ACM SIGMOD RECORDS, vol. 12, nO 3, Apr. 1982.
[15J ADIBA M., 8UI QUANG N., PALAZZO J. "Time concepts for
generalized data bases" ACM Annual Conference, Denver, Colorado,
U. S • A., Dc t. 1985.
[16) AHN I . , SNODGRASS R. "Performance evaluation of a Temporal
Database Management system" Proc. of ACM SIGMOD Conf., 1986.
[17) DADAM P., LUM V., WERNER H.D. "Integration of Time Versions
into a Relational Database System" Proc. of 10th VLDB, Singapour,
Aug. 1984.
[18) ADIBA M., BUI QUANG N. : "Historical multi-media databases"
Proc. of 12th VLD8, Kyoto, Japan, Aug. 1986.
[19) BARBIC F., PERNICI B. "Time modeling in Office Information·
Systems" Proc. of ACM SIGMOD Conf., Austin, Texas, May 1985.
[20) CLIFFORD J., RAO A. "A simple general structure for temporal
27
domains" AFCET-IFIP WG8.1 TAIS Conf., Sophia-Antipolis, France, May
1987.
[21] BOLOUR A., DEKEYSER L.J. "Abstractions in temporal
information" Information Systems, vol. 8, nO 1, 1983
[22] DBE : Data Base Engineering review vol 17, n04, Special issue on
data design aids methods and environment, Dec. 84
[23] S. CERI: "Methodologies and Tools for Database Design" ed, North
Holland Publ Co 1983.
[24] R.P. BRAGGER, A. DUDLER, J. REBSAMEN, C.A. ZEHNDER: "GAMBIT: An
interactive Database Design Tool for Data Structures, Integrity
Constraints and Transactions" in Database Techniques for Professional
Workstations, ETH Zurich 1983.
[25] J.M SMITH, C.P. SMITH: Database Abstractions Aggregation.
Communications of ACM. June 1977.
[26] J.M. SMITH, C.P. SMITH: Database Abstractions Aggregation and
Generalization. ACM TRANSACTIONS on Database Systems. June 1977.
[27] M.L BRODIE, E. SILVA: Active and Passive Component Modeling:
ACM/PCM in IFIP WG8.1 working conference on "Information systems (
design methodologies: a comparative review" 1982.
[28] KAHN K., GORRY G. A. : "Mechanizing Temporal Knowledge"
Artificial Intelligence, Vol.9, N°l, Aug. 1977.
[29] MITTAL S. : "Event-based Organization of temporal Databases"
Proc. CSCSI/SCEIO Conf. 82, Saskatoon, Saskatchewan, 17-19 May 1982.
[30J CAUVET C. "Un modele et un outil d'aide a la conception des
Systemes d'Information" Ph. D. Univ. of Paris 6, Nov. 1988.
[31J CHEN P. "The Entity/Relationship model : towards a unified
view of data", ACM TODS, Vol 1, nO 1, 1976.
[32J NOBECOURT P., ROLLAND C., LINGAT J.Y. : "Temporal management in
an extended relational system" 6th British National Conf. on
Databases, Cardiff, G.B., July 1988.
[33J LINGAT J.Y, NOBECOURT P., ROLLAND C. : "Behaviour management in
database applications" VLDB 1987, Brighton, G.B., Sept. 1987.
[34J LlNGAT J.Y, COLIGNON P, ROLLAND C. : "Rapid prototyping : the
PROQUEL language" VLDB 88, Los Angeles, USA, Sept 88.
2B