Complex and Composite Objects in CAD/CAM Databases

deposit_hagen

Publikationsserver der Universitätsbibliothek

Mathematik und

Informatik

Informatik-Berichte 80 – 04/1988

Gunter Schlageter

Complex and Composite Objects in

CAD/CAM Databases

Abstract

in CAD/CAM Databases*

W. Wilkes, P. Klahold, G. Schlageter

FernUniversität Hagen Praktische Informatik I

Postfach 940 D-5800 Hagen West Germany

An essential modelling concept for CADICAM databases is the composition relationship which relates a superior composite object to its components and makes the component' s data visible in the composite object. In order to import only the necessary information into the composite object, often an interface object is defined which is copied into the composite object as an abstraction of the component. In this paper an object oriented model is introduced which comprises an inheritance relationship between an inheritor object and a transmitter object. The inheritor object inherits (the existence of) attributes of the transmitter object, but moreover it also may inherit the attributes' values. This inheritance relationship can be used to model the notion of interface of an object as weil as the composition relationship. Thus, by using the only concept of value inheritance it is possible to model all aspects of the composition of objects. Furthermore, some severe drawbacks of a rigid interface concept can be overcome by the inheritance relationship.

1. Introduction

Data modelling in new fields of database applications requires the representation of more complex objects than in conventional applications. Thus, it is not sufficient to have only flat tuples (as in relational databases). Considerably more complex data structures are required to support application-oriented data modelling. This lead to the development of more powerful data models.

Some extended the relational model for managing hierarchical tupels (e.g. XSQL [HaLo82], NF2- relations [ScSc86], [Dada86]), others built objects out of networks of subobjects (e.g. molecules [Mits87] and molecular objects [Babu84], [BaKi85]). By these models it is possible to represent complex structured objects as one unit which is known to the system.

However, it is not sufficient to build up complex objects by local objects only. lt is important, especially in design applications, to design individual components of complex products independently. Particularly, the individual parts must be used in different products to allow unit constructions. Hence, besides the building of complex objects by local subobjects, the data model has to provide mechanisms to import infonnation from different individual component objects into composite objects. Usually, not all data of the component is imported into the composite object.

* The work presented in this paper was supported by IBM Germany.

Instead, interface objects are defined which can be regarded as abstractions of several implementations (versions) of design objects. Tue interface consists of data common to all versions, and usually, only the interface data of a component are imported into the composite object.

The definition of an object model should be based on a small number of basic mechanisms. Besides the ease of use an important reason for this is the possibility to implement a database kemel supporting the basic mechanisms of the object model more efficiently. More complex mechanisms can then be built by using the basic building blocks of the model. With this idea in mind we discuss the characteristics of interfaces and composite objects in section 2 more deeply. We shall see that the two modelling concepts of interfaces and composite objects are based on one basic mechanism, an inheritance relationship between objects. The inheritor object in this relationship inherits not only the existence of attributes (inheritance at the type level, generalization) but the values of the attributes as weil (inheritance at the object level, object generalization [Wilk87]). Thus, by providing the basic mechanism of inheritance relationship, interfaces and composite objects can be represented in the object model.

After this discussion, an object-oriented data model will be introduced which comprises the inheritance relationship as an integral mechanism. Its basic concepts are objects and relationships (section 3). Objects can become rather complex, they may have local subobjects which are related by local relationships (comparable to molecular objects [BaBu84], [BaKi85]). This basic model can be compared to the extended NF2-data model [PiAn86] with the extension of explicit descriptions of network relationships. By integrating the inheritance relationship into this basic model it is possible to represent interfaces and component relationships (section 4). Moreover, by identifying the basic mechanism behind the two concepts we get more freedom in using them. This results in a generalization of the notion of interface and in more flexible mechanisms for specifying the data which a component imports into the composite object.

Section 3 and 4 use the definition of logical gates as a general example, and gates will be redefined several times to illustrate the different concepts of the object model. Section 5 gives a further example from the field of steel construction which especially shows the importance of relationships in representing complex assembly mechanisms. Finally, some further aspects of composite objects are briefly discussed: Version management and concurrency control (section 6).

2. Characteristics of interfaces and composite objects

Particularly with CAD/CAM, an independent development of individual objects is important to make sure that highly complicated products, such as cars, aeroplanes, VLSI-chips or software- systems can be manufactured by means of work specialization. Especially important is the reusability of already designed parts [IEEE87]. Hence, the data model has to offer a component- relationship so that independent components can be incorporated into a complex object which then is called a composite object.

The incorporation of independent components into a composite object can be regarded in two ways:

1. Configurations of composite objects:

Which components does a composite object have, which components do its components have, etc.? These questions must be asked with particular consideration of configuration control which is concemed with the problem of providing all components of an object ([KaCB86], [DiLo85], [SVCC88]).

2. Import of data from the component into the composite object:

How can the component be incorporated into the composite object, which kind of information does it provide, how is the information transported into the superior object? These questions have to be answered when design-objects are to be represented completely by the qbject model, rather than being stored into a database as not-interpreted data. This problem is normally approached by the interface concept ([Baki85], [MLNB83]).

