F r o m E n t i t y - R e l a t i o n s h i p M o d e l s to R o l e - A t t r i b u t e M o d e l s

Amfindio Vaz Velho Rogrrio Carapuqa

INESCBST Apartado 10105, 1017 Lisboa, Codex, PORTUGAL

Phone: + 351.1.3100000 - Fax: + 351.1.525843 - E_mail: avv@eniac.inesc.pt

Abstract. This paper is a short presentation of the SOM (Semantic Object Model) approach. SOM was created to fulfill two main objectives. The first objective is the revision of the traditional data modeling techniques in order to integrate them within an object oriented framework, without sacrificing the main object-oriented principles, namely encapsulation, extendibility and reusability. The paper advocates that the way data modeling concepts have been combined with object-oriented concepts does not reach that goal. The second objective is the improvement of data modeling techniques in order to make them able to model roles. Roles are an important real world aspect we think has not been suitably dealt with. This paper describes atlributes and phases, the two main concepts of SOM. Attribute is the single concept used to model all static relationships and phases are thought to model roles. The paper also outlines the textual language (T-SOM) and the graphical language (G-SOM) used in SOM to describe conceptual schemes.

Keywords. O0 Conceptual Modeling, O0 Analysis and Design, Attributes, Roles, SOM

1 Introduct ion

In this section the motivations of SOM are analyzed and its main features are stressed. The section also outlines the paper's structure and introduces the example that will be used throughout the paper.

Semantic Data Models (SDMs) [11, 23] were introduced to cope with the limitations of record- based models [13]. SDMs provide convenient abstraction mechanisms for static relationships. SDMs increase the separation between conceptual and physical components and decrease the semantic overloading among relationship types. Several SDMs were proposed during the second half of the seventies and during the eighties. The Entity-Relationship Model (ERM) [11] was the pioneer of this family of models. Many models enriching the ERM in several ways, known as Extended Entity- Relationship Models (EERMs), have been proposed. Among the most well known are those reported in [10] and [34]. On the other hand, the Object-oriented (OO) paradigm [2, 35] is today (one of) the most promising answer for the demands of the industrial-quality software production. The OO paradigm allows the building of systems organized around highly abstract components (classes). Those components present a minimal semantic mismatch with the real world entities (RWEs) and exhibit encapsulation, extendibility and reusability [18]. The OO paradigm has been realized in several OO programming languages (OOPLs) [9, 19, 33], OO Database Management Systems (OODBMSs) [3] as well as OO Analysis and Design Methods (OOADMs) [36, 20].

A great potential has been claimed for the synergy between the OO paradigm and SDMs. Indeed, SDMs essentially provide constructors for modeling static relationships in an abstract way while behavioral issues are often left undefined. In contrast, the OO paradigm takes an abstract data type approach of embedding methods within classes being its weak point the absence of semantically rich constructors able to model static relationships [26]. The combination of SMDs with the OO paradigm provides a way of encapsulating the structural and the behavioral aspects of real word entities (RWEs), both of them modeled in a highly abstract way [14].

The combination between OO paradigm and SDMs has been materialized in two different approaches. One, we call the adoptive approach, is that taken by some OOADMs which adopt a SDM as their structural or static component. Examples of such methods are those from Rumbaugh [27], Booch [2], Shlaer and Mellor [29]. The other approach, we call the evolutionary approach, consists in extending a SDM with OO concepts, such as methods and messages. Works described in [16] and [7] adopt an evolutionary approach. In our option, either the adoptive approach or the evolution approach sacrifices the OO advantages, namely encapsulation, extendibility and reusability. It happens because they basically take the concepts of SDM as they were formulated in the original proposals. Such concepts, as will be shown below, do not directly conform with the OO principles.

258

SDMs were primarily introduced as schema design tools for relational databases. [23] identifies four basic ways which have been used to model relationships in SDMs. They are: an attribute, a conceptual distinct entity, an independent concept distinct from entity or a function. Aiming at easing the transformation to highly normalized relational schemes, normally SDMs use a combination of such mechanisms. In these cases, relationships among semantic entities, it means entities which correspond to real world concepts, are modeled separated from the entities themselves. This is often done by using conceptual distinct entities or an independent concept distinct from entity (type/class), as for instance association or aggregation.

The breakdown of entities, by spreading their relationships, certainly is a violation of the encapsulation principle. Moreover, modeling relationships by using conceptual distinct entities or an independent concept distinct from entity, make extendibility and reusability hard to get. Herein it is explained why it happens. In OO approaches the unit of extendibility and reusability is the class [17]. The fwst mechanism leads to two different kinds of class, classes for modeling entities and classes for modeling relationships. The second mechanism leads to two different concepts, one concept (class for instance) for modeling entities and an other concept (association for instance) for modeling relationships. Any way, two different extendibility and reusability mechanisms would be needed since it would be needed to deal with two different units. Otherwise, it means using a single mechanism, extendibility and reusability would be gotten only for entities or only for relationships. The Martin and Odell method [ 15] is an example of the first situation while OMT [27] is an example of the second situation.

SOM features the same semantic power as that of SDMs. However SOM follows an approach that is neither adoptive nor evolutionary. Hence, SOM avoids the drawbacks mentioned above. SOM starts from an object-oriented framework and enriches the semantics of the OO concepts in order to enable them to reach the semantic power of SDM.

SOM simply adopts attributes as the only way to model relationships. All entities are modeled through objects and all aspects concerned with the entities, including the relationships, are modeled inside the objects. This is as close as we can get to the semantics of real world entities. Besides, this does not violate the encapsulation principle. The attributes' basic semantics is the same as that of instance variables. However to get the semantic power of the constructors of the SDMs, SOM supports several categories of attributes (designator, association, etc.). Each one of them directly (in a highly abstract way) models the semantics of a very common kind of relationship among RWEs. SOM does not consider entities and relationships at the same level. Hence the class, which model entities, is the single unit for extendibility and reusability. A more uniform model is obtained by joining attributes and relationships.

OOADMs (adoptive approach) as well as ERM extensions with OO concepts (evolutionary approach), have not provided a substantial improvement to the concepts already presented in SDMs. However certain real world aspects are not suitably modeled in both approaches. We think roles a real world entity can play are one of them. A person, for instance, can play several roles, such as student, graduate student, soldier, officer, employee, unemployed person or taxpayer. Besides, those roles are dynamic. For instance, a person can be hired, fired and later be hired again. SDMs handle this with the concepts of specialization and generalization. These concepts basically state set inclusion relationships among instance of several types [30]. On the other hand, the specialization mechanism of the OO models normally considers the objects' type unchangeable and essentially allows sharing of code or behavior among different objects or types [31]. SDMs a s well as OO models are not able to model the way an entity acquires and discards roles.

