An Object-Oriented Programming Environment for Advanced Database Applications

deposit_hagen

Publikationsserver der Universitätsbibliothek

Mathematik und

Informatik

Informatik-Berichte 81 – 07/1988

Rainer Unland, Gunter Schlageter

An Object-Oriented Programming

Environment for Advanced Database

Applications

AN

R. Unland G. Schlageter

University of Hagen

Department of Computer Science I

D-5800 Hagen, West-Germany

Abstract

For various reasons conventional database systems fail to provide appropriate support for a wide variety of applications. Therefore, new generation database systems are being developed in some recent research efforts, among them OOPS.

OOPS is an object-oriented programming system with integrated data management facilities. It is designed to especially support advanced applications, like e. g. engineering and office applications. Extensive data modelling facilities, as they are typically offered by the abstract data type concept of object-oriented languages, are enriched by advanced data management concepts. Therefore, not only abstraction mechanisms, like e.g. the concepts of classification, generalization and aggregation, are provided but also modularity (keeping logically related things together}, information hiding (hiding the im_plementation / intemal representation of objects) and extensibility and flexibility (by allowing the modification of existing and the addition of new data types {classes) and operations). Furthermore, to especially support the semantics of applications, complex integrity constraints, exceptions, and triggers can be specified. Since all these facilities are integrated into a single language the artificial distinction between database language and programming language is eleminated.

1. Introduction

The areas of database management systems, programming languages, and artificial intelligence overlap in many new application areas, as for instance in office information systems, CAD/CAM and expert systems. Available software systems do not satisfy the requirements of these new applications. From the database point of view, the discussion on "non-standard" databases shows that current database technology is unsatisfactory for many reasons, among them (see e.g.: /BaBu84/, /BBDM84/, /HMMS87/, /HaLo82/, /Ka85/, /KSUW85/, /Lo81/, /Lock85/, /LoKi84/, /Si80/):

a) Lack of more sophisticated data types

To naturally and efficiently describe the structure of complex (or molecular) objects new data types like text, time, date, list, graph, tree, set etc. have tobe provided.

b) Artificial representation of complex objects

Existing modeling techniques and their notation fail to clearly express the nature of complex objects. Often the structure of complex objects can either not be expressed or has to be designed artificially. Natural possibilities to explicitly express relationships between objects are neccessary.

c) Operational semantics of complex objects is not expressable

Existing techniques fail to capture the operational semantics (e.g. set of operations applicable to an object) that are normally associated with complex objects. Instead, this semantic is completely specified by users and buried in

their application programs.

d) Lack of powerful and efflcient trigger. constraint and event mechanisms The complexity of new application areas requires powerful and efficient trigger,

constraint and integrity mechanisms.

e) Different levels of abstraction are not supported

Different levels of abstraction which allow the user to see complex objects from a more special (i.e. the structure of a complex object is visible in detail) or a more global view (i.e. every sub-component of a complex object is treated as another obJect) should be provided.

t) Lack of eft1cient functions for object storage and retrieval

Efficient storage techniques and retrieval operations for complex objects are required.

g) Conventional transaction model is too simple

Tue conventional transaction model, designed for short and Independent transactions, is too simple for new applications. Support for lang and nested transactions has tobe provided.

h) Lack of a powerful version model

Many new application areas cannot be modeled in a sufficient way by representlng only the present state of the world. Instead it must be possible to model tirne-dependent states (time versions), different approaches to a problem (alternatives) as weil as different views of an object (representations).

Actually, one can essentially distinguish between two trends in overcoming these shortcomings:

1) Improvement of existlng (relational) database systems (see e.g /LoKi84/, /DKAB86/, /PSSW87 /, /StRo87 /).

2) Development of considerably improved database models.

Tue first approach is a step in the right direction but does not solve all problems since data modelling facilities are still limited and somewhat unnatural.

In order to satify all or at least most of the above mentioned requirements it is necessary to provide considerably improved modelling capabilities. It should be possible to model the semantics of an application in the conceptual schema, rather than in the application program. Therefore, the data model should not only provide rich and expressive capabilities to naturally model the (static) properties of an application but should also allow the defmition of the dynamic behaviour.

This includes mechanisms to define operations which describe the behavioural semantics of the data, as well as extensive integrity constraints and exceptions.

Tue activity of designing complex applications in a high-level language with features that differ considerably from those supported by traditional database systems is called conceptual modelling, its result a conceptual schema. and the language used the conceptual language / AlCO85/. One promising candidate for conceptual modelling is semantic data models (see e.g. SDM /HM8 l /, TAXIS /MBW80/, SHM+ /Br81/). Fundamental to semantic data models are relationships which are used to support abstraction mechanisms (like classification, aggregation, generalization and association). With abstraction mechanisms specific details are suppressed while those pertinent to the problem or view of information at hand are emphasized. Another often heard catchword are object-oriented data models (see e.g. ORION /BCGK87 /, IRIS /FBCC87 /, GemStone /MSOP86/, OPAL /AhBH84/). An object-oriented data model is a collection of abstract data types, with operations defined an the types, and with objects which are instances of the types. Operations and properties can be inherited by other objects. Objects can be accessed and manipulated only by invoking operations defined on their types. Data structure and details of implementation are hidden. Tue difference between semantic data models and object-oriented data models is somewhat vague. Object-oriented data models can be seen as a specialization of semantic data models in that object-oriented data models additionally provide the concept of abstract data type. The concept of abstract data type, as it 1s realized in object-oriented systems, allows an easy and natural extension of the system. Therefore, a highly flexible reactlon to changes of the real world is guaranteed even 1f the database has already been in operatlon for a langer time.

In /Ditt86/ the distinction is made between several types of object- orientation:

* structural object-orientation: the data model includes facilities to represent complex structured entities, together with operators to deal with them,

* operational object-orietation: the data model allows to define type-specific operators based on simple data elements; thus those systems provide abstract data type facilities,