Above all, this paper deals with the second aspect of the composition-relationship, and it aims at . modelling the flow of information from the component to the superior object.

One possibility to transport the information of a component C into the superior object O is to define a local subobject in O into which C is copied. The complete information of C is now stored in O as weil, and C can be incorporated into the relationship structure of 0.

However, this procedure involves the following problems:

1. Since there is no connection to the component, 0 is not informed when updates of the component C occur, and C does not know that other objects use it as a component Thus, in case of an update the component possibly does not fit the composite object any more.

2. When a component is incorporated, it is generally not necessary, but rather confusing, to make the component's intemal structure completely visible. Thus, it is desirable not to transport all component data into the composite object.

There are the following solutions to the two problems:

1. Instead of a copy of the data, only a view to the component is granted to the composite object.

This means that the information of the component which is visible in the composite object, always corresponds to the original data of the component. Any update of the original data is instantly visible in the composite object. Updates can, of course, result in the component not fitting the composite object any more. The adaptation must be performed as before; however, it becomes obvious now, that adaptations are necessary.

2. Often an interf ace object is defined in order to make only certain information of an object visible extemally. The interface describes the extemal image of a set of objects (in the following called implementations), which describe different realizations of a design object.

Thus, via the interface only certain properties of the implementations are visible. At the same time, it must be observed that the interface data must not be updated within a single implementation in order to safeguard that all implementations have the same interf ace. On the other hand, updates of the interface-object itself involve the implementations directly, i.e.

they are transmitted into the implementations.

Obviously, the relationship between an implementation and its interface as well as the relationship between a composite object and its components are based on the same mechanism:

An identity of values between the implementations and the interface is required, as well as values of the composite object have to correspond to the values of a component.

Updates are only possible on one side of the relationship, and they are transmitted to the other side immediately: Updates of the interface are transmitted to the corresponding

implementations, updates of a component are transmitted to the composite objects in which the component is used.

Moreover, there is another analogy: the inherited information is specialized by adding further data:

The implementations describe how the properties of the interface are realized, whereas composite objects, for instance, add placement data to a component.

Tue above considerations reveal that both the composition relationship and the interface- implementation-relationship can be exptessed by an inheritance-relationship. Therefore, one of the basic elements of the object model introduced in the next section is an inheritance relationship which can be characterized by the following properties:

Via the inheritance relationship, attributes of an object (the transmitter) and their values are inherited by another object (the inheritor). Tue inherited data must not be updated in the inheritor, whereas updates of the transmitter data involve all inheritors.

The inheritance relationship is selective: Only the explicitly specified parts of data are transfered from the transmitter to the inheritor.

Like any other relationship (see section 3), the inheritance relationship may possess attributes, subobjects and constraints. Thus, it is possible, to further specify the relationship between the transmitter and the inheritor and to tailor it to the specific application. For instance, the attributes of the relationship may be used for purposes of consistency control: If an update of the transmitter object occurs, the inheritor object possibly has to be adapted since some local data do not fit the inherited data any more. In most cases this adaptation has to be done manually by a user. To inform the user about changes of the transmitter object the attributes of the relationship can be used. In connection with trigger mechanism (which are not dealt with in this paper) these informations can be used for building mechanisms for semi- automatical corrections of consistency violations.

The inheritance relationship includes the mechanism of generalization: By the generalization only object types are related to each other and the existence of attributes (definitional properties in [MyBW80]) are inherited from the supertype. Tue inheritance relationship, furthermore, relates objects, thus besides the inheritance of type properties object values (factual properties in [MyBW80]) are inherited, too. Moreover, the inheritance relationship is a generalization of the version generalization [BaKi85] which is tailored to the relationship between interfaces and their implementations.

3. Basic modellin2 elements of the object model

In the following sections we introduce an object model, which comprises the inheritance relationship as an integral part. By means of several examples we show how it can be used in modelling CAD/CAM objects. We start with the basic modelling concepts of the object model before we illustrate the application of the inheritance relationship in the next section.

Objects

The basic modelling units are objects which belong to specific object types. The object type describes the attributes an object possesses. Attribute values belong to a particular domain.

Domains may be simple (integer, string, etc.) or structured (using constructors as record, list-of, set- of, etc.). Automatically, any object has an attribute called surrogate which allows a system-wide identifi.cation of the object and which is managed by the system.

Integrity constraints may be defined with the definition of an object type. They are local to the object type, i.e. they define conditions the attributes of the objects have to obey. Classes are sets of objects belonging to the same object type; several classes may have objects of the same type (this is especially important in connection with complex objects, see below).

Example: (Modelling of simple AND-, OR-, NOR- and NAND-gates) domain I/O

=

domain Point

=

obj-type SimpleGate:

attributes:

Length, Width:

Function:

Pins:

constraints:

integer;

(AND, OR, NOR, NAND);