Aiming at modeling roles in a highly abstract way, SOM introduces the concept of phase. Phases reformulate the way types and classes are often understood. SOM considers that throughout its lifetime, although an object keeps its single and unchangeable identity, it does not have a single type. An object obtains and discards types when it enters or leaves phases. Class is a particular kind of phase, called a generator phase. Generator phases are the phases an object enters when it is created and from which it never leaves. Objects enter or leave non generator phases whenever some events occur and some predicate on the value of the attributes hold.

The rest of this paper is structured in the following ways: Section 2 introduces the SOM's basic object model, which is basically the same as that of Oblog [28]. SOM adopts such model as a starting point for its contributions. Section 2 also outlines the SOM's textual language, T-SOM, which follows Eiffel [19] very close. Section 3 discusses the conditions under which an object enters or leaves a phase and, consequently, acquires or discards a type. Section 4 shows how the attribute semantics is enriched in order to achieve the same semantic expressiveness as that exhibited by SDMs. Section 5 stresses some conclusions. This section compares SOM with some related work, systematizes SOM main contribution and refers to work that has currently been done to implement

259

SOM concepts in a commercial OODBMS. This paper does not describe all the SOM's features. Further details can be found in [37].

Concepts introduced throughout the paper will be illustrated using a simplified version of the Cars Registration universe [12]. We will start with a simple model and we will gradually add details. For readers unfamiliar with it, a small abstract follows. Basically it has to do with car registration and the transfer of ownership. Manufacturers are registered as the car's first owner as soon as practicable. There are a number of garages, which can own cars. Manufacturers as well as garages can stop their operation provided that they own no more cars. At any time a car may be owned either by its manufacturer, or a garage, or a person. Manufacturers can only sell cars to garages and can not buy cars. Garages can only sell to people. The fuel consumption averaged over all registered cars produced by a particular manufacturer in a particular year is required not to exceed a maximum value, which is the same for each manufacturer and may change from year to year. At the end of each January an appropriate message is sent by the Registration Authority to each manufacturer which has failed to meet this requirement.

This paper basically follows an example-driven approach. Indeed, for each one of the introduced concepts, the paper describes in an informal way its semantics and syntax and, through the running example, indicates how the concept can be used. Whereas notation will only be outlined and OO basic concepts are not reviewed, some background in OOPLs, particularly Eiffel [19], will make the understanding of this paper easier.

2 SOM's Basic Objec t Model

This section presents the concept of type as understood by SOM. A SOM's type has attributes, events, life cycle and invariants. Attributes define static relationships

with other objects. Events occur during objects' lifetime and change the values of the attributes. Life cycle imposes a temporal pattern for the occurrence of events. Invariants define assertions on the value of the attributes, which must always hold throughout the objects' lifetime. This notion of class is basically the same as that of Oblog [28]. As will be explained below a SOM's type can be a class or a (non generator) phase.

I GARAGE ~rands Traded MANUFACTURER I

t - - - ~ I STRING I

Fig. 1. Car Registration(l): G-SOM

CLASS GARAGE ATTRIBUTES

Reg_Number, Address: STRING; Brands Traded OPTIONAL: SET[MANUFACTURER]

EVENTS-

*Registration (rn, ha: STRING) D o RegNumber := rn; Name :~ na End;

New Address (na: STRING) Do Address : - na End;

Trade Brand (m: MANUFACTURER) Require Not Brands Traded. Has(m) Do Brands_Traded. Add(m) Ensure BrandsTraded. Has(m) End;

Cancel Brand (m: MANUFACTURER) Require Brands Traded. Has(m) Do Brands_Traded. Remove(m) Ensure Not Brands Traded. Has(m) End;

