The GOODSTEP Pro ject:

General Ob ject-Oriented Database

for



Software Engineering Pro cesses

The GOODSTEP Team

Abstract 1 Ob jective of GOODSTEP

The goal of the GOODSTEP project is The goal of the GOODSTEP pro ject is

to enhance and improve the functionality of to develop a sophisticated database system

a ful ly object-oriented database management dedicated to the supp ort of software develop-

system to yield a platform suited for appli- mentenvironments SDEs and make the ba-

cations such as Software Development En- sis for a platform for SDE construction with

a software pro cess to olset and generators for vironments SDEs. The baseline of the

graphical and textual integrated to ols imple- project is the O database management sys-

2

mented on top of it. tem DBMS. The O DBMS already in-

2

The GOODSTEP pro ject started Septem- cludes many of the features required by SDEs.

b er 1992 and will last for three years. This The project has identifed enhancements to

pap er mainly rep orts on the rst year of work O in order to make it a real software en-

2

within the pro ject. gineering database management system.

The baseline of the pro ject is an exist- These enhancements are essential ly upgrades

ing Europ ean commercially available ob ject- of the existing O functionality, and hence

2

oriented database pro duct: O [4]. Rather requirerelatively easy extensions to the O

2 2

than developing a new database manage- system. They have been developedinthe

ment system from scratch, GOODSTEP will early stages of the project and are now ex-

enhance and improve this pro duct. ploited and validated by a number of software

Besides the enhancements and improve- engineering tools built on top of the enhanced

ments of O which make it an admirably O database system. Toease tool construc-

2 2

suited system for SDEs, the pro ject pro- tion, the GOODSTEP platform encompasses

vides a numb er of test cases and p erforms tool generation capabilities which al low for

case studies to evaluate and justify the ap- generation of integratedgraphical and textual

proach. This includes p orting and devel- tools from high-level speci cations. In addi-

oping a numb er of existing software engi- tion, the GOODSTEP platform provides a

neering to ols on top of the new platform, softwareprocess toolset which enables mod-

the development of to ol generation capabili- eling, analysis and enaction of softwarepro-

ties to exploit the features of a fully ob ject- cesses and is also built on top of the extended

oriented system, and the developmentofad- O database. The GOODSTEP platform wil l

2

vanced software pro cess mo deling capabili- be validated using two CASE studies carried

ties which, once again, exploit the provided out to develop an airline application and a

features of O . business application.

2

The choice of an ob ject-oriented database



This work has b een funded by the EU under con-

management system as baseline of the

tract No. 6115 ESPRIT-I I I pro ject GOODSTEP

pro ject derives from the inadequacy of re-

lational database systems for software engi-

neering applications, which has b een recog-

nized for quite some time [22,25]. This has resulted in a great e ort in b oth the indus-

trial and research communities to extend the

t database technology towards more

curren Software Process Tool Construction

werful and exible database management

po toolset toolset

systems. In particular, in this context we are

interested in the work done on the develop-

uses uses

ment of ob ject-oriented database systems.

The class of ob ject-oriented database sys-

wo cat-

tems can b e roughly classi ed in t O2 Additional functionalities

egories: those o ering the full functionali-

ted data mo del, which

ties of the ob ject-orien O2 Kernel O2 database

e will refer to from nowonas object

w enhancement management system

database systems ODBSs [10], and those

o ering only a subset of the ob ject-oriented

mo del, whichwe will call structural ly ob ject-

oriented database systems. The main dis-

Figure 1: The GOODSTEP SDE platform

tinction b etween structurally ob ject-oriented

databases and ob ject database systems,

which is also the main drawback of the

hances the functionalities o ered by O ,by

2

rst class, is that most of the structurally

adding new functionalities to its kernel or on

ob ject-oriented database systems, suchas

top of it. Moreover, two to ol sets have b een

PCTE/OMS [17], Damokles [12], assume a

develop ed together with the enhanced O

2

certain level of granularity of the ob jects to

system to constitute the GOODSTEP plat-

b e stored and retrieved and that they further

form. The rst to olset TCT supp orts the

cannot de ne encapsulation of data struc-

generation of new to ols. The other set of

tures by op erations. These systems either

to ols supp ort development, simulation and

supp ort relations b etween coarse-grained ob-

execution of software pro cesses SPT. In

jects such as pro ducts of the SE life cycle

particular it integrates the to ols generated

e.g. A is the sp eci cation of B, A is owned

by the rst to ol set. Both SPT and TCT sup-

by develop er Q, etc., or else supp ort a rather

p ort the development of a customized SDE.

ne-grained level of ob jects suchassyntac-

The rest of the pap er is structured as fol-

tic units of programs or sp eci cations i.e.

lows: In Section 2, we rst describ e the

statements, variables, pro cedures, etc..

GOODSTEP platform in some detail. In

In practice, many software engineering

Section 3, we describ e the fundamental re-

to ols require supp ort for b oth levels of granu-

quirements for the underlying database sys-

larity. By contrast, ob ject database systems

tem as required by the GOODSTEP plat-

are the b est approach to supp ort sophisti-

form. In Section 4, we showhow these re-