set-of ( Pinld: integer;

InOut: I/O;

);

count (Pins)

=

=

count (Pins)

=

=

end SimpleGate;

Relationships

Objects can be related to each other. A relationship is represented by a relationship object. A relationship object belongs to a specific relationship type which can define several attributes and integrity constraints for the relationship objects. The types of the objects to be related can be specified, but they need not be.

Example of a relationship type:

obj-type PinType

=

attributes:

Inüut:

PinLocation:

end PinType;

rel-type WireType = relates:

Pinl,

I/0;

Point;

Pin2: object-of-type PinType;

attributes:

Corners: list-of Point;

end WireType;

The type of the objects to be related are specified after the keyword object-of-type. If the type of an object is not to be specified in the relationship-definition, this is denoted by <name>:object. In the example, WireType-relationships relate objects of type PinType, and every relationship object of this type has an attribute Corner by which the geometry of the wire is defined. Tue importance of relationships, especially for describing various assembly mechanisms for CAD/CAM-areas, will be illustrated later by means of an example from the field of steel construction.

Complex objects

Complex objects are built up from local objects (subobjects), possibly of several types, and relationships among them. Subobjects of a complex object are organized in local subclasses (object subclasses and relationship subclasses). The complex object has its own attributes, among them a surrogate. All subobjects depend on the complex object, they are deleted with the complex object.

Subobjects may be complex as well which results in several levels of nesting. The relationships of the complex object may link subobjects, also of different nesting levels. For example, in figure 1 Pins of Gates are related to Pins of SubGates.

The reason for introducing subobjects is the necessity of defining relationships within an object.

Tue basic idea is to build relationships between objects only. Therefore the parts of an object which have to be related must be defined as objects themselves, giving them their own surrogates. lt is not always easy to decide when to use a subobject and when an attribute, the decision depends on the intended use. Distinguishing between attributes and subobjects corresponds to some degree to the distinction of data types and object types in [Ehri85], and the subobjects can be compared to the embedded objects in OOPS [SUWZ88].

Length Width Pins

W1res

(a) object-type Gate

L

w

RII

~ Pins

Function SubGates

Length Width Function Pins

Flip-Flop

(b) complex object "Flip-Flop"

Figure 1: Complex object type Gate and complex object "Flip-Flop"

The type of a complex object is described by the definition of - attributes,

- types of subobjects,

- types of relaticmships among the subobjects, and - local integrity constraints.

Example: (building logical circuits from the simple gates AND, OR, NAND, NOR)

Circuits shall be built up by relating pins of AND,- OR-, NAND-, and NOR-gates. In order to incorporate the pins of these gates into a relationship, a new type ElementaryGate must be defined which represents pins as subobjects, rather than as attributes (as opposed to SimpleGates, see above). Thus, ElementaryGate already describes complex objects.

obj-type ElementaryGate =

/* equals SimpleGate except for the definition of Pins * / attributes:

Length, Width:

Function:

GatePosition:

types-of-subclasses:

Pins:

constraints:

integer;

(AND, OR, NAND, NOR);

Point;

PinType;

count (Pins)

=

=

count (Pins)

=

=

end ElementaryGate;

Now we can define the object type Gate (see figure 1) which itself defines two subclasses for objects and one for relationships:

The elements of Pins belong to the type PinType and represent the extemal pins of the gate to be described.

The elements of SubGates belong to the type ElementaryGate and represent the basic gates which are used to build up the circuit.

Basic gates are linked by elements of the relationship subclass Wires which belong to the type WireType. lt is determined that Wires-elements may relate pins of subgates to pins of other subgates or to the pins of the gate itself. In general, when defining a relationship class (as subclass of a complex object) the objects to be related can be further restricted to specific classes. Of course, the types of the objects have to match a possible type definition in the relationship definition.

obj-type Gate

=

/* representation of gates constructed by AND, OR, NAND and NOR-gates */

attributes:

Length,

Width: integer;

Function: matrix-of boolean;

types-of-subclasses:

Pins: Pin Type;

Subgates: ElementaryGate;

types-of-subrels:

Wires: Wiretype

where (Wire.Pinl in Pins or Wire.Pinl in SubGates.Pins) and (Wire.Pin2 in Pins or Wire.Pin2 in SubGates.Pins);

end Gate;

4.Inheritance Relationship

In addition to the features sketched in the previous section our object model possesses a further mechanism, the inheritance relationship. After a short introduction we illustrate the applicability of inheritance relationship by using it to model interfaces and composite objects.

4.1 Definition of an inheritance relationship

An inheritance relationship is represented by an object as any other relationship. Thus, an inheritance relationship is defined by a type-definition, and the specific relationships between objects are represented by inher-relationship-objects. As any other relationship, an inheritance relationship may have attributes, subclasses and constraints. But of course, the inheritance relationship carries a specific semantic: One of the objects to be related is called the transmitter of the relationship. lt transfers (part ot) its data via the inheritance relationship to the other objects which are called inheritors. The type of an inheritance relationship is de:fined as follows:

inher-rel-type <name> =

end;

transmitter: object-of-type <obj-type-name>;

inheritor: object-of-type <obj-type-name>; / object;

inheriting: < ... > /* attributes or subclasses of the transmitter's type*/

/* definition of attributes, subclasses, and constraints for the inher-rel */

Behind the keyword transmitter the transmitter-type is specified, behind the keyword inheritor the type of inheritor objects. lf no inheritor type is given, objects of several types may become inheritor objects of the inheritance relationship, otherwise only objects of the specified inheritor-type.

With the de:finition of an object type it must be explicitly stated that the type is an inheritor type in an inheritance relationship. For this reason, the definition of object types is extended by an additional keyword inheritor-in:

obj-type IOT

=

inheritor-in: INREL attributes:

By this definition the object type IOT is defined as a subtype of the transmitter type TOT of the inheritance relationship INREL, i.e. every object of type IOT inherits attributes of TOT. But, moreover, if an object of the inheritor type is created, it can be specified to which object of the transmitter type it is to be related. Thus, we have an inheritance relationship not only at the type level, but also at the object level. The inheritor object not only inherits the existence of attributes or subclasses from the transmitter type, but furthermore, it inherits attribute values and subobjects from the respective transmitter object.

A special case occurs if an object 10 of the inheritor type is not bound to a transmitter object. Then 10 cannot inherit any attribute values, it only inherits the attribute structure of the transmitter type.

Thus, this special case models the generalization mechanism used in object oriented data models.

The inheritance relationship is selective, i.e. the inheritor object inherits not all data of the transmitter but only those attributes or subclasses, which are specified in the inheriting-clause.

After this general introduction the rest of this section illustrates the properties of the inheritance relationship. This is done by (1) modelling the relationship of an interface to its implementations and in generalizing it to an interface hierarchy and by (2) modelling the component relationship between a composite object and its components.

4.2 lnterf aces and interf ace hierarchies

We assume that the interface of a gate is described by its expansion and its extemal pins. Therefore we divide the description of gates into two parts: Gatelnterface and Gatelmplementation. The object type Gatelnterface looks as follows:

obj-type Gatelnterface

=

attributes:

Length,

Width: integer;

types-of-subclasses:

Pins: Pin Type;

end Gateinterface;

All implementations of a specific gate are restricted to having the same interface. So we have to relate every Gatelmplementation object to a Gatelnterface object, and the data of the interface are to be inherited by all of its implementations. The generalization mechanism is not suited for modelling the inheritance of interface data by Gatelmplementation objects: Since generalization establishes a relationship at the type level, by this mechanism every Gatelmplementation object only inherits the existence of attributes of the type Gatelnterface. But a relationship to a particular Gatelnterface object from which the Gatelmplementation object can inherit its actual Pins is not established by the generalization mechanism.

In order to reach this goal we define the inheritance relationship AllOf _ Gate/ nterface which enables objects (of any type) to inherit data of Gatelnterface objects:

inher-rel-type AllOf_Gatelnterface =

/* enables objects to inherit all data of Gatelnterface objects */

transmitter:

inheritor:

inheriting:

Length, Width, Pins;

object-of-type Gateinterface object;

end All Of_ Gatelnterface;

In order to make Gatelmplementation objects inherit data from Gatelnterface objects, the object type Gatelmplementation has to be defined as an inheritor in the relationship AllOf _ Gatelnterface.

On the one hand, this statement has the effect that, at the type level, all attributes and subclasses, for

which the inheritance relationship is permeable, are transferred from the transmitter type Gatelnterface to the inheritor type Gatelmplementation (as with the generalization relationship).

But, moreover, if a Gatelmplementation object is created, it must be specified to which Gatelnterface object it is related. Thus, the definition of the object type Gatelmplementation looks as follows (see figure 2):

obj-type Gatelmplementation =

inheritor-in: AllOf_Gateinterface;

attributes:

Function: matrix-of boolean;

types-of-subclasses:

Subgates: ElementaryGate connections:

Wire: Wiretype

where (Wire.Pinl in Pins or Wire.Pinl in SubGates.Pins) and (Wire.Pin2 in Pins or Wire.Pin2 in SubGates.Pins);

end Gatelmplementation;

SubGates

L W Galel

Pins

Pins

CJ

Wires

R

1 t

Gatel nterface

1 nheritanceRelationship

Function Pins

Gatel mplementation

Figure 2: Relationship between Gatelnterf ace and Gatelmplementation

The inheritance relationship is obviously an appropriate instrument to model the interf ace implementation relationship. Moreover, it offers the possibility to overcome the rigid definition of interfaces. While implementations of a design object can be arbitrarily updated, most object models define interfaces as being unchangeable to avoid inconsistencies. This strict definition leads to problems and is not always necessary:

In reality, interfaces do change, thus we have to handle these changes.

Not all changes of interfaces concern all objects using the interface: If a new function is added to a module, this does not affect superior modules which do not need this function ..