* behavioral object-orientation: these data models combine both of the previous approaches: they include all the facilities necessary for complex obJects, and furthennore allows the defmitlon of abstract data types which take complex objects as the basis for their implementatlon.

When we talk about object-oriented data models we mean data models in the sense of definition 3 (behavioral object-ortentatlon).

To summarize, the main characteristics of object-oriented data models are the realization of the concepts of

* abstract data type, which provides infonnation hiding, also called (type) encapsulation,

* generalization / specialization by means of inheritance,

*

Of course, some object-oriented languages, like for example SMALLTALK /GoRo83/ or C++ (/Stro86/), offer all above mentioned features but they don't offer any possibilities to handle persistent data. Therefore, it seems to be appropriate to combine the concepts of these languages with advanced data management capabilities. In this paper we present such an approach from a project in which an integrated programming and data management system has been developed (object-oriented programming system (OOPS)). The project is a cooperation between a large German office systems manufacturer (Triumph-Adler AG) and the departments of Computer Science of the Universities of Hagen and

Aachen. A first prototype of OOPS is available which essentially satisfies all above mentioned requirements with the exception of an appropriate transaction manager. Currently. the programmer is responsible for accurately defining the beginning and the end of a transaction. Nested transactions are not supported.

Tue transaction is still the unit of recovery. However. it is planned to realize a transaction manager similar to the one presented in /KSUW85 /. This transactlon manager handles long and nested transactions. supports cooperative work of user groups on a common set of objects and allows a more flexible recovery by providing (transaction-oriented and object-oriented) savepoints. Furthermore, in a second phase a special version. alternative and representation mechanism (as described in /KSW86/) will be adapted to OOPS.

OOPS consists of three parts, the user interface, the object-oriented programming language OOPL and the database system (ODBS). ODBS forms the basis of the programming environment which means that OOPL resides on top of the database system (see fig. 1. 1). Tue user only works in terms of OOPL. Tue interface between OOPL and ODBS is mostly not visible to him. Tue user interface is QBE-like and is realized by a spreadsheet package.

Fteure 1.1: main components of OOPS

Man-Machine Interface

1

Programming System (OOPL)

1 Interface

1

Oatabase System ^(ODBS)

In the remainder of this paper we will concentrate on the conceptual modelling facilities of OOPS. The database component will only be considered briefly.

Section 2 describes the conceptual language of OOPS (called OOPL): First, we introduce the data model supported by OOPS. We then illustrate how OOPL can be used as a database programming language. Finally, we survey the data defmition facilities and the data manipulation functions.

In section 3 we briefly discuss the underlying system architecture. In particular, we present the interface between the object-oriented programming language and the database system.

Finally, in section 4 we relate OOPS to other projects in this area.

2 The Pro1Irammin1I Lanaua&ie OOPL

Currently. there is a lively discussion the features of which describe an object-oriented programming language. In /Pasc86/ Geoffrey Pascoe gives a definition which demands that an object-oriented language supports the concepts of information hiding. data abstraction (abstract data type). inheritance, and dynamic binding. Peter Wegner wants an object-oriented language to support objects. classes and inheritance (/Wegn87 /, /CaWe85/, /Wegn88/). Although not explicitly mentioned. we strongly assume that Geoffrey Pascoe also demands an object-oriented language to support classification. Since an abstract data type can be seen as an object whose state is only accessible through its operations.

therefore realizing information hiding, the differences between both definitions are the concepts of dynamic binding and information hiding. Peter Wegner only demands the realization of the concept of objects instead of data abstraction.

which means, that an object-oriented language must not necessarily support the concept of information hiding. Additionally, he does not demand dynamic binding. On the contrary, for him strong typing (together with data abstraction) forms a specialization of object-oriented languages, called strongly typed object- oriented languages. We agree witho Peter Wegner's defmition since we assume that the definition of Geoffrey Pascoe only allows SMALLTALK /GoRo83/ (and very strong related languages) tobe object-oriented. In the sense of Peter Wegner OOPL is a strongly typed object-oriented programming language. Like SMALLTALK, it is based on the concepts of objects, methods and messages.

Additionally, some other features of SMALLTALK are also realized in OOPL, although, on the other hand, there are essential distinctions between these languages. First, as already mentioned, OOPL is strongly typed. Strongly typing increases programming safety and run-time efficiency. High programming safety means to perform as much compile-time checking as possib1e (e.g. all type checks). Then, to meet the requirements introduced by "non-standard" database applications, the data modelling facilities are adapted to the requirements of advanced database systems. Another essential feature of OOPL is that it allows the formulation of triggers and constraints. Triggers invoke specified methods as a reaction to certain events (time, date, or arrival of certain messages, etc.).

Triggers and constraints enable the definition of complex semantic integrity constraints and exceptions. Exceptions, which are a special kind of triggers, allow the specification of how the system should react to specific violations

of

2.1 A brief survey of the data model

In the following we will give a brief survey of the data modeling facilities of OOPL. All defmitions given in this chapter are illustrated in the example at the end of the chapter. References to this example are expressed by see <number>

terms.

Instantiation

As usual in object-oriented systems everything in OOPL is an object, and every object belongs to exactly one (object) dass. On one hand a class is defmed as a set of instances of a specific type. Therefore, it is a realization of the concept of dassiflcation. On the other hand a dass describes the (common) properties and the behaviour of its instances (instance components) as weil as the properties and the behaviour of the dass as a whole (dass components). Properties (also named attributes) are called roles in OOPL while the behaviour of a class is described by procedures, called methods. One essential distinction between OOPL and SMALLTALK is that OOPL has a type concept. Therefore, roles {in OOPL) are type- declared while instance variables (in SMALLTALK) are not.

The way instantiation is realized is one of the major differences between OOPS and GALILEO {/AlCO85/). In GALILEO a dass only represents the structure of the objects of the dass but not the set of objects {instances).

Inheritance