cated ecient storage and retrieval of ob jects

quirements are addressed by O and we de-

2

at arbitrary levels of granularity [13].

scrib e the planned O extensions. Finally,

2

The pro ject amply demonstrates two im-

Section 5 concludes the pap er while drawing

p ortant features of an ob ject database sys-

attention on ongoing and further work.

tem. In the rst place, it enables much eas-

ier implementations of SE-tools than when

using conventional DBMSs. This is b ecause

2 Building the GOODSTEP Plat-

the richer semantics of the ob ject oriented

form for Software Develop-

mo del is most suited to the complex data

mentEnvironments

handled in software engineering applications,

and also b ecause there is no problem of xed

The metho ds and languages to b e used for

granularity of ob jects. In the second place,

the development of a software application {

it signi cantly improves the functionality of

b e they graphical or textual languages { de-

softwaretools which can bebasedupon it.

p end on the application domain. For exam-

The software architecture of GOODSTEP

ple, real-time applications require di erent

is illustrated in Figure 1. GOODSTEP en-

sp eci cation and implementation languages

than nancial or medical applications. More- it is p ossible to assign values to tokens and

over, the pro cess mo dels that supp ort an ap- predicates to transitions, describing the con-

plication development b est can not b e pre- straints on tokens consumed and pro duced

de ned. They dep end not only on the appli- by transition rings.

cation domain, but also on the organization

and on the p eople who are running the pro-

2.1.1 SLANG

cesses. Current SDEs su er from their se-

We describ e SLANG by means of a simple

lection of sp eci c combinations of languages

example. A SLANG sp eci cation of a pro-

and often assume a particular pro cess. Both

cess fragment is presented in Figure 2. For

usually do not completely cover the needs

an elab orated discussion of SLANG, we refer

of any software development and imp ose a

to [7].

pre-sp eci ed development mo de. Instead,

the software industry demands customiz-

Executable Test Cases

hmay b e easily adapted to able SDEs, whic Module

* the evolving needs of software development.

GOODSTEP addresses this need by provid-

Start Test ing means to

*

 de ne the pro cess used for developing

Data for Test Cumulative Test

ware system within the software a soft Execution Results (CTR)

(DFTE)

pro cess to ol-set and generate the to ols needed during the  Test Cases

Prepare Test Used Up

course of a software pro cess using the to ol construction to ol-set.

Executable

Test (RET) Using the pro cess to ol-set a mo del tailored

to the needs of a particular institution or Test Results

Being Computed en pro ject can b e mo deled, analyzed and ev (TRBC)

Execute Test

later used for running a software pro ject. Test Results Using the to ol construction to ol-set, it will Summary (TRS) b e p ossible to de ne and generate concep- Test

Results

tual schemas and de ne and generate a set

tegrated syntax-directed software devel- of in End Test Errors

Found t to ols from appropriate sp eci cation opmen Add Test

Result languages. Final Test

Results

2.1 Software Pro cess Mo deling and

Enactment

Figure 2: A Mo del of a Pro cess Fragmentin

Software pro cess mo deling and enactment

SLANG

is supp orted in GOODSTEP by the SPADE

Software Pro cess Analysis Design and En-

The example mo dels a pro cess activity to

actment environment. SPADE provides a

test executable mo dules of a software sys-

domain-sp eci c language for the mo deling

tem. The net asso ciated with the activity

and enactment of software pro cesses called

is activated as so on as another pro cess ac-

SLANG Spade LANGuage. SLANG is

tivity SLANG nets are hierarchically orga-

based on high-level nets and is given formal

nized in activities puts a token that repre-

semantics in terms of a translation scheme

sents a mo dule successfully compiled on the

from SLANG ob jects into ER nets. ER

place Executable Modules and some other to-

nets [18] are a mathematically de ned class

kens representing test data on the place Test

of high-level Petri nets that provide the de-

Cases.For each such test case, a test is ex-

signer with p owerful means to describ e con-

ecuted mo deled by transition Execute Test

current and real-time systems. In ER nets,

and the results are cumulatively recorded in 2.1.2 SPADE

an error rep ort. If no more test cases are

SPADE [6]is a software pro cess environment

available, transition EndTest res, thus end-

that supp orts the enactment of pro cess mo d-

ing the activity, and pro ducing a token that

els written in SLANG. The enactment of the

mo dels the error rep ort in place Final Test

pro cess mo del causes the automatic execu-

Results. Note that ExecuteTest is describ ed

tion of computer-based actions and guides

as a black transition; meaning that the tran-

the b ehavior of p eople involved in the pro-

sition is not atomic; it invokes the execution

cess. In addition to the description of a

of the testing program and then the execu-

software pro duction pro cess, a SLANG pro-

tion of the net is resumed without waiting

cess mo del may also include the sp eci cation

the tests to b e completed. This mechanism

of a software meta-pro cess. Therefore, pro-

is used in SLANG to mo del the invo cation of

cess enactmentinvolves the execution of ac-

to ols such as those generated with the to ol

tivities of b oth the pro duction pro cess and

construction to olset.

the meta-pro cess. The meta-pro cess mo d-

ware

ProcessData els those actions that do not aim at soft

pro duction, but concern the management of the pro cess itself: creation/mo di cation

Place Token Arc Transition

of activities, ob ject typ es, etc. The re ec-

tive nature of SLANG makes it p ossible to Activity

MetaType ModelType SLANG Types

manipulate the pro cess de nition i.e., Pro-

Model-specific Types

cessTypes and ProcessActivities in the same

Module TestCase TestResult TestSummary

ays other pro cess data are manipulated, Name:string; TestData:text; UsedTest:TestCase; TestingModule:EexecutableModule; w Failures:list of Failure; Results: set of TestResult; Author:Programmer;

#PendingTests:integer; olution.

Body:text; therefore enabling pro cess ev

Imp ortant requirements for database sys-

ExecutableModule

tems arise when we consider the problem of Compiler:string;

CompilerVersion:string;

pro cess evolution [5]. All information de- Machine:ComputerResource;

Size:integer;

scribing a SLANG sp eci cation pro cess typ e

Code:binary; descriptors and pro cess activities and the

Is_a relationship

ExecutableTest

pro cess state all instances of ProcessData

and its subtyp es have to b e stored in a

rep ository, i.e an O database. The SLANG

2

Figure 3: Typ e De nition of Tokens for Net

interpreter uses O to access b oth the de-

2

in Figure 2

scription of the pro cess mo del and the pro-

cess data pro duced and mo di ed as result of

To complete the formal de nition of the

its enactment.

net, the token typ es must b e de ned. These

While it is not p ossible to change the def-

typ es are de ned by attaching typ e de ni-

inition of the SLANG language  xed part

tions to places. Typ e de nitions are orga-

of the schema, all other comp onents can b e

nized in a typ e hierarchy, de ned by an \is-

changed. Changes to the instances of the

a" relationship. The ro ot of the hierarchyis

xed part of the schema e.g. arcs and tran-

the typ e ProcessData.Typ es inherit the at-

sitions, and changes to the mo di able part

tributes and op erations of their ancestors in

of the schema e.g. token typ es corresp ond

an ob ject-oriented style. The example of the

to changes in the pro cess mo del. Changes

typ e hierarchy used in the net of Figure 2 is

to the instances of the mo di able part corre-

given in Figure 3.

sp on to changes in the state of the enacted

To supp ort pro cess evolution, i.e. \changes

pro cess mo del.

on the y" [21], typ e descriptions maybe

added or changed during pro cess enactment.

2.2 To ol Construction

The change of a typ e requires instances of

that typ e to change accordingly.

The GOODSTEP platform contains two

to ol generators. The rst one is the Graph- Pro ject compiler that is capable of gener-

ating graphical to ols. The second is the store intermediate versions of a do cumentso

GENESIS compiler which takes a sp eci - that they can revert to a previous revision

cation written in the ob ject-oriented to ol if their subsequent mo di cations turn out to

sp eci cation language GTSL [8] and au- b e ill-chosen.

tomatically derives textual syntax-directed Finally, users exp ect acceptable perfor-

to ols. We rst discuss the functional and mance from the to ols such that their work-

1

non-functional prop erties users require from ow is not interrupted.

generated to ols and then sketch some issues

on to ol design which later on have an im-

2.2.2 Issues in To ol Design

pact on the database functionality required

What is a do cument in the database?

to make to ol generation feasible.

The common internal representation for

syntax-directed to ols such as syntax-directed

2.2.1 Requirements on Software De-

editors, analyzers, pretty-printers and com-

velopmentTo ols

pilers is a syntax-tree of some form. In prac-

The to ols to b e generated will b e used by

tice, this abstract syntax-tree representation

users to edit, analyze and transform do cu- of do cuments is generalized with context-

sensitive edges to an abstract syntax-graph ments. To giveasmuch supp ort to users as

p ossible, the to ols must b e syntax-directed

for reasons such as ecient execution of do c-

according to the languages in which do cu-

uments, consistency preservation of do cu-

ments are written.

ments, and user-de ned relations within do c-

Besides dealing with errors concerning the

uments. Such context-sensitive edges are not

con ned to within individual do cuments { context-free syntax, to ols should also deal

with errors concerning b oth the internal

context sensitive edges frequently exist b e-

static semantics of do cuments and inter-

tween comp onents of distinct do cuments. As

document consistency constraints. The to ols

an example c.f. Fig. 4 where they relate

may allow temp orary inconsistencies to b e

no des in a graph of mo dule interface sp eci -

cations with corresp onding no des in another created during edit op erations, since do cu-

graph of mo dule b o dy sp eci cations. This ment creation in a way whichavoids such

temp orary inconsistencies is impractical in

leads to a project-wide abstract syntax graph.

many cases.

For a detailed discussion of context-sensitive

Obviously, do cuments must b e storedper-

edges we refer to [14].

sistently b ecause they must survive editing

pro cesses. Moreover, users require to ols to

How is it stored? Due to the require-

op erate as safely as p ossible, i.e. in case of

ments of p ersistence and integrity, a p er-

a hard- or software failure they exp ect in-

sistent representation of each do cument un-

tegrity preservation of do cuments their im-

der manipulation must b e up dated as so on

mediate usabilityby the same or other to ols

as each user-action is nished. Typically

against hard- or software failures. Also sig-

a user-action a ects only a very small p or-

ni cant user e ort must not b e lost in case

tion of the do cument concerned, if any.

of a failure, i.e. any completed change a user

Given that the representation under manip-

p erformed to a do cumentmust p ersist in the

ulation is an abstract syntax-graph, the up-

database.

date can easily b ecome inecient if, rstly,

When the consequences of user actions are

a complex-transformation b etween the graph

p ersistent, users must have the abilityto

and its p ersistent representation is required

backtrack or \undo" such actions when mis-

and, secondly, the p ersistent representation

takes are made. Thus, users maywantto

is such that large parts of it havetobe

rewritten each time, although not b eing

1

As the users of the GOODSTEP platform have

mo di ed. This would for instance b e the

di erent roles, we distinguish in the sequel users

which are the develop ers that use the customized

case, if we had chosen to store the graph in a

GOODSTEP platform in order to develop an appli-

sequential op erating system le which is up-

cation from SDE builders who use the features pro-

dated at the end of each user-action.

vided by the GOODSTEP platform for customizing

Such ineciency can b e avoided completely it to obtain a particular SDE. Documentation Subgraph

ToSection Value=’WindowManager’ List Section ToFirst ToTitle Documentation List Section Title ToParagraph ToNext Value=’The Module ...’ List ToFirst Paragraph Paragraph ... List ToLast ToNext

ToDoc ......

Module Design Subgraph

Name=’WindowManager’ Function ToIdent Decl Module Ident Name= ’InitWindowManager’ ToExport Operation ToFirst Proc ToIdent Decl List Decl Ident Name=’y’ ToParList Par ToFirst CBV ToName ToImport Ident ToFirst List Par Ident List ...

ToType ToImpl Ident ToImpl ToImpl ToImpl ToImpl

ToImpl Module Implementation Subgraph Name=’WindowManager’ Function ToIdent Decl Module Ident

ToImpl Name= ’InitWindowManager’ ToProcs Operation ToFirst Proc ToIdent Decl ToImpl List Decl Ident Name=’y’ ToParList Par ToFirst CBV ToName ToImport ... List Par Ident ... ToDecl

ToNext ... ToType ToStat ... Ident Name=’ComputePosition’ Proc ToIdent Decl Decl Ident Name=’Pos’ ToParList Par ToFirst CBR ToName List Par Ident

ToNext Name=’Position’ ToDecl ... ToType

ToStat ... Ident

Figure 4: Excerpt of a pro ject-wide Abstract Syntax Graph

tion language is appropriate to cop e with the if the p ersistent representation takes the

complexity inherent in pro ject-wide syntax- form of an abstract syntax graph itself, with

graphs. To manage this complexity the comp onents and up date op erations that are

distinction of ob jects and typ es, encapsula- one-to-one with those required by the to ols

tion of ob jects' attributes by op erations and concerned.

information-hiding as well as inheritance to

express generalisation/sp ecialisation should

b e applicable to the data de nition. There-

3 Requirements on Databases

fore, a p owerful typ e mechanism including

for Software Engineering

ob ject constructors for expressing di erent

typ es of aggregation and metho d de nitions

In this section we outline the requirements

to achieve encapsulation must b e provided.

on a DBMS that arose during design of b oth

the software pro cess to olset and the to ol con-

Schema Up dates Due to the re ective

struction to ol set. A detailed discussion of

nature of SLANG we require supp ort for

the requirements can b e found in [14].

schema up dates from the database system as

a prerequisite for a SPADE implementation.

DDL/DML The typ es of tokens as de-

This has a numb er of implications. First of

ned by SLANG typ es must b e established

all, the database system must enable intro-

in the schema in order to have the pro cess

duction of new typ e de nitions, changes to

engine storing tokens in O .For the same

2

existing typ e de nitions and even deletion

reason, the overall structure of pro ject-wide

of typ e de nitions even though the database

abstract syntax graphs has to b e de ned in

mayhave b een lled with instances already.

terms of the data de nition language of the

As the pro cess engine cannot b e stopp ed for

database system and it must b e established

executing the schema up dates, these up dates

and controlled by the database's conceptual

must b e p ossible, even if other concurrent

scheme. This implies that the data de ni-

trol integration of the to ols and pro cess in- DBSE applications such as to ols are op erat-

tegration. Control integration implies that ing against the database. Pro cess data may

a to ol can invoke another to ol to p erform have b een created and accessed under con-

some piece of software pro cess it is carrying trol of the schema which has to undergo a

out. A pro cess mo del governs the invo cation change. These data must not b e lost or cor-

of to ols and a to ol is invokable only if the rupted otherwise by the change. This re-

mo del allows it. Triggers are required also quires means to adapt the data structures

to supp ort the integration of software pro- of existing data to the changed structures.

cess interpreters and the integration b etween Since the pro cess engine can not b e stopp ed

these interpreters and the to ols. for p erforming these changes, migration of

data must b e atomic, i.e. either done com-

pletely or not at all.

Transactions The database system must

preserve the integrity of the abstract syntax-

graph and the pro cess state against hard- or Versions The DBSE must supp ort cre-

software failures. Therefore the system must ation and managementofversions of those

supp ort atomic transactions, i.e., a transac- subgraphs that representversionable do cu-

tion mechanism that enables grouping a se- ments. In particular, it must enable its

quence of up date-op erations such that they clients to derive a new version of a given

are either p erformed completely or not p er- subgraph, to maintain a version history for a

formed at all. To ensure that a to ol can re- subgraph, to removeaversion of a given sub-

cover in case of a failure to the state of the graph, and to select a currentversion from

last completed user-action, each completed the version history.

DBSE transaction must b e durable.

Views A pro ject-wide abstract syntax graph

Distribution In an SDE distribution of may contain a lot of redundant information {

activities is imp ortant. This can b e achieved in Fig. 4 no des of typ e FunctionModule, De-

by allowing for distributed accesses from the clIdent, OperationList and the edges ToIdent

users' client workstations to a database and ToExport are duplicated in the interface

server. Following this approach, however, and b o dy subgraphs. Eliminating this du-

care must b e taken that the server do es plication by sharing the aggregation subtrees

not b ecome a p erformance b ottleneck for the concerned has the following advantages: 1

whole environment. the conceptual schema is simpli ed 2 stor-

age of the schema and corresp onding data re-

quires less space, and 3 consistency preser-

vation esp ecially across do cument b ound-

4 Enhancing the O ODBS

2

aries b ecomes much easier. If subtree shar-

ing is to b e used, to ols accessing the pro ject

Relational database systems are inappro-

graph need a view mechanism like that of-

priate for storing pro ject graphs, since 1

fered in many relational database systems, to

the data mo del can not express syntax

maintain appropriate separation of to ol con-

graphs appropriately, 2 relational database

cerns and so allow separate to ol development

systems do not supp ort versioning of do c-

and maintenance. These to ol-oriented views

ument subgraphs and 3 relational views

must b e regarded as virtual graphs since they

are not up datable in general. No struc-

are not actually stored in the DBSE, but up-

turally ob ject-oriented DBMS meets all of

dates on views by to ols must propagate au-

our requirements. Those that are capa-

tomatically to the underlying pro ject graph.

ble of eciently managing pro ject graphs

such as GRAS [20], lack functionality w.r.t.

views, versioning, access rights and ad- Active capabilities When abstract syntax-

justable transaction mechanisms, and distri- graphs are changed by one user, other users

bution. Others that o er these functionali- mayhave to b e noti ed ab out this change.

ties such as PCTE/OMS [17] or CAIS-A [2] This can b e achieved with a trigger facility.

are unable to eciently manage the large Triggers may b e used also to supp ort con-

a syntax graph with a single network call. collections of small ob jects as they o ccur in

A further contribution to eciency is that pro ject graphs and are therefore inappropri-

execution of metho ds de ned in the schema ate. The approach of GOODSTEP is there-

is done on the clientthus avoiding a p erfor- fore to start from an existing ob ject-oriented

mance b ottleneck on the servers. DBMS which is the O system since this

2

already addresses some of the requirements

4.2 Schema Evolution

presented previously. This will b e discussed

in Subsection 4.1. A ma jor e ort in GOOD-

Schema evolution in an ob ject database

STEP is devoted to enhancing O enhancing

2

system refers to the ability to change

or adding functionalities for schema evolu-

b oth the schema and consequently the

tion, version management, view de nitions

database. Every time a schema is mo di-

and active database capabilities. This will

ed the database has to b e up dated to b e

b e addressed in Subsections 4.2-4.5.

brought to a consistent state with resp ect to

the new schema. A schema can b e changed 4.1 Features o ered already by O

2

using sp ecial primitives, see for example [24].

In [13]wehave shown how to implement

The corresp onding database up dates are p er-

the structure de nition of pro ject-wide ASGs

formed using user-de nedconversion func-

within a schema of a fully ob ject-oriented

tions whose input parameters are instances

DBMS in general and within O in partic-

of the old and the new schema class de -

2

ular. In O wewould therefore de ne com-

nitions. Being executed they transform ob-

2

mon prop erties of no des within classes. The

jects of the database to conform to the new

type of the class then de nes attributes and

schema. The SDE builder has to de ne a

outgoing edges as instance variables.Navi-

conversion function for each mo di ed class

gation along edges is implemented by deref-

in the new schema. System default transfor-

erencing. Consistency of the graph de ni-

mations are applied in case no explicit con-

tion can b e checked at compile-time based

version functions are given by the builder.

on O 's type system. For schema simpli -

From a p oint of view of an SDE builder,

2

cation purp oses, inheritance is used to de-

after execution of the appropriate conver-

ne common prop erties of no des only once

sion functions, the entire database conforms

in a sup erclass. Integrity of a syntax graph

to the the new schema. From an imple-

is enforced by encapsulation, i.e a to ol can

mentation p oint of view, conversion func-

not mo dify edges and attributes directly, but

tions are up dates to the database. There

must use the metho ds de ned for that pur-

are mainly two strategies for implementing

p ose. The computations necessary for p er-

database conversion functions: immediate

forming these metho ds can b e done within

and lazy [19]. In the rst case, all ob jects

the schema b ecause the data de nition lan-

of the database are up dated immediately af-

guage of O is computational complete.We

ter the execution of all conversion functions.

2

have shown in [5]how the execution of the

In the second case, ob jects are up dated only

pro cess engine can b e implemented using the

when used i.e. conversion functions are exe-

O query language [3].

cuted only when ob jects are e ectively used.

2

O o ers a transaction mechanism which

No matter what strategy is used, the ef-

2

can b e used for grouping a set of up date

fect on the database has to b e the same: the

statements such that they are p erformed

database must b e in a consistent state with

completely and are then durable or not at

resp ect to the new schema [16]. For a more

all. This enables up dates of pro cess states

detailed discussion of O schema up dates us-

2

as well as changes to a syntax-graph to b e

ing lazy evaluation of conversion functions

done in an integrity preserving manner.

we refer the interested reader to [15].

O provides for distributedaccess from

2

several clients to several central databases.

4.3 Versions

These client/server accesses exchange pages.

Our goal for extending the O database Given the clustering mechanism of O [9]

2 2

system with version management facilities is we can manage to transfer many no des of

of real data stored in the database whereas to provide a Version Manager, implemented

a virtual schema describ es a virtual world. as a prede ned O class which provides a

2

A view is thus in our context a sp ecial kind set of metho ds for manipulating the di er-

of schema with certain restrictions. We use entversions.

the term virtual schema as a synonym of view The granularityofversioning is that of

in what follows and the term real schema is comp osite ob jects. These comp osite ob jects

used in contrast to virtual schema to avoid implement subgraphs of the pro ject-wide ab-

confusion. stract syntax graph. We provide a class

Like a real schema, a view includes de - Version which enables a to ol to de ne com-

nitions of classes, metho ds, typ es, functions p osite ob jects at run-time. Instances of this

and named ob jects. It may also imp ort and class are the smallest entity known by the

exp ort de nitions from other schemas, al- version manager. The di erent ob jects b e-

though these mechanisms are given a slightly longing to a comp osite ob ject are versioned

di erent semantics. In addition, virtual def- together. Therefore the class Version pro-

initions can b e included in a virtual schema. vides several basic metho ds which allows the

As a matter of fact, the distinguishing p oint SDE builder to:

between a real and a virtual schema is the

 Create a version i.e. initialize a version

fact that the latter has at least one virtual or

history graph,

imaginary class p ossibly imp orted whereas

the former has only real classes.  Add or delete ob jects to a version, thus

A virtual schema is always derived from including/removing them in/from the

another virtual or real schema, whichwe call versioned comp osite ob ject

its root schema. When we de ne a view we

 Derive a new version from an existing

must therefore declare its ro ot schema. The

version,

ro ot schema of a view determines on which

 Determine a particular version as de-

databases it can b e activated, namely those

fault version,

databases instantiated from its ro ot schema.

Using these virtual schemas an SDE  Select a particular version di erent from

builder is enabled to de ne virtual abstract the default version,

syntax graphs on top of conceptual graphs

 Delete a version by removing it from the

stored in the database. These graphs can b e

DAG,

accessed and mo di ed in a way customized

 Retrieveaversion,

towards particular to ols.

 Navigate through the version history

4.5 Active Capabilities

graph.

This will provide a to ol builder with the

In the framework of GOODSTEP active

basic functionality to maintain di erentver-

rules have b een intro duced in O as a means

2

sions of those subgraphs of a pro ject-wide ab-

of supp orting SDE construction. We can

stract syntax graph that representversioned

only sketch here and refer for an elab orated

do cuments.

discussion to [11]. Rules we consider are pro-

duction rules based on the Event-Condition-

4.4 Views

Action ECA formalism. The overall se-

mantics of an ECA rule is: \Whenever the

The baseline of this part of the pro ject is

event E o ccurs, if the Condition C holds then

the view mechanism de ned in [1] and ex-

execute Action A".

tended in [23]. In our approach, the de ni-

In our context, rules are comp onents of

tion of a view is similar to the de nition of

an O schema; they are de ned at the same

2

aschema. A virtual schema is, like a nor-

level as typ es, classes and applications. They

mal schema, an organizational unit meantto

are thus considered at a higher level than

encapsulate a set of related intentional def-

programs, metho ds and data manipulation.

initions. The main di erence is that a real

This approach allows to control the execu-

schema describ es the structure and b ehavior tion of more general op erations than meth-

tionale of the pro ject. Wehave discussed the o ds calls or manipulation of a single entity

requirements p osed to an SDE and the way an entity is an ob ject or a value and to as-

we prop ose to tackle them. The rst inte- so ciate rules to transaction, program or ap-

grated version of the GOODSTEP platform plication executions. Rules resp ect encapsu-

is due at the end of 1994. lation and transparency: they are triggered

Currently, we are starting to use the by authorized op erations related to p ersis-

GOODSTEP platform within two case stud- tent or transiententities. Rules can b e ex-

ies. The aim of the rst case study is to p orted/imp orted b etween schemas which in-

customize the platform to an SDE for use creases reusability. Finally, for the purp ose

within typical information system develop- of programming guidelines, rules are isolated

ment pro cesses. This SDE will then b e used from programs and metho ds: a rule can b e

by an industrial partner for developmentof activated or deactivated only through rules.

an information system supp orting university The event part of a rule de nition sp eci-

adminstration. In a second case study we are es whichevents will trigger the rule. Pro-

going to customize the GOODSTEP plat- p osed eventtyp es can b e divided into two

form for use within airline software pro jects categories. The rst category is made of

of another industrial partner. These pro jects entity manipulation eventtyp es which are

reuse C++ classes from a variety of class li- generated by manipulations creation, dele-

braries. The customised SDE for this pro ject tion, up date, etc. of entities. The second

is going to supp ort the development and category is made of applicativeeventtyp es

maintenance pro cess of C++ class libraries. which are asso ciated to the b egin or end of a

transaction, an O program or application.

2

The Condition part is made up of predi-

Further Information and Acknowledge-

cates O SQL queries over entities. The

2

ments

Action part is made of any O C co de. Con-

2

Information ab out GOODSTEP including a

ditions and Actions can op erate on p ersistent

p erio dically up dated series of technical re-

or transiententities.

p orts can b e obtained via anonymous ftp

Based on the atomic transaction mo del of

from ftp.inria.fr in /pub/INRIA/Projects/Verso/GoodStep-Library.

O ,we de ned two kinds of rules: 1 im-

2

Inquiries ab out the pro ject will b e answered

mediate rules which are executed right af-

by [email protected].

ter the o ccurence of the triggering event and,

2 deferred rules corresp onding to cumula-

The memb ers of the GOODSTEP team

tivechanges on entities which are executed

and the institutions supp orting GOODSTEP

at the end of the transaction just b efore

are: S. Abiteb oul INRIA, M. Adiba Uni

its validation in which triggering events o c-

Grenoble, J. Arlow British Airways, P. Ar-

cured. The choice of rules to b e executed

menise Engineering, S. Bandinelli Cefriel,

is based on i a total rule ordering ensured

L. Baresi Cefriel, P. Breche Uni Frank-

by the system and ii on the notion of ex-

furt, F. Buddrus Uni Frankfurt, C. Col-

ecution cycle. A cycle describ es the execu-

let Uni Grenoble, P. Corte Engineering,

tion of a sequence of op erations b elonging

T. Coupaye Uni Grenoble, C. Delob el IN-

to user-de ned transaction, a program or a

RIA, W. Emmerich Uni Dortmund, G. Fer-

rule. Every execution cyle is asso ciated with

ran O Technology, F. Ferrandina Uni Frank-

2

a delta structure containing data related to

furt, A. Fuggetta Cefriel, C. Ghezzi Cefriel,

the triggering op erations considering the net

S. E. Lautemann Uni Frankfurt, L. Lavazza

e ect of these op erations. Delta structures

Cefriel, J. Madec O Technology, M. Pho enix

2

can b e accessed in Conditions and Actions

British Airways, S. Sachweh Uni Dortmund,

using sp eci c op erators.

W. Schafer Uni Dortmund, C. Souza Dos San-

tos INRIA, G. Tigg British Airways and

R. Zicari Uni Frankfurt.

5 Conclusions and Ongoing Work

In this pap er, wehave limited the presen-

tation of the pro ject mainly to show the ra-

S. Sachweh, and W. Schafer. The Go o d- References

step To ol Sp eci cation Language Ref-

erence Manual. Deliverable ESPRIT [1] S. Abiteb oul and A. Bonner. Ob jects

Pro ject GOODSTEP 6115-6P, Com- and Views. In Proc. of the ACM SIG-

mission of the Europ ean Communities, MOD Conf. on Management of Data,

Novemb er 1993. Denver, Co, pages 238{247. ACM Press,

1991.

[9] V. Benzaken, C. Delob el, and G. Har-

rus. Clustering Strategies in O :An

[2] Ada Joint Program Oce. Common

2

Overview. In [4], pages 385{410. 1992.

Ada Programming Supp ort Environ-

ment APSE Interface Set CAIS, Re-

[10] R. Cattell, editor. The Object Database

vision A. Technical Rep ort DoD-STD-

Standard: ODMG-93. Morgan Kauf-

1838A, U.S. Department of Defense,

man, 1993.

1988.

[11] C. Collet, T. Coupaye, and T. Svensen.

[3] F. Bancilhon, S. Cluet, and C. Delo-

NAOS Ecient and mo dular reac-

b el. Query languages for ob ject-oriented

tive capabilities in an Ob ject-Oriented

database systems: the O prop osal. In

2

th

Database System. In Proc. of the 20

Proc. DBPL, Salishan Lodge, Oregon,

Int. Conf. on Very Large Databases,

June 1989.

Santiago, Chile, 1994. To app ear.

[4] F. Bancilhon, C. Delob el, and P. Kanel-

[12] K. R. Dittrich, W. Gotthard, and P.C.

lakis. Building an Object-Oriented

Lo ckemann. Damokles { a database sys-

Database System: the Story of O . Mor-

2

tem for software engineering environ-

gan Kaufmann, 1992.

ments. In R. Conradi, T. M. Didriksen,

and D. H. Wanvik, editors, Proc. of an

[5] S. Bandinelli, L. Baresi, A. Fuggetta,

Int. Workshop on AdvancedProgram-

and L. Lavazza. Requirements and

ming Environments,volume 244 of Lec-

Early Exp eriences in the Implemen-

ture Notes in Computer Science, pages

tation of the SPADE Rep ository us-

353{371. Springer, 1986.

ing Ob ject-Oriented Technology. In

S. Nishio and A. Yonezawa, editors,

[13] W. Emmerich, P. Kroha, and

Proc. of the First JSSST International

W. Schafer. Ob ject-oriented Database

Symposium Kanazawa, Japan,volume

Management Systems for Construction

742 of Lecture Notes in Computer Sci-

of CASE Environments. In V. Marik,

ence, pages 511{528. Springer, 1993.

J. Lazanks y, and R. R. Wagner, edi-

tors, Database and Expert Systems Ap-

[6] S. Bandinelli, M. Braga, A. Fuggetta,

th

plications | Proc. of the 4 Int. Conf.

and L. Lavazza. The Architecture of

DEXA '93, Prague, Czech Republic,

the SPADE-1 Pro cess-Centere d SEE. In

volume 720 of Lecture Notes in Com-

B. C. Warb oys, editor, SoftwarePro-

puter Science, pages 631{642. Springer,

cess Technology | Proc. of the 3rd

1993.

European Workshop, EWSPT '94, Vil-

larddeLans,volume 772 of Lecture

[14] W. Emmerich, W. Schafer, and

Notes in Computer Science, pages 15{

J. Welsh. Databases for Software Engi-

30. Springer, 1994.

neering Environments | The Goal has

not yet b een attained. In I. Sommerville

[7] S. Bandinelli, A. Fuggetta,

and M. Paul, editors, Software Engi-

and C. Ghezzi. Pro cess Mo del Evolu-

th

neering ESEC '93 | Proc. of the 4

tion in the SPADE Environment. IEEE

European Software Engineering Con-

Transactions on Software Engineering,

ference, Garmisch-Partenkirchen, Ger-

192:1128{1144, 1993.

many, volume 717 of Lecture Notes

[8] W. Beckmann, J. Brunsmann, D. Dong,

in Computer Science, pages 145{162.

W. Emmerich, P. Kroha, W. Reimer, Springer, 1993.

UK, Lecture Notes in Computer Sci- [15] F. Ferrandina, T. Meyer, and R. Zi-

ence. Springer, 1994. To app ear. cari. Implementing Lazy Database Up-

dates for an Ob ject Database System.

[24] R. Zicari. A Framework for Schema Up-

th

In Proc. of the 20 Int. Conferenceon

dates in an Ob ject-Oriented Database

Very Large Databases, Santiago, Chile,

System. In [4], pages 146{182. 1992.

1994. To app ear.

[25] R. Zicari and C. Bauzer-Meideros. New

[16] F. Ferrandina and R. Zicari. Ob ject

Generation Database Systems. In P. Lo-

Database Schema Evolution: are Lazy

cop oulos and R. Zicari, editors, Concep-

Up dates always Equivalent to Immedi-

tual Modeling, Databases and CASE |

ate Up dates? In Proc. of the OOPSLA

An Integrated View of Information Sys-

Workshop on Supporting the Evolution

tems Development. John Wiley, 1992.

of Class De nitions, Washington, DC.

ACM Press, 1993.

[17] F. Gallo, R. Minot, and I. Thomas. The

ob ject management system of PCTE as

a software engineering database man-

agement system. ACM SIGPLAN NO-

TICES, 221:12{15, 1987.

[18] C. Ghezzi, D. Mandrioli, S. Morasca,

and M. Pezz e. A Uni ed High-level

Petri Net Formalism for Time-critical

Systems. IEEE Transactions on Soft-

ware Engineering, 172:160{173, 1991.

[19] G. Harrus, F. Velez, and R. Zicari.

Implementing schema up dates in an

ob ject-oriented database system: a cost

analysis. Technical rep ort, GIP Altair,

1990.

[20] C. Lewerentz and A. Schurr. GRAS, a

management system for graph-likedoc-

rd

uments. In Proc. of the 3 Int. Conf.

on Data and Know ledge Bases. Morgan

Kaufmann, 1988.

[21] N. H. Madhavji and W. Schafer. Prism {

Metho dology and Pro cess-Oriented En-

vironment. IEEE Transactions on Soft-

ware Engineering, 1712:1270{1283,

1991.

[22] D. Maier. Making database sys-

tems fast enough for CAD appli-

cations. In W. Kim and F. H.

Lo chovsky, editors, Object-Oriented

Concepts, Databases and Applications,

pages 573{582. Addison-Wesley, 1989.

[23] C. Santos, S. Abiteb oul, and C. Delo-

b el. Virtual Schemas and Bases. In

th

Proc. of the 4 Int. Conf. on Extend-

ing Database Technology, Cambridge,