Often it is not clear which information actually belongs to the interface. The interface of a chip may be built by its pins only, but some applications may require more information of a chip to integrate it as a component into a composite object (for instance, time information for time simulations ).

Not all CAD/CAM areas allow the definition of a clear interface. For instance, in the area of mechanical engineering, it is difficult to define exactly what the interface of an object is.

Moreover, it is much more complicated to describe the assembly of components which can be accomplished in many more ways than, for instance, in software engineering (call of procedures ).

lf interfaces are changeable, we have to deal with versions of interfaces. Common properties of these interface versions may be represented by a "super interface" which transfers its data to the interface versions via an inheritance relationship. For instance, interfaces of gates may possess the same pins, but their expansion may be different. This can be modeled by further dividing the description of gate interfaces:

obj-type Gatelnterface_l

=

types-of-subclasses:

Pins: Pin Type;

end Gatelnterface_I;

inher-rel-type AllOf_Gatelnterface_I =

transmitter: object-of-type Gatelnterface_I;

inheritor: object;

inheriting: Pins;

end AllOfGatelnterface_I;

obj-type Gatelnterface =

inheritor-in: AllOf_ Gatelnterface_I;

attributes:

Length,

Width: integer;

end Gatelnterface;

As the example shows, by means of the inheritance relationship we can build more complex interface hierarchies than the two-level relationship between interfaces and implementations.

Objects at higher levels of the hierarchy represent more abstract views of the design object. Thus, the hierarchy can be regarded as an abstraction hierarchy which allows a classification of design objects and their versions according to their common properties as subtle as desired. We are no longer limited to one single interface of a design object, and when constructing composite objects we can decide which abstraction of the component to use. Furthermore, this abstraction hierarchy supports the process of design: in the early phases of the design process composite objects may use components from abstract levels of the hierarchy, and during the design the component is refined by walking down the hierarchy to lower levels [BKSW87].

4.2 Composite objects

Having related the interfaces to their implementations using the inheritance relationship, we now model the component relationship by the inheritance relationship, too. The goal is to assemble gates not only by elementary gates but by previously designed complex gates. Since the external image of a gate is described by a Gatelnterface object, we have to import the data of Gatelnterface objects into superior Gatelmplementation objects.

Figure 3:

1

composite object

component-relationship

component interface

interface-relationship

componentimplementation

Application of the inheritance relationship for modelling the component relationship and the interface-implementation relationship simultaneously

A component relationship between a composite object and its components can be modelled as follows (see figure 3): A component of the composite object is represented by a subobject of the composite object. This subobject is the inheritor in an inheritance relationship whose transmitter object is the component. Thus, the component transfers data into a subobject of the composite object, and these data is visible for the composite object as part of this subobject. Besides the inherited data, the subobject may possess its own attributes and subobjects. So we enhance the definition of the object type Gatelmplementation as follows:

obj-type Gatelmplementation =

inheritor-in: AllOCGatelnterface;

attributes:

Function: matrix-of boolean;

types-of-subclasses:

SubGates:

inheri tor-in:

attributes:

All Of_ Gatelnterface;

GateLocation: Point;

types-of-subrels:

Wire: WireType

(1)

(2)

where (Wire.Pinl in Pins or Wire.Pinl in SubGates.Pins) and (Wire.Pin2 in Pins or Wire.Pin2 in SubGates.Pins);

end Gatelmplementation;

Remark: In this definition the type of subclass SubGates has been declared implicitly. Of course, it could have been defined also as an explicit type.

The interesting point of this example is that the relationship AllOf _ Gatelnterface appears twice: On the one hand (1), every Gatelmplementation inherits data from the corresponding interface, on the other (2), also subobjects of class SubGates inherit data from interface objects, in this case, however, from a component (see figure 4). Of course it is also possible to use different relationship types for relating the component subobject to the component and the whole object to its interface.

Furthermore, different inheritance relationships can be used for modelling different kinds of component relationships.

Pins Gatel nterface

component ______ _ ---· interface

relationship relationship

unct1on Pins

Gatel Pins

Wires Gatel mplementation

- inheriteddata

Figure 4: Gatelnterface in the roles of interface and component of Gatelmplementation

A valuable mechanism for tailoring the inheritance relationship to the need of the application is the possibility to explicitly specify its permeability. In section 4.1, we described the problems of a rigid interface definition. The two last items are due to the fact that it is not always possible to anticipate at definition time which interface data of an object have to be inherited by a superior composite object. Thus, it is sometimes necessary to determine the visible data specifically for a single case.

This can be accomplished by defining the permeability of the inheritance relationship.

Let us assume, for example, that objects of type Gatelmplementation possess an additional attribute TimeBehavior. Since this attribute is not part of the interface, it cannot be inherited from objects of type Gatelnterface. In order to use this attribute, a composite object must be related to a Gatelmplementation object instead. Nevertheless, by defining the appropriate permeability in the inheritance relationship SomeOf _ Gate, only the necessary information will be transferred to superior objects:

inher-rel-type SomeOf_Gate