++Delete LIFE CYCLE Registration -> (NewAddress q

Trade Brand [ Cancel Brand)* -> Delete INVARIA~TS Unlque(Reg_Number);

I Brands Traded. Count <= 3 [END - - Class Garaq~

Fig. 2. Clsss Garage(]): T-SOM

Figure 1 depicts in G-SOM a small fragment of the structural model of Cars Registration. Figure 2 specifies in T-SOM the class G a r a g e . In G-SOM, classes are depicted by rectangles. Pre-defined

260

classes (Integer, String, etc:) are drawn smaller. Let us explain and exemplify the components of a SOM type using class G a r a g e .

An attribute has a name, a domain phase, the l~hase where it is declared, and a type. Attributes are depicted in G-SOM by polygonal lines with special symbols (arrow, triangle, etc.) on the extremes according with their properties (multiplicity, etc.).

The attributes of class G a r a g e expresses that an instance of G a r a g e is always related with two instances of S t r i n g , through the attributes R e g _ N u m b e r and A d d r e s s , and one instance of Set [Manufacturer], through the attribute Brands_Traded. BrandsTraded models the manufacturers from which a garage sells cars.

Attributes can be classified as single-valued or multi-valued as well as mandatory or optional. An attribute is said to be multi-valued if its type is a collection. Otherwise the attribute is said to be single- valued.

A collection is any type which inherits from the SOM pre-defined generic type C o l l e c t i o n [XJ. C o l l e c t i o n [X] defines the general features of all repositories of objects, independently of the specific data structure used to store the objects. Set, List, Array and Hash would be examples of collection. The value of an am'ibute is a set of objects. For single-valued attributes this set has at most one element. B r a n d s T r a d e d is a multi-valued attribute since its type, S e t , is a collection while Reg Number and A d d r e s s are single-valued attributes. As said before attributes are depicted in G- SO1VT by polygonal lines with special symbols on the extremes. The symbols allowed for multi- valued attributes are the triangle and the half ellipse while the symbols allowed for single-valued attributes are the arrow, the square and the rectangle.

An attribute is said to be mandatory if it value can not be an empty set. Otherwise the attribute is said to be optional. Reg_Number and A d d r e s s are mandatory attributes while B r a n d s T r a d e d is an optional attribute. In G-SOM the symbol of a mandatory attribute is drawn filled-while the symbol of an optional attribute is drawn unfilled. In T-SOM optional attributes are differentiated from the mandatory ones because their name is followed by the keyword Optional.

Events are specified through pre-conditions ( r e q u i r e ) , body ( d o ) a n d post-conditions ( E n s u r e ) . One class may have one or more creation events and zero or more destruction events. R e g i s t r a t i o n is a creation event and D e l e t e is a destruction event. In T-SOM, creation events are marked with a star (big-bang) and destruction events with two crosses (death). Besides, creation and destruction events, a class normally includes other events. This is the case of class G a r a g e . In it, New A d d r e s s changes a garage's address, T r a d e B r a n d includes a manufacturer in the set of brandsThat a garage sells and C a n c e l B r a n d does th-~ inverse.

Life Cycle is expressed as a regula{expression which alphabet is the set of event types. The life cycle of class G a r a g e specifies that between the creation event and the destruction event zero or more occurrences of instances of event types New A d d r e s s , T r a d e B r a n d and C a n c e l B r a n d are allowed. Such life cycle would have b ~ n omitted because actually the default life cycle-means any sequence of events starting with a creation event and ending with a destruction event.

Section Invariants of class G a r a g e specifies two invariants. The first one is an uniqueness invariant. It states that no two garages can share the same value for the attribute Reg Number. The second one states that no garage can sell cars from more than 3 manufacturers.

Objects in SOM communicate through attribute lookupand event call. Both mechanisms, illustrated in the events T r a d e _ B r a n d and Cance l _ B r a n d , use the dot notation, which is very common in OOPLs. The events T r a d e B r a n d and C a n c e l B r a n d call services of the SOM pre- defined generic class C o l l e c t i o n [X7, namely has, add, remove and coun t . The semantics of such services is that which is suggested by their names.

3 Phases

Phase is the concept used in SOM for modeling roles. In modeling the real world, roles are an important issue. Indeed, the world can be seen as made up of sets of entities, which can play several roles.

In spite of their meaningfulness, roles have not been suitably addressed, either by the specialization and generalization mechanisms of SDMs as well as by the inheritance mechanisms of the OO approaches. Such approaches model different roles a real entity can play, not as a single object acquiring and discarding types (roles) but as different objects linked somewhat by inheritance, specialization or generalization. Although this approach is important to support reusability and

261

extendibility at the implementation level [17], it does not correspond to the exactly way real world entities behave and so does not allow the building of highly abstract models. Surprisingly, even the data modeling research that has been recently done on OOADMs and on the extensions of the ERM with OO concepts, has not brought up many new ideas which concerns role modeling. Among the few exceptions are event schema proposed in [15].

In dealing with roles, three important aspects should be addressed. (i) Roles are not static and are not completely played once an object has been created. Throughout its lifetime an entity can play new roles as well as stop playing roles it has played before. (ii) Different kinds of entities can share roles. (iii) Conditions under which entities start playing or stop playing roles, correspond to semantically- meaningful situations that happen during their lifetime. An example follows: (i) A person can play the role of a buyer of cars. A person can also play the role of an owner of cars. (ii) The role of buyer of cars can be played either by persons or by garages. The role of a car's owner can be played either by persons, by garages or by manufacturers. (iii) When a person sells all cars of which he or she was the owner, he or she stops playing the role of a car owner. Such a person becomes an owner again when he or she buys a car again. Every type in SOM is defined by a phase. A phase models a role which a given set of real world entities can play. SOM considers that through its lifetime an object obtains and discards types when it enters and lea~;es phases. An object enters or leaves a given phase when a specific event occurs or a given predicate on the phase's attributes holds.

This section describes the concept of phase. First, the section describes the basic notions SOM uses to deal with phases. Afterwards, the main advantages of phases over traditional specialization hierarchies are summed up. Figure 3 depicts in G-SOM a fragment of Cars Registration. Figure 4, 5, 6 and 7 are T-SOM fragments of class L e g a l _ E n t i t y , of phase G a r a g e , of phase B u y e r and of phase Owner . L e g a l _ E n t i t y models any meaningful entity, from the point of view of the registration authority, which can behave either as a car's owner or as a car's buyer.

3.1 Phases Vocabulary

SOM considers two kinds of phase, namely generator phases and non-generator phases. Only generator phases have creation events. When an object is created it becomes an instance of the type defined by its generator phase. Objects never discard this type.

In G-SOM generator phases are depicted by rectangles while non-generator phases are depicted by ellipses. In T-SOM generator phases begin with the keyword Class while non generator phases begin with the keyword Phase. Legal_Enti ty, Ownership_Transfer and C a r are generator phases while M a n u f a c t u r e r , G a r a g e , P e r s o n , B u y e r and Owner are non-generator phases.

Given an object in a phase Pl it enters a phase P2 when a specific event es occurs and a specific

assertion as on the P l attributes holds. P l is called a source phase and P2 a destination phase, es is

called a specialization event for the pair <P l ' P2 >' as a specialization assertion for the triple <P l ' es,

p2 > and <es, as> a .~pecialization condition for the pair <Pl' P2 >"

An object leaves a phasep when a specific event eg occurs and a specific assertion ag holds, eg is called a generalization event forp, eg a generalization assertion for the pair <p, eg> and the pair <eg, ag> a generalization condition for p. A generalization condition may be defined based on events and attributes which belong to the source phase. A generalization condition also may be defined based on events and attributes which belong to the destination phase. In this case the generalization condition is said to be an exit condition.

When an object enters a phase it acquires the type defined by the phase. This means that, although the object keeps the same identification, it acquires new attributes and events. In other words, entering a phase allows an object to enriches its representation (state) as well as its behavior. When an object leaves a phase it discards the type defined by the phase.

Lets us explain SOM notations for phases and exemplify the concepts introduced above. In G- SOM, source phases and destination phases are linked by a double trace polygonal line ended with an arrow pointing to the destination phase. The specialization and generalization conditions are indicated close to that line. <Legal_Entity, Person>, <Legal_Entity, Garage>, <Garage, Buyer>, <Buyer, Owner> and <Manufacturer, Owner> are examples of pairs source phase and destination phase.

262

~, DATE I

, I LEGAL_ I ' ~ f ~ ~ ~ O W N E R S H I P . . . ; . - L ER ON J TRA .ER I

I S77UNG , ~ 1 1 Ca,cet Brand[...J I Buy Car ~ . f A I I T - - - 4 - - - - - ~ I CAR

GARAGE ~ BUYER ~ '~ [ I 1 ( ) . . - ( 3==7 , I Trade Brand II Sell Car,..., - ~ # - I

I I Traded / -"q'--- f ~ I ~ W

k. J Car_Registration

Fuel Warning t I ~ F .WARNED - - ' - - - ' ~ k M AN U FACTU-R ER 1

~tok ~

Fig. 3. Cars Registration(2): G - S O M

CLASS LEGALENTITY DESTINATION PHASES

PERSON Becomes With RegPerson GARAGE Becomes With Reg_Garage MANUFACTURER Becomes With RegManuf

ATTRIBUTES Reg_Number, Address: STRING; Reg_Date: DATE;

EVENTS Registration (rn, add: STRING; rd: DATE)

DO ... End; New Adress (ha: STRING) Do ... End;

*Reg Person (rn, add: STRING; rd: DATE) Do Reglstartion (rn,add, rn) End;

*Reg_Garage (rn, add: STRING; rd: DATE) Do Registartion (rn,add, rn) End;

*Reg_Manuf (rn, add: STRING; rd: DATE) Do Registar~ion (r~,add, rn) End;

++Delete Require ... End INVARIANTS Unique(Reg_Number)

END -,,- Claes Le~l~En:~.s . . . . . . . . . . . .

Fig. 4. Class Legal_Enti ty: T - S O M

PHASE GARAGE DESTINATION PHASES

BUYER Becomes With Trade Brand Leaves With Cancel Brand (N_Brands = 01

ATTRIBUTES BrandsTraded OPTIONAL: SET[MANUFACTURER]; N_Brands: INTEGER => BiandsTradeO.Coun~; Sells To (b: LEGALENTITY): BOOLEAN =>

b.I~a(PERSON); Buy_From (o: LEGAL_ENTITY): BOOLEAN =>

O.Isa(MANUFACTURER) And BrandsTraded. Has(o)

EVENTS Trade Brand -. End; CancelBrand ... End

I PHASE BUYER

DESTINATION PHASES OWNER Becomes With Buy Car

ATTRIBUTES BUy From (o: LEGAL ENTITY): BOOLEAN

E VEN~S B~y Car (c: CAR)

Do OWNER::AnotherCar(c) End

END : ~ ~ s ? ~uyer . . . . . . . . . .

Fig. 6. Phase Buyer: T - S O M

PHASE OWNER LEAVES WITH Sell Car ICars. Count= 0]

ATTRIBUTES Cars: LIST[CAR]; Sells TO (b: LEGAL ENTITY): BOOLEAN

EVENTS

*Another Car (c: CAR) Require Not Cars. Has(c) Do Cars.Add(c) Ensure Cars. Has(c) End;

Sell Car (c: CAR; b: BUYER) Require Sells_To(b); b. Buy From(Sel~ Cars. Has(c); b /= Self;

Do" Cars. Remove(c); b. Buy_Car(c); c. Reg_Transfer(Self, b)

Ensure Not Cars. Has(c) End END - - Phase Owner

Fig. 7. Phase Owner : T - S O M

Fig. 5. Class Garage(2) : T -SOM

263

Those examples show that a source phase can be either a generator phase (class) or a non- generator phase ( < L e g a l E n t i t y , P e r s o n > and < G a r a g e , Buyer>) . They also show that a source phase can have more than one destination phase ( < L e g a l _ E n t i t y , P e r s o n > and <Legal_Entity, Garage>) and vice-versa (<Buyer, Owner> and <Manufacturer, Owner>).

In T-SOM destination phases are indicated in the section Destination Phases of their source phases. This is exemplifies by the phases L e g a l E n t i t y , G a r a g e and B u y e r . Specialization conditions are declared by the clause Becomes With of the section Destination Phases of the source phase. Generalization conditions which are not exit conditions (based on source phase's events and attributes) are declared by the Leaves With clause of the section Destination Phases of the source phase. Phase G a r a g e includes an example, Generalization conditions which are also exit conditions are declared by the Leaves With section of the destination phases. Phase Owner includes an example. For the pair < L e g a l E n t i t y , G a r a g e > , Reg G a r a g e is a specialization event. This example shows that a cTeation event may also be a specialization event.

In a specialization condition it is possible to omit either the event or the assertion. The omission of the assertion means that objects enter the destination phase whenever the event occurs, no matter what the attributes' value. The omission of the event means that objects enter the destination phase whenever the assertions hold no matter what event that has occurred. The omission of both the event and the assertion means that objects enter the destination phase as soon as they enter the source phase. The omission of generalization events and generalization assertions holds a similar semantics.

Let us see some examples. For the pair < G a r a g e , Buye r> , T r a d e B r a n d is a specialization event. The respective specialization assertion was omitted. Moreover, C a n c e l _ B r a n d is a generalization event and N _ B r a n d s = 0 is the respective generalization assertion 1. N B r a n d s is a derived attribute (function) whose value is the number of manufactures from which a-garage trades cars. The pair < P e r s o n , B u y e r > neither has specialization conditions nor generalization conditions. This means that a person always is a buyer. For the pair < B u y e r , Owner>, Buy_Car is a specialization event. The respective specialization assertion was omitted. Moreover, Se 11 Car is a generalization event and C a r s . C o u n t -- 0 is the respective generalization assertion. This is a case of an exit condition.

An event declared in a destination phase may not be called in the source phase because when an object is in the source phase it is not always in the destination phase as well. This rule has an exception in SOM. One specific destination phase event may be called by the source phase's specialization event. This event is called an entry event . Entry events model knowledge that is shared by source phase and destination phase. For instance, a person knows that to become a student he or she must enroll in a given course. Although enrollment is a student event, people have to know about it.

In T-SOM, entry events are marked with a star, as creation events are. A n o t h e r C a r (figure 7) is an entry event of the phase Owner. A n o t h e r Car is called by B u y C a r (figure 6), which is a specialization event for the pair < B u y e r , Owner>.

For calling an entry event from a specialization event it is necessary to precede the entry event's name by the name of its domain phase followed by the resolution operator '::'. This is exemplified in the event B u y _ C a r of class B u y e r . B u y _ C a r is called during the ownership transfer process. Let us explain how this process is supported. Phase Owner has a multi-valued attribute C a r s modeling the collection of cars an O w n e r ' s instance owns. Class C a r has a multi-valued attribute T r a n s f e r s , which holds a collection of O w n e r s h i p _ T r a n s f e r ' s instances. Each instance of O w n e r s h i p _ T r a n s f e r holds an Owner field modeling the transferee a n d a B u y e r field modeling the next owner. Event se 11 Car of class Owner removes the target car from the value of actual owner's attribute C a r s , callsi-he event B u y _ C a r on the target buyer and calls the event R e g _ T r a n s f e r , which registers a transfer, on the target car.

The concept of phases allows to classify objects based on multiple and independent criterion. In figure 3, for example, manufacturers are classified as owners, as long as they own one or more cars. However, they are also classified as warned manufacturers, as long as they have received a fuel warning. All the four combinations between owner and warned manufacturer are possible. This

1N B r a n d s = O would also be an appropriate generalization condition and N_Brands/=O an appropriate specialization condition.

264

means that a manufacturer may be a owner without being a warned manufacturer, may be a warned manufacturer without being a owner, etc. Besides, these "states" can be dynamically changed.

Such as inheritance in OOPLs, phases support rewriting facilities. Let us see an example. As said before, manufacturers can only sell cars to garages and can not buy cars while garages can only sell to people. These restrictions are supported by rewriting the Boolean attributes S e l l s To and Buy_From. Sells To is an attribute of Owner, which verifies if a given owner is allowed-to sell a car for a specific legal entity. This attribute would be redefined for phases M a n u f a c t u r e r , G a r a g e and P e r s o n . These phases are (indirect) source phases of phase Owner. Buy_From is an attribute of B u y e r , which verifies if a given buyer is allowed to buy a car from a specific legal entity. This attribute would be redefined for phases G a r a g e and P e r s o n . These phases are source phases of phase Buyer . Figure 5 shows the version of these attributes for phase Ga rage . Isa is a pre-defined Boolean attribute of SOM. It verifies if an object has a given type.

As shown before, phases model roles in a highly abstract way. It is an important issue that surprisingly has not been suitably addressed. Phases also pack within a single concepts features that have been partially achieved in some models ([10] and [1] for instance) only through the use of several constructors. Phases are also powerful from the methodological point of view. Indeed, diagrams like that of figure 3 can be understood as Role Flow Diagrams (RFDs), showing how real world entities acquire and discard roles. A design concentrated in RFDs stresses the dynamic aspects of a system, much more than a design concentrated in an EERM, as it is done in OMT [27] for instance. RFDs make real world's understanding as well as communication among developers and users easier. From our experience developing systems using SOM we have realized that it is easier for users and developers to understand and to talk about real world if they follow role flows than if they follow data flows [38] or inheritance hierarchies.

3.2 Phases versus Inheritance

This section sums up the main advantages of phases over inheritance such as it is supported in class- based OOPLs as Smalhalk [9], C++ [33] and Eiffel [19]. Although prototype-based languages are not considered, the conclusions also apply to them. Indeed, inheritance, the classification mechanism of class based-languages, and delegation, the classification mechanism of prototype-based languages, are equivalent mechanisms [31].

Classes classify objects based on their template or implementation. Phases introduce an advanced classification mechanism, which combines set-based and life cycle-based classification. Indeed, phases allow to classify objects based on the fact that they hold a given predicate over certain attributes. They also allow to classify objects based on occurrence of a given event, which allows to group objects according to different stages of their lifetime. In class-based languages normally Objects are automatically classified once and for all. Moreover, classification is made upon creation. Phases allow objects to evolve over its lifetime by changing their classification. Finally, phases allow to support multiple classification based on independent criteria. As it is well-known, class-based languages do not efficiently support that feature. They only can support this through the definition of all possible combinations using multiple inheritance, which can lead to a combinatorial explosion.

This set of features, namely set-based and life cycle-based classification, dynamic classification and multiple classification, make phases appropriate to model real world entities in a way very close to human perception. It means, to model real world entities as sets of objects, playing and discarding multiple roles, in a dynamic way.

4 Attributes

SOM models all static relationships through attributes. The basic semantics of attributes, as it was explained in section 2, is very close to the semantics of instance variables, as defined in the OOPLs. This section shows how SOM enriches attributes' semantics in order to make them as expressive as the constructors that are often found in SDMs. Notions introduced in this section will be illustrated using the Car Registration fragment represented in figure 8. This fragment includes attributes and classes that have not been introduced yet.

This section is structured in the following way. First they are introduced the concepts of extension of a phase, extension of an attribute and attribute inverse. After introducing these basic concept, they are introduced the concepts of category of attribute and dependent attribute. A category of attribute defines a particular pattern of relationship. A dependent attribute allows to model a relationship, which itself has attributes. The section ends with some methodological remarks about using attributes.

265

4.1 Basic Concepts

This section introduce basic concept, which will allow to define more abstract ones. The concepts introduced are those of extension of a phase, extension of an attribute and atwibute inverse.

The extension of a phase is defined as being the set of its instances. For instance, the extension of class M a n u f a c t u r e r is the set of M a n u f a c t u r e r ' s instances it means the set of manufacturers that are currently in operation.

Each attribute defines a mathematical relation, called the extension of the attribute. The domain of this relation is the extension of its domain phase, The co-domain of this relation is the extension of its type phase, if the attribute is single-valued, or the extension of its type phase parameter, if the attribute is multi-valued. A tuple <x, y> belongs to the extension of an attribute att if y belongs to the value of att when an is evaluated at x. The extension of an attribute att is denoted by Ext(att).

Let us exemplify the concept of extension of fin attribute. Class Ca r has a single-valued attribute called Manufacturer. The domain of Ext (Manufacturer) is the class Car. The co-domain of E x t ( M a n u f a c t u r e r ) is the class M a n u f a c t u r e r . On its hand, phase G a r a g e has a multi- valued attribute called B r a n d s T r a d e d . The domain of E x t ( B r a n d s T r a d e d ) is the phase G a r a g e . The co-domain of E x t - ( B r a n d s T r a d e d ) is the phase M a n u f a c t u r e r . However, the type of Brands Traded is not Manufacturer but Set [Manufacturer] (figure 2).

The concept ~f inverse attribute is herein introduced. Two attributes att I and att 2 are said to be inverse if throughout the lifetime of the instances of their domain phases, Ext(att 1) and Ext(att2) are

inverse relations. It means whenever <x, y> belongs to Ext(attl), then <y, x> must belong to Ext(an 2) and vice-versa. For instance, the attributes B r a n d s _ T r a d e d of G a r a g e and Sells To of Manufacturer are inverse. In G-SOM, inverse attributes are drawn on the same polygoffal line. T-SOM syntax will be explained later.

It is not mandatory to declare an inverse attribute. For instance, attributes M a n u f a c t u r e r and Mode l of class C a r have defined without inverse. However, when an event has as its target an attribute that gets an inverse, its semantics is extended in a suitable way in order to keep the attributes' extension inverse. For instance, the event B r a n d s _ T r a d e d . p u t (m) occurring on an instance of G a r a g e , being r a a reference to an instance of M a n u f a c t u r e r , would be (automatically) followed by theeventm. S e l l s To.put (self).

Inverse attributes represent a limited breakdown in the encapsulation of classes. Inverse attributes can be understood as a window through which it has obtained permission to break the encapsulation. This is what happens in reality. For instance, a married woman knows that her husband has a w i f e attribute and a married man knows that his wife has a H u s b a n d attribute. The basic point is that often the knowledge about a relationship is shared by the participating entities. This should not be hidden but, on the contrary, should be stressed in the models.

4.2 Attribute Categories

Research on SDMs brought to information modeling several constructs, which try to abstractly capture the semantics of some patterns of relationship among real world entities, which very often occur. Models like RM/T [6] feature a very rich set of constructs. One of the advantages of those constructs is the reduction of the semantic overlapping among relationship types [13]. This means that two different patterns of relationship among real world entities are not modeled through the same concept but, instead, the modeling method provides specific concepts for each of them.

Regarding the way as relationships are dealt with, the approach of OOADMs can be considered a retreat, when compared with what SDMs feature. Indeed, different kinds of relationship are modeled by the same concept, association for example. The differences among them are stated through multiplicity constraints. For instance, in OMT [27] one-one, one-many and many-many relationships, either mandatory as well as optional, are all modeled with the concept of association.

SOM supports various categories of attributes, namely designators, associations, double designators, aggregates, components and relations. Each category has particular semantics, appropriate to model a particular pattern of static relationships. The notion of attribute's category combines those notions introduced before with multiplicity constraints on the attribute's extension.

The categories of attributes supported by SOM are herein explained. Let us start with a comment on syntax. As said before, in G-SOM attributes are depicted by a polygonal line with a given symbol at one of the extremes. Actually, there is a different symbol for each one of the categories of

266

attributes. For each one of the categories of attributes this section introduces its semantics and syntax and exemplifies its use (see figure 8).

| ~ ....

1 1 o, R

I MODEL ! ~ Model [ CAR

[OWNERSHIP_[ Transfer~[ HISTORY ~.hPrev Motor s / Car~'C---~ ENGINE

|TR sFE" I "t t ,

Fig. 8. ears Registration(3): G-SOM

A designator is a single-valued attribute, either mandatory or optional. The multiplicity of its extension must be many-one throughout the lifetime of the instances of its domain phase. In G-SOM the symbol of designators is an arrow. The arrow is drawn close to the type phase, if the attribute does not have inverse or close to the domain phase, if the attribute has inverse. In class C a r the attributes L i c e n s e Number, Model, M a n u f a c t u r e r and Owner are designators. The symbol shown on the line th~depicts L i c e n s e Nurabei: specifies a uniqueness invariant to this attribute.

An association is a muhi-valued att~bute, either mandatory or optional. The multiplicity of its extension must be one-many throughout the lifetime of the instances of its domain phase. In G-SOM the symbol of association is a half ellipse. The attributes C a r s of phase Owner , T r a n s f e r s and Prey Motors of class History and Models of phase Manufacturer are associations. Mode~s, Transfers and Prev Motors are optional attributes while Cars is a mandatory attribute. As said before, the symr"ols of mandatory attributes are drawn filled. Whenever an association has an inverse the inverse must be a designator and vice-versa. For instance attributes Owner of class C a r and C a r s of class Owner are inverse. Owner is a designator and C a r s is an association.

Double designators, aggregators and components are single-valued attributes. The multiplicity of their extension must be one-one throughout the lifetime of the instance of their domain phases.

For double designators, the attribute and its inverse, whenever it has been declared, are both mandatory or both optional. The inverse of a double designator is a double designator as well. The attributes H i s t o r y of class Car and C a r s of class H i s t o r y are mandatory double designators. The G-SOM symbol of double designators is the square. Class H i s t o r y models the events that have happens on a car since it has registered until its destruction. They can be ownership transfer events, modeled by the attribute T r a n s f e r s , as well as engine changing events, modeled by the attribute P r e y M o t o r s . P r e y M o t o r s will be commented on later.

Aggregatesand components model the usual part of semantics. Aggregators are always mandatory and components always optional. The inverse of an aggregate is always a component and vice-versa. The attribute M o t o r of class Car is an aggregate while the attribute C a r of class E n g i n e is a component. The main difference between aggregates and double designators has to do with the destruction semantics. Whenever a car is destroyed its history is automatically destroyed as well. However, its motor is not automatically destroyed. Instead the value of the attribute C a r of such motor is set to void.

Besides association, relation is the other category that applies to multi-valued attributes. A relation is a multi-valued attribute, either mandatory or optional. The multiplicity of its extension is many- many throughout the lifetime of the instances of its domain phase. The attributes Brands_Traded of G a r a g e and S e l l s T o of M a n u f a c t u r e r are relations.

267

4.3 Dependent Attributes

SOM models all static relationships with attributes. However, relationships also can have attributes [5]. A relationship's attribute is supported in SOM by the notion of dependent attribute. This section illustrates the main features of dependent attribute.

Figure 9 shows a T-SOM fragment of the section Attributes of class H i s t o r y . In T-SOM, an attribute's category is indicated by a specific keyword (D REF, ASSOCIATION, etc.) preceding its type. Figure 9 also shows how an inverse attribute is indicated. Indeed, an attribute's type can be followed by the symbol <-> and the name of its inverse attribute.

CLASS HISTORY

ATTRIBUTES Car: D REF CAR <-> History;

Transfers OPTIONAL:

ASSOCIATION LIST [OWNERSHIP_TRANSFER] ;

Prey Motors OPTIONAL:

ASSOCIATION ARRAY [ENGINE]

{ ReplaceDate : DATE } ; ...

EVENTS ,,. LIFE CYCLE ... INVARIANTS ...

Fig. 9. Class History: T-SOM

Let us focus on the attribute P r e y M o t o r s . It is a multi-valued attribute, whose value holds the collection of motors a car has already had, before the one it actually has. For each motor it is necessary to hold the date when it was replaced. This is modeled by the attribute R e p l a c e D a t e , which is said to be a dependent attribute. A dependent attribute is not defined for the instan'ce of a given domain phase but for the objects belonging to the value of some multi-valued attribute. That m u l t i - v a l u e d a t t r i b u t e i s s a i d t o b e t h e owner attribute. Indeed, R e p l a c e D a t e is not defined for each one of the instances of the class H i s t o r y but for each one of the instances of the class E n g i n e which belong to the value of the attribute Prey Motors.

In G-SOM,--dependent attributes obey rules similar to those used for non-dependent attributes. However, instead of being drawn on the borders of the class' rectangle, they are drawn on the borders of an anonymous rectangle linked to the polygonal line of the owner attribute through a knot (figure 8). In T-SOM, dependent attributes are declared after their owner attribute. They are delimited by parentheses.

4.4 Methodological Remarks

Let us finish this section with some final remarks about the methodological merits of attributes. As it was shown, attributes combine encapsulation with semantic expressiveness. All relationships in which a given class participates are modeled inside the class. On the other hand, categories of attributes directly capture semantics of the most common kinds of relationship. Each one of the categories of attributes has semantics that does not overlap the semantics of some other categories of attributes. Hence, the same situation has a tendency to be always modeled the same way. The identification of relationships as well as the communication among software developers is made easier. Relationships with attributes as those of the ERM are modeled in SOM through dependent attributes.

It is important to observe that the category of an attribute is independent of its type even for multi- valued attributes. For instance, in figure 9 both T r a n s f e r s and P r e v M o t o r s are associations. However the former is a List while the later is an Array. This combinesa semantic issue with a data structure issue. It is very important in order to keep SOM useful throughout the software development life cycle. The use of the same model and language either for analysis, design or implementation as been claimed either as one goal as well as one strength of the OO paradigm [21]. Extendibility and reusability are achieved for phases as well as for relationships. Indeed, by rewriting an attribute it is possible to specialize a relationship.

5 Conc lus ions

This section lightly describes the implementation of the SOM's concepts on the top of a commercial OODBMS. Moreover, SOM's contributions are summed up and some related work is described.

268

5.1 SOM on Top of an OODBMS

This subsection briefly describes the implementation of attributes and phases on top of ONTOS [22], an Object Oriented Data Base Management System which adopts the object model of C++. A compiler which transforms SOM's phases to C++ classes has been developed. In this section we will outline the transformation algorithms we have adopted for categories of attributes and phases. We will leave out the specific aspects related with ONTOS. ONTOS has basically been used as a persistent programming platform. Although the transformation algorithms (particularly the phases' algorithm) include several interesting issues, an exhaustive discussion around those issues is out of the scope of this paper.

The basic idea to implement the categories of attributes is to define them as generic classes or, in the C++ terminology, as templates [33]. As ONTOS does not support templates yet, macros were adopted instead. Thus, for each one of the categories of attributes there is a macro, which, when expanded defines a class. A SOM attribute of thecategory c is transformed into a C++ data member which type is the class that results from the expansion of the macro which corresponds to the category of c. That class includes functions which ensure semantics defined in SOM for the respective category of attribute. For amibutes with inverse, the macros have at least two parameters, CodDOm and RevAtt. RevAtt stands for the name of the inverse attribute. For single-valued attributes, CodDOrn stands for the type of the data member. On the other hand, for binary muhi- valued attributes, besides CorPOra there is a third parameter, C o l l T y p e . C o l l T y p e must be an ONTOS' aggregate 1. Then, for multi-valued attributes, C o l l T y p e i s the type of the data member and CodDOm the type of the elements.

For each SOM phase two C++ classes are defined, Surrogate and Body. All the SOM's reference to a given phase is represented in C++ by a pointer to the respective surrogate. The surrogates only have a pointer to the surrogate of its source phase (MySource) and a pointer to the respective body (MyBody). The body holds the representation of attributes and of events. All the services defined in the body are also defined in the surrogate through in line functions. If Y is a destination phase of x, the surrogate and the body of Y inherit from the surrogate and body of x respectively. When an object in phase x enters a phase Y the following operations are executed: a new surrogate and a new body for the phase Y are created; the pointer MySource of the surrogate of Y is redirected to the surrogate of • the body of X is copied to the body of Y; the pointer MyBody of the surrogate of X is redirected to the body of Y; the body of x is deleted. Phase exit is implemented with a sequence more or less inverse.

5.2 Summary of SOM Contributions

Let us add up the main contributions of SOM. The concept of attribute allows to integrate the data modeling techniques within an object-oriented framework. SOM keeps the semantic expressiveness of SDM but does not sacrifice the OO principles, namely encapsulation, extendibility and reusability. The concept of phase supports set-based and life cycle-based classification, dynamic classification and muhiple classification. These features make phases appropriate to model real world entities in a way very close to human perception. This means, to model real world entities as set of objects, playing and discarding multiple roles, in a dynamic way.

5.3 - Related Work

The use of attributes and phases are the SOM's main contributions. This subsection gives a brief survey of related work.

Several OOADMs methods ([27, [2], [29], [15]) feature concepts with the same expressiveness as the SOM's concept of attribute. However, they place structural relationships at the same level as classes. In SOM structural relationships are internal to classes. We advocate that the SOM's approach fully conforms to the OO principles and advantages, namely encapsulation, extendibility and reusability. However, the approaches behind the methods referenced above are easier and informal. Hence, they are more appropriate at the early stages of domain analysis.

Roles are an important aspect for real world understanding�9 Object-oriented research has not really dedicated much attention to role modeling. However, some systems with role modeling capabilities

lAggregate is an ONTOS abstract class which is a superclass of all collection types.

269

have been reported [8, 24, 15, 32, 25, 4]. The main differences to the SOM's concept of phase are the following: In some systems, the transition between phases (types) is determined only by state predicates [4] or by pre-defined methods [8, 32]. In SOM the transition between phases (types) can be determined by a combination of state predicates and event occurrences. In some of the systems mentioned above ([24, 15, 25]) roles are handled by a different concept than that of type or class. SOM understands a role as a type: the concept of phase, which models roles, is the basis of the SOM type system. Only [15] features a classification of events similar to those featured by SOM (specialization events, generalization events, etc.).

Acknowledgment: The authors express their gratitude to the review team assign to this paper for their relevant and helpful comments.

References

1. A. Albano, L. Cardelii, and R. Orsini, Galileo: A Strongly-Typed, Interactive Conceptual Language, ACM Transactions on Database Systems, Vol, 10, N-* 2, June 1985, pp. 230-260.

2. G. Booch, Object Oriented Design with Applications, The Benjamin/Cummings Publishing Company, Inc., 1991.

3. R.G. Cattel, Object Data Management: Object-Oriented and Extended Relational Database Systems, Addison- Wesley, 1991.

4. C. Chambers, Predicate Classes, Proceedings of ECCOP'93 - 7tb European Conference on Object-Oriented Programming, O. N. Niers'trasz (ed), Lectures Notes in Computer Science N ~ 707, Springer-Verlag, 1993, pp. 268-296.

5. P. Chen, The Entity-Relationship Model: Toward an Unified View od Data, ACM TODS, 1 : 1, 1976, pp. 9-36.

6. E. Codd, Extending the Database Relational Model to Capture More Meaning, ACM Trans. on Database Systems, Vol. 4, N ~ 4, December, pp. 397-434.

7. G. Engels et al., Conceptual Modelling of Databases Applications Using an Extended ER Model, Data & knowledge Engineering 9 (1992/93), pp. 157-204.

8. D.H. Fishman et al., Overview of the Iris DBMS, in: W. Kim, and F. H. Lochovsky (eds.), Object-Oriented Concepts, Databases, and Applications, Addisom-Wesley, 1989, pp. 219-250.

9. A. Goldberg and D. Robson, Smaltalk-80: The Language and its Implementation, Addison- Wesley, 1983.

10. M. Hammer and D. McLeod, Database Description with SDM: A Semantic Database Model, ACM Trans. Database Systems, 6(3), September, 1981, pp. 351-386.

11. R. Hull, and R. King, Semantic Database Modeling: Survey, Applications, and Research Issues, ACM Computing Surveys, Vol. 19, N -~ 3, September 1987, pp. 201-260.

12. International Standard Organization, Concepts and Terminology for Conceptual Scheme and Information Base, ISO TR #9007, 1982.

13. W. Kent, Limitations of Record-based Information Models, ACM Transactions on Database Systems, Vol. 4, N -~ 1, March 1979, pp. 107-131.

14. R. King, My Cat is Object-Oriented, in: W. Kim, and F. H. Lochovsky (eds.): Object-Oriented Concepts, Databases, and Applications, Addisom-Wesley, 1989, pp. 23-30.

15. J. Martin and J. Odell, Object Oriented Analysis and Design, Prentice Hall, Englewood Cliffs, N.J., 1992.

16. F. R. McFadden• C•nceptua• Design •f Object-Oriented Databases•J•urnal •f •bject-•riented Programming: Focus on ODBMS, SIGS, 4(4), July/August, 1991, pp. 23-26.

17. B. Meyer, Reusability: The Case for Object-Oriented Design, IEEE Software, Vol. 4, N -~ 2, 1987, pp. 50-64.

18. B. Meyer, Object-oriented Software Con.~truction, Prentice-Hall lnternacional, 1988. 19. B. Meyer, Eiffel The Language, Prentice Hall Object-Oriented Series, 1992. 20. D .E . Monarchi and G. 1. Puhr, A Research Typology for Object-Oriented Analysis and

Design, Comm. ofAcm, Vol 35, N ~ 9, September 1992, pp. 35-46. 21. J.-M. Nerson, Applying Object-Oriented Analysis and Desing, Comm. ofACM, Vol 35, N ~ 9,

September 92, pp. 65-74. 22. Ontologic, ONTOS Reference Manual, ONTOS Inc., 1992. 23. J. Peckham, and F. Maryanski, Semantic Data Models, ACM Computing Surveys, Vol. 20, N ~

3, September 1988, pp. 153-189.

270

24. B. Pernici, Objects with Roles, in: F. H. Lochovsky, R. B. Allen, Proceeding of the Conference on Office Information Systems, SIGOIS Bulletin, Vol. 11, Issues 2, 3, ACM Press, 1990, pp. 205-215.

25. T. Reenskaug et al., OORASS: seamless support for the creation and maintenance of object oriented systems, Journal of Object-Oriented Programming, 5 (6), October, 1992, pp. 27-41.

26. J. Rumbaugh, Relations as Semantic Constructs in an Object-Oriented Language, in: Proceedings of the Conference On Object-Oriented Programming Systems, Languages and Applications-87, SIGPLAN NOTICES, Vol. 22, N*- 12, December 1986.

27. J. Rumbaugh, M. Blaha, W. Permerlani, F. Eddy and W. Lorensen, Object-Oriented Modelling and Design, Prentice-Hall 1991.

28. A. Sernadas and H.-D. Ehrich, What is an Object After All, in: R. A. Meersman, W. Kent and S. Khosla (eds.), Object Oriented Dtabases: Analysis, Design and Construction (DS-4), (Proc. IFIP TC2/WG2.6 Working Conference, Windermere, UK (1990), North-Holland, 1991.

29. S. Shlaer and S. J. Mellor, Object Oriented System Analysis: Modeling the World in Data, Yourdon Press, Englewood Cliffs, N.J., 1988.

30. H.A. Smith and D. C. P. Smith, Database Abstractions: Aggregation and Generalization, ACM Trans. Database Systems, 2(2), March, 1977, pp. 105-133.

31. L.A. Stein, H. Lieberman, and D. Ungar, A Shared View of Sharing: The Treaty of Orlando, in: W. Kim and F. H. Lochovsky (eds.), Object-Oriented Concepts, Databases, and Applications, Addisom-Wesley, 1989, pp. 31-47.

32. L.A. Stein & S. B. Zdonik, Clovers: The Dynamic Behavior of Types and Instances, Brown University, Dept. of Computert Science, Technical Report N Q CS-89-42, November 1, 1989.

33. B. Stroustrup, The C+§ Programming Language, 2 g Edition, Addison-Wesley, Reading, MA, 1992.

34. J.T. Teorey, D. Yang, and J. P. Fry, A Logical Design Methodology for Relacional Databases Using the Extended Entity-Relationship Model, ACM Computing Surveys, Vol. 18, N -~ 2, June 1986, pp. 197-222.

35. P. Wegner, Concepts and Paradigms of Object-Oriented Programming, ACM SIGPLAN, OOPS Messenger, Vol. 1, N ~ 1, August 1990.

36. R.J. Wirfs-Brock and R. E. Johnson, Surveying Current Research in Object-Oriented Design, in: Com. ofACM, Vol 33, N Q 9, September 90, pp. 104-124.

37. A.V. Velho, SOM: A Semantic Object Model - Motivations, Concepts and Languages, (in Portuguese) INESC Thecnical Report, 1992.

38. E. Yourdon, Modern Structured Analysis, Yourdon Press, Cliffs, N.J., 1989.Englewood