As usual in object-oriented systems an inheritance mechanism is provided.

Via inheritance a class (recursively) inherits the specifications of its (unique) superdass. of the superclass of its superclass and so an. In OOPL inheritance is

strict, which means that everything defined in a superclass must be satisfied by the instances of all subclasses. too. A subclass definition, however. may refine the domain of an object but it should not override a property. The inheritance mechanism of OOPL only allows simple inheritance, which means that every object has exactly one father. Therefore, regarding inheritance, the classes of OOPL form a tree. In this OOPL differs from other approaches. like e.g. TAXIS or SDM, which all offer multiple inheritance. therefore, forming a net of classes.

Inheritance realizes the concept of generalization / specialization.

Types

OOPL distinguishes between independent and dependent (in OOPL called embedded} object-types. An independent object represents exactly one entity of the real world. This means that, on one hand, the same real world entity is represented by only one object in the database. On the other hand, the same object in the database should not represent more than one entity. This implies that every independent object is unique.

Embedded objects, on the contrary. only represent a (complex) property of an entity. These objects are therefore not objects by themselves, but only exist in the context of other objects (their Jather objects); they depend on their father. While independent objects are only included via references (see below) into any other object, embedded objects are physically included into their father objects. An example of an embedded object is the object-type TermsOjDelivery (see AJ in Part.

OOPL provides a rich range of primitive and more sophisticated data types (and, of course, operations (methods) an these types), like time, date or string, and data structures, like graph, tree, list. stack, collection, set, etc. These data types can be seen as embedded objects. Additional data types (classes) and data structures as well as operations (methods) can be defmed by the user whenever needed (extensibility).

A relationship between instances of different classes can be expressed by a special object-type, the reference-object. A reference-object allows the type- declared reference to any other instance of any class (see C). References are only used to express a relationship between two independent objects.

With the help of reference objects and embedded objects aggregation can be modelled.

Since OOPL also supports repeating group types, like the SetOJ or ListOJtype, all types of (binary) relationships can easily be ~ressed, i.e. 1: 1-, l:n- and n:m- relationships (see e. g. the role sup (C) in TermsOJDelivery in the example).

2.2 Type Concept of OOPL

In contrast to SMALLTALK OOPL has a type concept. This was felt to be necessary for reasons of programming safety and run-time efficiency (see also / AlCO85/, /MyBW80/). The claimed improvement in "user friendliness" of non- typed languages is paid for by a serious loss of programming safety which, in most real-life applications. is too hiSVl a price. Tue first prototype of OOPL adopted strong typing, whereas in a Tater version some more flexibility will be introduced to better satisfy the requirements of certain database applications.

Strang typing means that

- each object belongs to exactly one type - each variable has to be type-declared

- each occurrence has to be conform to the declaration

Types in OOPL are expressed by classes: each variable and each reference is associated with a class which defmes the corresponding values or objects.

Therefore, all context-sensitive checks as well as binding can be performed at compile-time, which obviously contributes substantially to safety and run-time efficiency.

Besides the conformity of instance and declaration corresponding objects must have the same type, for instance:

- left and right side of

än

- type of reference and type of object referred to.

This strong typing enforces that programs are complete at compile-time as far as object declaration is concerned. Of course, this reduces programming flexibility: however, in OOPL an environment is offered which supports the compilation of small parts of a program. This releases the programmer from the burden of changing environment whenever compilation and linking of a program is needed due to a {small) change. The design goal was to get the safety of complete compilation while allowing as much flexibility as possible.

As usual in object-oriented systems classes (and therefore types) can be related by the mechanism of inheritance. A subclass inherits the methods and roles of the superior class. Methods may be redefined in this process. roles can only be restricted.

The inheritance relationship between classes is of great practical interest.

However, to be able to exploit the concept to the required extent, the typing concept must be slightly weakened: Strang typing means that each object has exactly one type, i.e. it has a certain set of roles and methods. However, when modeling class hierarchies, another view is appropriate: if the special properties of an object of a subclass are not considered, it has the structure defined by the superclass. Hence, this object belongs to its class and to its superclass, etc. This abstraction, called generalization, is of great importance for database applications, and thus, this deviation from strong typing is mandatory.

2.3 OOPL as Database Proerammtne Laneuaee

The main application area of OOPL is its use as a database programming language. Usually, database applications are written in a general purpose programming language in which a database sublanguage (for instance SQL) is embedded. The prob1em with having two languages is "impedance mismatch"

/CoMa84/. This means that the data language and the programming language may support widely different programming paradigms. Moreover, the languages may support different structures, so that these structures may be lost at the interface. As an example, consider SQL and COBOL: as COBOL can only operate at the tuple level, the relational structure supported by SQL is lost.

One design goal of OOPL was to offer a homogeneous programming system which integrates concepts for data management and generaf computing. The programmer no langer has to know any database concepts (with the exception of the notion of a transaction, which is not only a database concept). He only works in terms of data structures (objects) which can either be temporary or permanent (see below).

OOPL distinguishes between permanent and temporary objects. The distinction is made by the programmer who declares classes to be either local (to his program) or permanent. Only permanent objects are maintained in the database. Local objects are maintained in the local object memory. They live as long as a main memory reference to them exists, they are removed, at the latest, at the end of the application program.

OOPL also supports the concept of an identifier (called nominaton. Any attribute combination of a complex object can be specified as a nominator.

Additionally, the system provides a systemwide unique identifier which is accessible to the user, too. The identifier can be used to express a relationship of an object to another object (e.g. object-subobject relationship).

Of course, besides the outlined programming interface an interface for the non-programmer has tobe provided. This interface is QBE-like, but will n0t be discussed here in more detail.

Object Definition and Object Manipulation

In the following we explain a dass declaration in OOPL and how objects and methods are defined by the use of dasses. In the example the entity Part

describes artides available for delivery by a commision agent. To not swell the example only a meaningful extract of the ^Part object-type is presented (only a few instance methods are listed in particular).

A dass dedaration consists of four components:

* dass header - dassname /

kind of dass - superdass

* instance components - nominator

- instance roles - instance methods

* dass components - dass roles

- dass methods

* constraints and triggers

The dass components describe all features conceming the dass itself while the instance components describe the property and behaviour of every single instance of the dass. Therefore, dass components realize a concept very similar to the concept of metaclass in TAXIS (and some other approaches). A metadass in TAXIS can be defmed over a number of different dasses while a metadass in OOPL only describes the characteristics of one class.

Besides the function of a dass to define property (structure) and behaviour of objects, the following feature is important: a class represents the set of objects of a type (the instances) stored in the database. In addition, the dass protocol defines operations which allow to access these instances via keys or conditions.

As these access operations are supported by the database system, the programming language is at the same time a database programming language, and a separate database language is no longer required.

Class Header

In the example the class header of the class Part (1) defines Part as to be permanent and as to have no superclass other than the universal superclass Object (2). The class TermsOjDelivery (C) is embedded, which means that TermsOjDelivery only exists in the context of Part.

Class Roles

The dass components of a class are declared in the class section (3 and 4).

Part has one class role, called lastPartNo (3), in which the highest part number used so far is stored. The initial setting of lastPartNo is 0, (i.e., when the class is defmed, lastPartNo gets this value). Afterwards, lastPartNo is incremented by the class method createPartNo every time a new instance of Part is created.

Instance Roles

Part objects have several roles. Some roles are marked as public (pub). These may be accessed and updated from outside the object via dotnotation (object- reference.roleName). All other roles are private which means that they are hidden within the object. Hence, these roles are not known outside the object, and they can only be accessed by the methods of Part.

Roles may get initial values at creation time automatically. These initial values may be computed by sending messages to other objects or classes. For instance, to determine the value of partNo, the message createPartNo is sent to the class Part which starts the corresponding method (Sa). The result of this method (a new part number) is assigned to the role partNo of the newly created object.

Every role has a specific type which may be system-defmed, like e.g. partNo (5a). which is of type Integer. or user-defined, like e.g. price (5b). which is of the user-defined type US$ (the type US$ is explicitly defined somewhere else in the program (b1;1,t not insi9e the e~ple)). A lot of important classes are predefined (integer. strtng. date. time ... ). wh1ch are dealt with as embedded classes.

The type of the role listOjDelivery (Sc) is defined by the type constructor ListOf. listOjDelivery therefore declares a set. composed of an arbitrary number of (homogenous) objects of the type TermsOjDelivery. The objects are ordered as a list. Other type constructors are ArrayOf, SetOf. DictionaryOf, etc., all providing special operations to deal with these data structures (list operations, search operations. etc.). The data structures prevent the database designer from artificial normalization. Among others. they are a means for representing multivalued roles. Especially, they can be used for representing all kinds of relationships between objects.

The role location (5d) refers to a set of Stock(s), namely all stocks where this part is stored (n:m-relationship). Since Stock is an independent (non-embedded) class SetOf Stock is a set of references to instances of Stock (and not a set of instances of Stock). Stock is defined outside of this example.

All instances of a (permanent) class are disjoint. Therefore, every instance can uniquely be identified by a combination of roles, called nominator roles. The nominator is a user-defined identifier which can be used for direct access to objects. Part has the nominator partNo (6).

To summarize, OOPL distinguishes between primitive, reference, composite and derived types. Primitive types are irreducible in that they cannot be decomposed (e.g., 5a). Reference types refer to an other (independent) object (e.g., Sc, 5d, B). Embedded objects are mostly complex, therefore representing a composite object-type. The value of a derived object-type is automatically computed from other information in the database whenever-the object is accessed (e.g. C). Of course, derived objects can not be updated.

Object Manipulation

As in any object-oriented system the access to objects as well as their modification is realized by methods.

Methods consist of two components:

- method.filter block - method. bod.y block

The method ftlter block (marked by round brackets) consists of the specification of the message which activates the method (method.filter, underlined in the example), and the according parameters (which are typed in OOPL) together with their types.

The method body block contains the defmition of the internal variables as well as the method. bod.y which is a sequence of messages and assignments. The method body block is represented in square brackets.

The result of the execution of a method is either an object which is transferred to the sender of the activating message (fimction method), or a modification of the receiving object (procedure method.). In the case of a function method the type of the resuit-object is defined after the method ftlter block (4).

Besides ihe definition of a method OOPL offers another possibility of accessing roles of a class: if a role is declared to be public, it can be accessed via

"dot notation" (i.e. there exists an implicit method which returns the value of the role). In a similar way a public role can be modified (i.e. there exists an implicit method ".rolename:=" whlch assigns a value to the role). This mechanism makes the language easier to use, especially in database applications where single elements have to be modified very often.

An important concept, extensively discussed in the database area, is the concept of a transaction. In OOPL transactions are started and finished by special messages send to a system component (BOT- and EOT-message). As methods call other methods in a nested way, transactions also become nested, so that - as an extension to current database technology - nested transactions can be supported by the system. The prototype system, however, deals only with one level transactions.

Class Methods

The dass method createPartNo (4) has no parameters and is an example of a function method. After its execution it retums a value of type integer.

Instance Methods

The (instance) methods of the class Part define the possibilities of accessing and manipulating objects (roles) of this type. The methods guarantee a high level of integrtty, as they can be used to form complex operations which preserve the semantics of the objects. In our example all methods are procedure methods. The first two methods expect a parameter of type integer. They increase the number of reserved parts (7a) and the parfs in stock (7b) while decreasing the number of parts on order (7b). The last two methods are defined to allow insertion in (7c) or deletion from (7d) listOjDelivery. Therefore, they expect a parameter of type TermsOjDelivery.

If no method is defined to manipulate a role this role is not changeable. In our example the role partNo (5a) cannot be altered.

Constraints and Trliiers

Since OOPL is strongly typed and the user is allowed to define arbitrary types a lot of integrity constraints are already defined during object definition. These integrity constraints are called implicit and can be completely checked at compile- time. In contrast, explicit integrity constraints may lead to run-time checks. This type of integrity constraint is defined in the constraint-section (8) of the dass declaration. Each constraint is given a name (8a), is associated with a trigger which specifies the condition which leads to a check of this constraint and it consists of a block which evaluates to true or false (8c). Furthermore, in cases where the constraint depends on the access of one or more roles all roles are specified whose access initiates the execution of the constraint (8b). The execution can be trtggered at the beginning or the end of the modifying method or transaction (Sd). By this, preconditions as well as postconditions for methods or transactions can be defined. If a condition is defined for a transaction and this condition is violated by executing a method outside of a transaction than the violation is ignored. The constraint and rule concept is very similar to the prerequisite / postcondition and exception concept of TAXIS.

In cases where an integrity violation is detected, the method (transaction) is not executed (precondition violated) or the modifications performed by the corresponding method (transaction) are undone (postcondition violated). However, there is also the possibility to specify in the rule-section (9) how the system should react in the case of an integrity violation. If the constraint 'sufficientStocks' of the example is violated, the exception 'violationSuffientStocks' is executed which issues an appropriate order to the cheapest supplier to restore the required number of parts {9a). In 9b the variables are defmed which are used in the method. In 9c the smallest current price is calculated ^(min is a system- defined set operation working on a homogeneous set). In 9d the cheapest supplier is determined. Therefore, the first instance of TermsOjDelivery out of listOjDelivery is decided which fulfills the. predicate that its current price is equivalent to the minimum price. In 9e the order to supply as many parts as specified in optDelivery-Quantity is given to the supplier decided in 9d.

onOrderAt: article: volume: is a method which is defined in the class Supplier (outside of the example). Finally, the number of parts on order is increased (9f1.

Triggers are not only activated by integrity violations but also by other events:

- time (9g) - date (9h) - arrtval of a message - access to a role - write-access (modification) to a role (9i, C)

In B the current price of the part is decided whenever an access to currentPrice takes place. Triggers can either be defined in the rule section or, if the trtgger affects a single rofe only, in the role section (C).

Example

- - - c l a s s h e a d e r - - - - -

1 class permanent Part

2süpe.rciäss· ··· ·· · ·· ·abJe.ci" ··· ... ·

- - - c l a s s roles/methods--

3classRole lastPartNo : Integer on creation <- O;

4ciässMeiii'öci···

(createPartNo) : Integer

[/astPartNo <- lastPartNo + 1; "lastPartNo;];

- - - i n s t a n c e roles/methods Srole

a

b

C

d

partNo: Integer on creatlon <- PartcreatePartNo;

pub partName: Strlng [20];

pub sellingPrice : US$;

costPrice : US$;

listOfDelivery. LlstOf TermsOfDelivery, minimumStocks : Integer;

stocks : Integer;

onOrder: Integer:

reservedStocks : Integer;

location : SetOf Stock;

6nomlnator partNo 7method

a (reserved: number : Integer)

[reservedStockS<-reservedStocks + number;];

b (delivery: number: Integer) [onOrder<- onOrder- number:

stocks <- stocks + number:);

c (extendlistOfDeliveryBy:del: TermsOfDelivery) [listOfDelivery add: del];

d ( remove FromlistDelivery :del: TermsOfDelivery) [ listOf Delivery Includes: del

lfTrue: [listOtDelivery remove: del]);

- - - c o n s t r a i n t s / t r i g g e r s Sconstralnt

a sufficientStocks

b on modlflcatlon stocks, reservedStocks, onOrder, minimumStocks

c [(stocks - reservedStocks + onOrder) > minimumStocksJ d at EndOfTransactlon

... ^~ ... .

9rule

violationSuffientStocks a on vlolatlon sufficientStocks

b [delivery: TermsOfDelivery, minimumPrice: US$;

c minimumPrice<-listOfDelivery rnln:curPrice d delivery <· listOfDelivery

uslng supp

select [supp.curPrice = minimumPriceJ flrst;

e onOrderAt: delivery.sup article: seif

g

h

voiuine : delivery.optDeliveryQuantity

onOrder <-onOrder + delivery .optDeliveryQuantity];

dailyReport on time = 17:00

[ /* do daily report */ ]:

stockTaking

on date = 12/31 /????

[ /* do stock-taking */ ];

adaptCostPrice

on modlflcatlon sel/ingPrice [ /* adapt costPrice */ ];

Aclass embedded TermsOtoelivery superclass Object

role B pub

pub pub

C pub pub

sup : Supplier;

wholeSalePrice : US$;

optoeliveryOuantity : Integer;

curPrice : US$ on access <-

sup.country.currentRate ·wholeSalePrice;

suppDiscount : Integer;

bold type : reserved words

underiifled : user-defined method filter

italics : user-defined objects (classes, roles)

3. The system architecture of OOPS Figure 3.1: The architecture of OOPS

PROGRAMMER INTERFACE

object- Interpreter

oriented

1 system

Com- System Object

piler Cache Cache

oos

(Object-Oriented)

Database System Data Dictionary ODBS

The basis of the programming system is a specially tailored database management system offertng a one object at a time interface. The database not only contains all data objects but also all meta information needed for describing them, all methods and all system information. On top of the database system resides the object oriented system (00S) which implements the features of OOPL.

The programmer only works in terms of OOPL. i.e. the programming interface is based on the mechanism of sending messages to objects.

In the following we briefly describe some components of the system.

The programmer interface

The programmer is allowed to define new classes. to modify existing ones or to implement or modify methods.

To define a new class (or method) means to instantiate a new object of the class dass (or method) and is therefore done by sending an appropriate message to dass (or method).

Every method is stored as an instance of two classes - after its definition or modification it is stored in the class sou.rce-methods and after its successful compilation its translated intermediate code is stored in the dass compiled- methods. In any case. a new method is automatically compiled when it is invoked the first time. Additionally, a method is given to the programmer to explicitly compile a new or modified method to ensure that it works correctly and to avoid later compilation during run-time of an application program.

The object oriented system (00S)

Tue OOS consists of four components, an interpreter, a compiler, a system cache and an object cache.

The compiler ·

Since a type concept is established in OOPL a compiler is necassary to fully exploit this feäture. Before a method is interpreted it is compiled frrst. Among others, all context sensitive checks are performed during compilation. The result of compilation is an intermediate code which is the basis for the interpreter.

The system cache and the obiect cache

Any information OOS deals with is represented as an object. On one hand there are data objects needed by the applications, on the other hand there are methods, structure and system descriptions. Since the use of these two kinds of objects is different the parts currently needed of these objects are stored in different cashes - data objects in the object cache, all other objects in the system cache.

Since both caches contain only objects, the same basic maintainance mechanisms can be used for them. With these operations the interpreter is able to find objects in a cache and to handle cache overflows.

Every time the system is initialized a basic set of structure descriptions, system information and methods is loaded into the system cache. Tue object cache remains empty. Additionally needed system information, as well as all data objects. are loaded into the proper cache on request.

Ta minimize access time to a complex object the interpreter does not always load the complete object from the database. For example, if only fixed length data are accessed, the variable length parts of the object will not be loaded.

Tue function of a cache manager is taken on by the interpreter. Therefore, if a cache overflow occurs, the interpreter decides which (part of an) object has tobe removed. If this object has been modified, it is sent to the database. Tue logical transfer unit between 00S and the database is an object (or apart of an object), and not a page.

The interpreter

Tue interpreter is responsible for receiving, interpreting, executing and answering a message.

In more detail a message - consisting of a receiver object and a method protocol (the identifier of a method) - is treated as follows:

Step 1: searchlng for the appropriate method (and structure description) First, the interpreter accesses the system cache. By examining the dass of the receiver object the appropriate method is determined. If the method cannot be found in the cache it is loaded from the database. As a result of the access to the system cache the method body (that part of the method that contains the

is sent. If the method body is already compiled (is a member of the dass

compiled-methods) the compiled method body is returned. Otherwise the method body is sent to the compiler first.

Step ^2: searching for the receiver object

If the method is ^a class method, the receiver is an object representing a dass description and is therefore loaded from the system cache. Otherwise it is loaded from the object cache.

Step 3: executing a method

The method to be executed either embodies some messages or is a primitive method (a basic method which cannot be divided into submethods). In the first case the interpreter again handles the messages in a recursive way. Otherwise the primitive method is executed. If an access to the database is necessary, this is done under control of the interpreter. lt translates the message into a sequence of database commands and controls the execution of these commands.

The (object-oriented) database system (ODBS)

The programming system resides on top of a database management system which is responsible for the maintenance of all permanent objects. The architecture of the actual DBMS is similar to any modern DBMS, but was specially tailored to the needs of the programming system.

· Besides the storage of all (complex} data objects, ODBS also maintains all information needed by the programming system in the data dictionary. Mainly, the dictionary contains the descriptions of the logical structure and the physical representation of all objects of the programming system as well as all methods for these objects.

To allow easy modification of the conceptual schema versions of object descriptions are supported. By this version mechanism the conceptual schema can be modified online in a simple way without costly reorganization of the database.

In accordance with the data defmition possibilities of OOPL objects may have a structure or may be of variable length (i.e. text). ODBS explicitly supports both types. Complex objects are stored as one unit (no splitting into sub-components as for example sub-relations).

As modern hardware provides large main memory sizes we took advantage of this feature and implemented a version of the database cache method /E1Ba84/.

This technique integrates buffer management and recovery methods in such a way, that undo/redo operations are no langer necessary and thus leads to an essential performance enhancement.

4. Relation to other work

Object-oriented languages have received considerable attention in recent years. This can for example be seen by the fact that there might exist more than fifty object-oriented programming languages (/StBo86/). Such languages are typically main memory resident and they realize single-user systems. Of course, there have been some approaches to augment object-oriented languages to maintain large numbers of objects. One example is LOOM (/KaKr83/} which is an object-swapping virtual memory system especially designed to support SMALLTALK in managing large volumes of objects. LOOM does not provide a multi-user facility Another approach is GemStone /MSOP86/. Like OOPS GemStone also integrates database concepts in an object-oriented language (SMALLTALK). Although GemStone supports the rich data modelling facilities of SMALLTALK the database concepts are rather conventional. There are no mechanisms to define integrity constraints or trtggers. The transaction model is very similar to today's transaction models {no nested transaction, the unit of recovery is a transaction). Another essential distinction between OOPL and GemStone is that OOPL is strongly typed while GemStone is not.

A more sophisticated approach to combine an object-oriented language and a data~ase _sy~tem is 12resented in ~RION /BKKK87 /. ORION especially supports ml:1-ltimedia 11;1formation such as 1mages and audio. lt also supports versions of obJects. While ORION offers excellent capabilities for the storage and representation of multimedia objects it neglects for example transaction management. recovery and semantic integrity.

Besides the strong influence of object-oriented languages, the design of OOPL has also been influenced by conceptual modelling. OOPL borrows features such as the integrity constraint and exception mechanism · from TAXIS. But there are also some important distinctions between both approaches. TAXIS is primarily designed for application systems that are characterized by large volumes of transactions that are short, of predictable structure, and update intensive (/MBGW84/). This application area differs substantially from that one planned for OOPL. Accordingly, TAXIS does not support long transactions or enhanced recovery mechanisms. Although these features are actually not implemented in the first prototype of OOPL their implementation has already been prepared and will be realized in the second phase.

Of course, there exist more projects which run parallel to our project and which realize concepts similar to ours. To mention some more, there are for example GALILEO / AlCO85/, which has been mentioned ealier in this text, IRJS /FBCC87 /, PRJMA /HMMS87 /, OPAL /AhBH84/, PROBE /DaSm86/ and VBASE (/ AnHa87 /). Common to all these approaches is the fact that they offer rich data modelling facilities. Differences are essentially in the realization of the behavioural or dynamic aspect of data modelling and in the consideration of semantic integrity constraints, triggers and appropriate transaction management.

5. Conclusion

We have presented an object-oriented programming environment which integrates basic concepts from object-oriented languages with concepts from the area of databases. The environment offers all functions of a modern database in an integrated way, especially rich data modelling facilities and a powerful trigger and semantic integrity mechanism. The programmer only works ⁱⁿ terms 01 the programming language. Therefore, the arlifical distinction between programming Ianguage and database language is no langer existent. In (/B1Zd87 /) it is said that the integration of a general programming language and a database programming language is a laudable aim but that both language types also have great (and partly opposite) differences in philosophy. Even ooject-oriented languages, which support the organization of software around data objects, rather than around ffow control, still emphasize the behaviour of objects. The handling of large amounts of shared, persistent data is still a minor subject. Of course, this statement and other statements in the paper are true and also valid for our approach. Since we want OOPS to mainly support data intensive applications in an excellent way, it tends to be above all a powerful database programming language. Systems which focus on processing, rather than on {persistent) data, should not be written in OOPL.

To summarize, OOPS offers the following main characteristics:

- it integrates concepts for data management and general computing, therefore offering a homogenous interface

- it is strongly typed, therefore offering high programming safety and run-time efficiency

- it provides a comprehensive set of system-defined data types,

- it allows the distinction between embedded and independent object-types,

- it supports the design of all kinds of complex objects, references cari be defmed naturally,

- a system-defined and user-defined identifier-concept is provided,

- the operational semantics of complex objects can be expressed via methods, new methods can be added whenever needed,

- the concepts of classificatlon (instantiatlon). generalizatlon (inheritance).

aggregatlon and metaclasses are realized.

- it offers modulartty. information hiding, extensibility and flexibility.

- different levels of abstraction (views) can be defined by implementing appropriate methods.

- constraints and triggers can be defined, therefore establishing a powerful mechanism to define semantlc integrity constraints and exceptions.

Some of the issues that require further conceptual and/ or implementational work are

- the type concept (type hierarchies) and its relation to query facilities (a good introduction to this problem is given in /BaKK.88/).

- the transaction concept, for instance: nested transactions. transactions and hierarchical objects,

- the integration of programming tools.

- protection mechanisms,

- an improved support of events which are of great relevance especially in the office automation area,

- management of versions, alternatives (also called variants). and representations.

The system is implemented as a prototype on M32 UNIX-computers of Triumph-Adler AG. The development took more than 25 man years, the code

comprises appoximately 80 thousand lines of code. Currently, experiments are being made conceming the use of the language environment and the performance of the system. The project started at the end of 1983.

Acknowledgement

We are indebted to the other members of the OOPS Project, namely M. Nagl from the University of Aachen, G. Maul and her group, R. Zieschang and his group.

both from Triumph-Adler AG, and W. Wilkes and R. Meyer from the University of Hagen.

Literature

/AlC085/ Albano, A., Cardelli, C., Orsini R.: Gallleo: A Strongly Typed, Interactive Conceptual Language. ACM TODS 10, June 1985

/AnH.a87/ Andrews, T.; Harris, C.: Combining Language and Database Advanta- ges in an Object-Oriented Development Environment, Proceedings ACM OOPSLA. Okt. 1987

/AhBH84/ Ahlsen, M.; Bjornerstedt, A.; Hulten, C.: OPAL: An Object-Based Systemfor Application Development, IEEE Database Engineering, Vol. 7, No.

4, Dec. 1984

/BaBu84/ Batory, D.S., Buchmann, A.P.: Molecular Objects, Abstract Data Types and Data Models: A Framework, Proc. 10th VLDB, Singapore, 1984

/BaKK88/ Banerjee, J.; Kirn, W.; Kirn, K.-C.: Queries in Object-Oriented Databases, Proceedings Fourth International Conference on Data Engineering, Los Angeles, Feb. 1988

/BBDM84/ Brodie, M., Blaustein, B., Dayal, U., Manola F., Rosenthal A.:

CAD/CAM Database Management, IEEE Database Engineering Newsletter, Special Issue on Engineering Data Management, July 1984

/BCGK87 / Banerjee, J.; Chou, H.T.; Garza, J.F.; Kirn, W. et al: Data Model Issuesfor Object-Oriented Applications, ACM TOIS, Vol. 5, No. 1, Jan. 1987 /BlZo87 / Bloom, T.; Zdonik, S.o: Issues in the Design of Object-Oriented

Database Programming Languages, Proceedings ACM OOPSI.A, Okt. 1987 /BoMS84/ Borgida, A.; Mylopoulos, J.; Wong, H.: Generalization / Specialization

as a Basis for Software Speciftcation, from 'On Conceptual Modelling'. M.

Brodie, J. Mylopoulos, J. Schmidt (editors), Springer Verlag, 1984

-'-,

/Br81/ Brodie. M.: On Mcxlelling Behavioural Semantics of Data, Proc. 7th \!LDB Conference. Cannes. France. 1981

/CaWe85/ Cardelli. L.; Wegner, P.: On Understanding Types, Data Abstraction, and Polymorphism. Computing Surveys, Vol. 17, No. 4, Dec. 1985

/DaSm86/ Dayal. U.: Smith, J.: PROBE: A Knowledge-Oriented Database Management System. from 'On Knowledge Base Management Systems', M.

Brodie, J. Mylopoulos,(editors), Springer Verlag, 1986

/Ditt86/ Dittrich, K.R.: Object-Oriented Database Systems, from 'Entity- Relationship Approach', S. Spaccapietra (Editor), Elsevier Science Publishers B.V. (North Holland), 1986

/DKAB86/ Dadam, P.: Kuespert, K.; Anderson, F.; Blanken et al: A DBMS Prototype to Support NF2-Relations: An Integrated View on Fiat Tables and Hierachies, Proc. ACM SIGMOD, Washington, 1986

/DKLy85/ Derrett, N.; Kent, W.; Lyngbaek, P.: Some Aspects of Operations in an Object-Oriented Database, IEEE Database Engineering; New York, Vol.8, No.

4, Dec. 1985

/DMBC87/ Dayal, U.; Manola, F.; Buchmann, A.; Chakravarthy, U. et al:

Simplifying Complex Objects: The PROBE Approach to Mcxlelling and Querying Thern, Proc. Second GI-Conf. Database Systems in Office, Engineering and Scientific Environments, Darmstadt. Germany , 1987

/E1Ba84/ K. Elhardt, R. Bayer: A Database Cachefor High Peiformance and Fast Restart in Database Systems. ACM TODS, Val 9, No 4, Dec. 1984

/FBCC87 / Fishman, D.; Beech, D.; Cate, H.P.; Chow, E.C. et al: IRIS: An Object- Oriented Database Management System, ACM TOIS, Vol. 5, No. 1, Jan. 1987 /GoRo83/ Goldberg, A., Robson, D.: Smalltalk-SO The Language and its

implementation, Addison-Wesley Publishing Company, 1983

/HaLo82/ Haskin, R.L., Lorie, R.A.: On Extending the Functions of a Relational Database System, Proc. ACM-SIGMOD, 1982, pp. 207-212

/HM81/ Hammer, M.; McLeod, D.: Database Description with SDM: A Semantic Mcxlelling andAnalysis, ACM TODS, Vol. 6, No. 3, Sept. 81

/HMMS87/ Härder, T.; Meyer-Wegener, K.; Mitschang, B.: Sikeler, A.: PRIMA - a DBMS Prototype Supporting Engineering Applications, Proc. 13th VLDB Conference, Brighton 1987

/Ka85/ Katz, R. H.: Iriformation Management Jor Engineering Design, Springer publishing, 1985

/KaKr83/ Kaehler, T.; Krasner, G.: WOM - Large Object Oriented Memory for Smalltalk-SO Systems, from 'Smalltalk-SO, Bits of History, Words of Advice', G. Krasner (Editor), Addison Wesley, 1983

/KSUW85/ P. Klahold, G. Schlageter, R. Unland, W. Wilkes: A Transaction Mcxlel Supporting Complex Applications in Integrated Information Systems.

Proceedings of ACM-SIGMOD 1985, Austin, Texas

/KSW86/ P. Klahold, G. Schlageter, W. Wilkes: A General model for Version Management in Databases, Proceedings 12th VLDB 1986, Kyoto, Japan

/Lock85/ P. Lackemann, et. al.: Requirements of technical applications to data base systems, (in German), Annual Meeting

oI

/Lo81/ Lorie, R.A.: Issues in Database for Design Application, Proc. of the IFIP Conf. on CAD Data Bases, North-Holland, Publ. Co, 1981

/LoK184/ Lorie, R.A., Kirn, W.: Supporting Complex Objects in a Relational System Jor Engineering Design, IBM Research Report, IBM Research Laborat01y, San

Jose, Califomia, 1984

/MBGW84/ Mylopoulos, J.; Borgida, A.; Greenspan, S.; Wang, H.: Iriformation System Design at the Conceptual Level - The TAXIS Projekt, IEEE Database Engineering, Val. 7, No. 4, Dec 1984

/MyBWS0/ Mylopoulos, J., Bernstein, P.A. and Wang, H.K.T.: A La.nguage Facility for Desiging Database-Intensive Applications. ACM TODS, June 1980 /MSOP86/ Maier, D.; Stein, J.: Otis, A.; Purdy, A.: Development of an Object-

Oriented DBMS, Proc. ACM OOPSI.A, Sept. 1986

/Pasc86/ Pascoe, G.: Elements of Object-Oriented Programming, Byte, Aug. 1986, page 139 - 144

/PSSW87 / Paul. H.B.: Schek, H.J.: Scholl, M.H., Weikum, G.: Architecture and Implementation of the DARAISTADT Database Kernel System Proc. ACM SIGMOD, San Francisco, 1987

/S180/ Sidle, T.W.: Weakness of Commercial Data Base Management Systems in Engineering Application, Proc. of 17th Design Automation Conf., Minneapolis 1980, pp.57-61

/StBo86/ Stefik. M.: Bobrow, D. G.: Object-Oriented Programming: Themes and Variations, The AI Magazine, Vol. 6, No. 4, 1986

/Stro86/ Stroustrup, B.: The C++ Programming Language, Addison Wesley, Reading MA. 1986

/StRo87 / Stonebraker, M.; Rowe, L.: The POSTGRES Papers, Electronic Research Laboratory, College of Engineering, University of California Berkeley, Memorandum No. UCB/ERL M86/85, June 1987

/UWSZ88/ Unland, R.; Wilkes, W.; Schlageter, G.; Zieschang, R.; et. al.: OOPS - An Object-Oriented Programming System with Integrated Data Management Facility, Proc. 4th International Conference on DATA ENGINEERING, L.A., USA, 1988

/UnSc88/ Unland, R.: Schlageter, G.: An Object-Oriented Programming Environment Jor Advanced Database ApplicatiDns, to appear in: Journal of Object-Oriented Programming, SIGS Publications, New York, USA. 1988 /Wegn87 / Wegner, P.: Dimension of Object-Based Language Design, Proceedings

ACM OOPSLA, Okt. 1987

/Wegn88/ Wegner, P.: Perspectives on Object-Oriented Programming, Tutorial 21th Annual Hawaii Intern. Conf. on System Sciences, Kona, Jan. 1988

·\