=

transmitter: object-of-type Gatelmplementation inheritor: object;

inheriting:

Length, Width,

TimeBehavior, Pins;

end SomeOf_ Gate;

To sum up, the inheritance relationship offers very flexible possibilities to transfer data from a component to a composite object:

1. lt builds up an abstraction hierarchy in which the common properties of objects are represented by superior objects, thus extending the notion of an interface. This allows to define several abstract views of the design object which can be used for integrating it into superior composite objects, resulting in a flexible bottom-up-definition of interfaces.

2. lt allows to define the visibility of components specifically for single composition relationships. The interface levels suggested by the component can be refined and tailored to specific needs. This can be seen as a top-down-definition of interfaces.

The combination of the bottom-up and the top-down definition of interfaces offers a powerful means for a precise description of all aspects of the component relationship.

5. Example of an application: steel construction

By a second example we want to illustrate the several features of the introduced object model in an integrated way and emphasize the importance of powerful relationships for modelling the assembly of parts. The example comes from the field of steel construction and it models (part of) the world of weight carrying structures which are assembled from plates and girders by means of bolts and nuts (see figure 5).

/ a ,,., ' 1 '

___

1, . ...,_,

! ; '

/ ·;, /, 't'.) 1

1, I ^{:1 \}

-1.- / __ ,-' ____ ...,i!_o:0-1/ _{: f}

:

i' 1' f !

' - - ' - - ' - - - l ' - ' -"I

Figure 5: Weight Carrying Structures (from [Pege85])

As basic object types we introduce BoltType and Nuffype and the object type BoreType, which will be used later on to define subobjects of plates and girders.

domain AreaDom

=

record:

Length, Width: integer;

end-domain AreaDom;

obj-type BoltType = attributes:

Length,

Diameter: integer;

end BoltType;

obj-type NutType = attributes:

Length,

Diameter: integer;

end NutType;

obj-type BoreType

=

attributes:

Diameter, Length:

Positiion:

end BoreType;

integer;

Point;

Now we define the types of plates and girders in three phases:

1. At first the interface types Girderlnterface and Platelnterface are defined.

2. Afterwards the inheritance relationship Al!Of _ Girderlf is established by means of which Girder-objects inherit the data of their interface. In this example all data from the interface is inherited by Girder objects. Correspondingly, Al!Of_Platelfis defined.

3. Finally the object types Girder and Plate are defined as inheritor in the inheritance relationship Al!Of_Girderlfrespectively Al!Of_Platelf

1. lnterface-definitions obj-type Girderlnterface =

attributes:

Length,Height,Width:

types-of-subclasses:

integer;

Bores:

constraints:

Length < 1 00*Height*Width;

end Girderlnterface;

BoreType;

obj-type Platelnterface

=

attributes:

Thickness:

Area:

types-of-subclasses:

Bores:

end Platelnterface;

integer;

AreaDom;

Bore Type;

2. Definitions of the inheritance relationships inher-rel-type AllOf_Girderlf =

transmitter: object-of-type Girderlnterface inheritor: object-of-type Girder

inheriting:

Length,Height, Width, Bores;

end AllOf_Girderlf

inher-rel-typ AllOf_Platelf =

transmitter: object-of-type Platelnterface inheritor: object-of-type Plate

inheriting:

Thickness, Area, Bores;

end AllOf_Platelf;

3. Definitions of Plate und Girder obj-type Plate =

inheritor-in: AllOf_Platelf;

attributes:

Material: (wood, metal);

end Plate;

obj-type Girder

inheritor: AllOf_ Girderlf;

attributes:

Material: (wood, metal);

end Girder;

To build up higher level objects using plates and girders, these components have to be assembled using bolds and nuts. For representing this assembly we define the relationship type ScrewingType.

ScrewingType shows the modelling power of complex relationships: lt relates several bores with supplying bolds and nuts by the relationship itself (as a component of the relationship object).

ScrewingType possesses one further attribute showing the strength of the screwing connection.

Moreover, constraints describe that a screwing must have exactly one bolt and one nut, that the diameters of bolt and nut have to fit together, and that the bolt has tobe long enough to connect the respective plates and girders.

Relationships like ScrewingType can describe several other complex assembly mechanisms of parts, expressing much semantics of the modeled objects. This allows the implementation of mechanisms for advanced consistency control.

Before defining the relationship ScrewingType, we first have to establish two inheritance relationships by which Bold and Nut objects can be used as components in ScrewingType:

inher-rel-t_ype transmitter:

inheritor:

inheriting:

AllOf_BoltType

=

object-of-type BoltType;

object;

Length, Diameter, end AllOf_BoltType;

inher-rel-t_ype transmitter:

inheritor:

inheriting:

AllOf_NutType =

object-of-type NutType;

object;

Length, Diameter;

end AllOf_BoltType;

rel-type ScrewingType

=

relates:

Bores: set-of object-of-type BoreType;

attributes:

Strength: integer;

types-of-subclasses:

Bolt:

inheritor-in:

Nut:

inheritor-in:

constraints :

#s in Bolt

=

#n in Nut

=

AllOf_BoltType;

AllOf_NutType;

for (s in Bolt, n in Nut):

s.Diameter = n.Diameter;

for b in Bores:

s.Diameter <= b.Diameter;

s.Length = n.Length + sum (Bores.Length) end ScrewingType;

Now we are able to define the complex object type WeightCarrying_Structure:

obj-type WeightCarrying_Structure = attributes:

Designer: char;

Description: char;

types-of-subclasses:

Girders:

inheritor-in:

Plates:

inheritor-in:

types-of-subrels:

AllOf_ Girderlf;

AllOf_Platelf;

Screwings:

where

ScrewingType for x in Bores:

x in Girders.Bores or x in Plates.Bores;

end WeightCarrying_Structure;

A WeightCarrying_Structure is described by some attributes,

two subclasses Girders and Plates, the elements of which inherit their full data from the actual component they are related to, and

a sub-relationship Screwings, the elements of which define the assembly of plates and girders.

Using this kind of modelling, bolds and nuts are hidden in the relationship ScrewingType. Of course, it is also possible to define them as direct components of WeightCarrying_Structure. This

implies a change of ScrewingType where bolts and nuts are no longer subobjects but external objects which are to be related by the relationship ScrewingType.

6. Further aspects of complex and composite objects

As we saw in the previous sections, the inheritance relationship is a very powerful mechanism to model several aspects of composition relationships between objects. By the inheritance relationship an inheritor object not only inherits the existence of attributes but also their values from a transmitter object. U sing this inheritance mechanism we are able to model the interf ace- implementation relationship as well as the component relationship. Furthermore, by using the inheritance relationship we succeed in generalizing the notion of interface by constructing abstraction hierarchies of design objects. An object-oriented data model was introduced which comprises the inheritance relationship as an integral part, and the expressiveness of this model has been illustrated by means of examples from the fields of chip design and steel construction.

To handle composite objects, some more aspects have tobe investigated. Finally, we briefly look at two of them, namely the version concept and the transaction concept.

Versions

The implementations of an interface can be seen as the versions of a design object which is represented by the interface. By generalizing the notion of interface to an abstraction hierarchy, we get versions of interfaces which themselves have versions (the implementations). Thus, our concept leads to the introduction of "versioned versions" which are organized in abstraction hierarchies.

But, of course, version management has several other aspects. Especially important are ordering relationships among the versions and grouping of versions to support the process of design in

keeping track of the design history,

supporting the parallel development of alternatives,

providing means for classification of versions, e.g according to their degree of correctness.

Furthermore, a powerful version mechanism supports the management of changes ( composite objects may use old versions of interfaces). Which mechanisms are needed to do these jobs and how they can be integrated into an object model is described in [KSWi86] and [Wilk87].

When keeping several versions of a component the problem of choosing the right one comes up. lf we use a static assignment of components to the composite object in the inheritance relationship (as presumed in this paper for reasons of simplicity), it is not possible to incorporate new versions of components automatically into composite objects. Therefore, often a generic relationship is used (i.e. the component version is not fixed by the relationship ). U sing generic relationships the selection of component versions is deferred to assembly-time, but now we need mechanisms controlling the selection process. There are three principial possibilities [Wilk87]:

1. A component is selected by queries associated with the composite object giving the required properties of the component (top-down selection).

2. Design objects supply a specific version as the default version. If the design object is used as a component via a generic relationship, this default version becomes the actual component (bottom-up selection).

3. Tue selection mechanism is neither associated with the composite object nor with the component. Instead the selection is guided by information not included in the object definition (e.g. environments in [DiLo85]).

Transactions

lt is well-known that CAD/CAM-databases need advanced transaction mechanisms to deal with the specific requirements of this application area (see e.g. [KSUW85], [KLMP84], [BaKK85]).

Furthermore, the transaction manager should be able to exploit the more powerful modelling features of advanced object models. For instance, the explicitly defined relationships between objects can be used to identify potential conflicts (two update transactions are working on objects which are related to each other).

When accessing a composite object, we have to deal with "lock-inheritance" in the reverse direction of data inheritance: Accessing the data of a composite object which are inherited from a component requires to prevent the component also from being updated. Thus, the parts of the component which are visible in the composite object have tobe read-locked when the data is touched in the composite object.

During the design-process, sometimes it is necessary to see a composite object with some or all of its components materialized ("expansion" of a composite object). To support this use of composite objects, complex operations have to be offered which are able to lock not only single objects but whole parts of the component hierarchy. But as a matter of fact, the leaves of the component hierarchy often are heavily used objects (e.g. bolds and nuts, VLSI-standard-cells). To lock them exclusively by invoking a complex operation which accesses the expansion of a composite object for update would be disastrous. But these "standard objects" usually are protected by access control mechanisms preventing the normal user from updating them. Thus, there should be a tight connection between the access control manager and the lock manager: If objects are to be locked implicitly by complex operations the access control manager should be consulted to grant no lock which allows more operations than the access control admits. If for instance a user wants to work on the expansion of a chip, he usually is allowed only to read parts of the customized standard cells.

This should be realized by the lock manager, so that only these parts of the standard cells are locked in read-mode.

References

[AlCO85] A.Albano, C.Cardelli, R.Orsini: Galileo: A strongly-Typed, lnteractive Conceptual Language. ACM TODS, Vol.10, No.2, June 1985

[BaBu84] D.S.Batory, A.P.Buchman: Molecular Objects, Abstract Data Types and Data Models -A Framework. Proc. VLDB, Singapore 1984

[BaKK85] F.Bancilhon, W.Kim, H.Korth: A Model for CAD Transactions. Proc. VLDB, Stockholm, August 1985

[BaKi85] D.S.Batory, W.Kim: Modelling Concepts for VLSI CAD Objects. ACM TODS, Vol.10, No.3, September 1985

[BKSW87] T.Berkel, P.Klahold, G.Schlageter, W.Wilkes: Modelling CAD-Objects by Abstraction. Informatik Berichte der FernUniversität Hagen, Nr.74, Oktober 1987, to appear in Proc. 3rd Int. Conf. on Data and Knowledge Bases, Jerusalem, June 28-30, 1988

[Dada86] P.Dadam, et.al.: A DBMS Prototype to Support Extended NF2-Relations: An lntegrated View on Fiat Tab/es and Hierarchies. Proc. SIGMOD, Washington D.C., May 1986

[DiLo85] K.R.Dittrich, R.A.Lorie: Version support for engineering data base systems. IBM Research Report RJ4769, San Jose 1985

[Ehri85] H.-D.Ehrich: Specification of conceptual schemata by abstract data types and versions. Proc. Workshop on Design of information systems - methods and models, Tutzing, June 1985 (in German)

[HaLo82] R.L.Haskin, R.A.Lorie: On Extending the Functions of a Relational Database System. Proc. SIGMOD, Orlando, June 1982

[IEEE87] IEEE Software, July 1987, special issue on reusability

[KaCB86] R.H.Katz, E.Chang, R.Bhateja: Version Modelling Concepts for Computer-Aided Design Databases. Proc. SIGMOD, Washington D.C., May 1986

[KSUW85] P.Klahold, G.Schlageter, R.Unland, W.Wilkes: A Transaction Model Supporting Complex Applications in Integrated Information Systems. Proc. SIGMOD, Texas, May 1985

[KSWi86] P.Klahold, G.Schlageter, W.Willces: A General Model for Version Management in Databases. Proc. VLDB, Kyoto, August 1986

[KWUK87] P.Klahold, W.Wilkes, M.Ungerer, D.Köhler: Representation of Design Objects in Relational Databases. Proc. 3. E.I.S. - Workshop, Bonn, 1987 (in German)

[KLMP84] W.Kim, R.Lorie, D.McNabb, W.Plouffe: A Transaction Mechanismfor Engineering Design Databases. Proc. VLDB, Singapore, August 1984

[MLNB83] D.McLeod, K.Narayanaswamy, K.V.Bapa Rao: An Approach to Information Management for CAD/VLSI Applications. Proc. SIGMOD, Engineering Design Applications, San Jose, May 1983

[Mits87] B.Mitschang: MAD - a datamodelfor the kerne/ of a non-standard-database-system.

Proc. Conference on databases for office, engineering and science (BTW), Darmstadt, April 1987 (in German)

[MyBW80] J.Mylopoulos, P.A.Bernstein, H.K.T.Wong: A Language Facility for Designing Database-lntensive Applications. ACM TODS, Vol.5, No.2, June 1980

[Pege85] G.Pegels: Experience with Artificial Intelligence - A CAD!CAM-System for Steel- and Timber Constructions, Chemical and Industrial Plants. Proc. on Data processing for design, VDI-Gesellschaft Entwicklung, Konstruktion Vertrieb, Munic 1985 (in German)

[PiAn86] P.Pistor, F.Anderson: Designing a Generalized NF2-Model with an SQL-Type Language Interface. Proc. VLDB, Kyoto, August 1986

, . .\ u t, J

[ScSc86] H.-J.Schek, M.Scholl: The Relational Model with Relation-Valued Attributes.

Information Systems, Vol.11, No.2, 1986

[SUWZ88] G.Schlageter, R.Unland, W.Wilkes, R.Zieschang, G.Maul, M.Nagl, R.Meyer: OOPS - An Object-Oriented Programming System with lntegrated Database Management Facility. Proc. Conference on Data Engineering, Los Angeles, February 1988

[SVCC88] International Workshop on Software Version and Configuration Control, Grassau, West-Germany, Janurary 1988 (Proc to appear at Teubner Verlag, edited by J.Winkler)

[Wilk87] W.Wilkes: The Notion ofVersions and its Modelling in CAD/CAM-Databases. PhD- thesis, University of Hagen, September 1987 (in German)