] DATA &

ELSEVIER Data & Knowledge Engineering 17 (1995) 159-181

KNOWLEDGE ENGINEERING

MOODD, a method for object-oriented database design

Mauricio J.V. Silva, C. Robert Carlson*
Department of Computer Science, Armour College of Engineering and Science, Illinois Institute of Technology, 10 West 31st Street, Chicago, IL 60616, USA
Received 18 March 1993; revised 6 June 1994; accepted 4 October 1994

Abstract

In this paper we propose a Method for Object-Oriented Database Design, called MOODD. Considerable recent research [22] has focused on object-oriented design techniques. MOODD distinguishes itself by generating an object-oriented data definition from requirements written in a natural language. Examples to illustrate the method are given for a particular OODBS called 02 [19]. MOODD consists of three phases. The first phase is to use a Requirement Specification Language (RSL) [27] to represent user requirements. Next, the RSL requirements are converted into an object-oriented conceptual model composed of the Nested Entity-Relationship (NER) [10]/ Update Protocol Model (UPM) [9]. Finally, the NER/UPM schemas are implemented by an object-oriented data model

Keywords: Object-Oriented Database; Conceptual database design; Entity-Relationship; Natural language; Requirement specification language

I. Introduction
New and emerging database applications, such as office information, CAD/CAM and CASE, demand the capability to model very complex objects and the ability to change them without affecting the current application base [30]. Object-oriented Database Systems (OODBS) [2] try to solve these problems by using facilities like data abstraction and inheritance to manage data, and by providing an active data model that captures the semantics and behavioral constraints of data. To effectively use this technology, a wide range of object-oriented modeling and design techniques have been proposed [22]. This paper adds to this research an integrated design approach which employs natural language as a cornerstone of design. The focus of this paper is: (i) to develop object-oriented modeling techniques which express requirements in a natural language, such as English; (ii) to utilize automated analysis techniques for identifying natural language expressions that describe both simple and complex
* Corresponding author. Email: silvmau@minna.acc.iit.edu 0169-023X/95/$09.50 (~) 1995 Elsevier Science B.V. All rights reserved SSDI: 0 1 6 9 - 0 2 3 X ( 9 5 ) 0 0 0 2 1 - 6

160

M.J.V. Silva, C.R. Carlson / Data & Knowledge Engineering 17 (1995) 159-181

objects; (iii) to utilize an object-oriented approach that yields an object-oriented database design; and (iv) to support automatic documentation of object-oriented database designs based on natural language expressions. In this paper, a Method for Object-Oriented Database Design, called MOODD, is presented. According to MOODD, the design process can be divided into three phases as described in Fig. 1. In the first phase, a natural language requirement specification language (RSL) [27] is used to represent user requirements. Next, the RSL requirements are translated into an object-oriented conceptual model composed of nested entity-relationship diagrams (NER) [10] and update protocol model expressions (UPM) [9]. Together, these models capture both the static and dynamic aspects of objects. Finally, the NER diagrams and UPM expressions are implemented by an object-oriented data model. Examples to illustrate the method are given for a specific object-oriented data model called 02. We chose the NER/UPM for the object-oriented conceptual model, because we had already developed an object-oriented modeling tool [17]. This tool allows designers to develop NER/UPM designs of objects and automatically produces relational database schemas from these designs. Many methods for database design have used a restricted natural language approach to requirements specification [1, 3, 6, 12, 23, 25], but not all have carried it through to the design of an object-oriented database. Chen [12] proposed eleven grammatical rules for translating English statements into ER diagrams. For instance, in Chen's statements, nouns correspond to entities, verbs to relationships, adjectives to entities' attributes and adverbs to attributes of relationships. Nijssen [23] developed a methodology called NIAM, a fact oriented approach based on requirements written in a natural language. The information obtained from the user relative to data requirements are represented in a conceptual model composed of facts and rules represented by ENALIM diagrams. The output of the methodology includes data structured maps and records. Batini [6] developed a method for database design which uses natural language, forms and conventional file systems as user requirements. From these requirements a conceptual model composed of ER diagrams is derived. He also proposed several rules of thumb to restrict natural language requirements, resulting in the identification of sentence templates relevant to database design, i.e. sentences that refer to data, operations, events or constraints.

1st Phase

2nd Phase

3rd Phase

I RSL Specification

Object-Oriented Conceptual Model: NER diagrams/ [ UPM expressions

NER diagramd UPM expressions/

i
I

OODBS

Fig. 1. Describing the three phases of M O O D D .

M.J.V. Silva, C.R. Carlson / Data & Knowledge Engineering 17 (1995) 159-181

161

Andonoff [1] developed a method for object-oriented database design divided into two steps. The first step is to define a set of functional and multivalued dependencies between elementary properties derived from specifications written in a natural language. Then, this set of dependencies are reduced eliminating redundancy. In the second step the set of reduced dependencies are derived into an object-oriented schema. Rumbaugh [25] proposed an object-oriented software development methodology, called OMT, which extends from analysis through design to implementation. The OMT uses three kinds of models to describe a system, which are applicable during all stages of software development: the object model represented by object diagrams, the dynamic model represented by state diagrams and the functional model represented by data flow diagrams. The models are derived from the problem statement written in English. Initially, the methodology looks for nouns as potential objects, verbs or verb phrases as associations and adjectives as attributes. Then, the unnecessary and incorrect objects, associations and attributes are eliminated according to a set of criteria. Finally, the models are implemented in a relational database according to a set of guidelines. Bailin [3], proposed an object-oriented requirement specification method starting from user requirements stated in English. The method uses ER diagrams, Entity data flow diagrams (EDFD) and an Entity dictionary as a conceptual model. The method looks for nouns or noun-phrases as potential entities, which are then classified as active or passive entities. An active entity operates on inputs to produce outputs and a passive entity is one that is acted upon. Table 1 summarizes all these approaches, classifying them according to the following issues: Requirement Language, Modeling Capability, Conceptual Model and Target System. An analysis of Table 1 shows that our approach is more comprehensive than the other proposed approaches. It has the following advantages: (i) It utilizes a natural language approach to requirements specification by using RSL. (ii) It models both the static (structure and associations) and dynamic (behavior) properties of complex objects. (iii) It utilizes an object-oriented conceptual model NER, which is an extension of the ER model. (iv) It describes explicitly the dynamic object behavior of the application with UPM expressions. (v) It develops an application with an object-oriented data model, which is semantically richer than the relational model. The remainder of this paper is organized as follows. Section 2 describes how requirements specification is defined in RSL. Section 3 describes the translation of RSL into an objectoriented conceptual schema composed of NER diagrams and UPM expressions. Section 4 describes the translation of NER diagrams and UPM expressions into an object-oriented data model. Section 5 summarizes the paper.

2. Describing requirement specifications with RSL

The problem of determining and documenting user requirements is one of the most difficult tasks in database design [16]. Many systems have failed because system analysts and designers did not understand user needs. This failure is due to the lack of communication between users

162

M.J.V. Silva, C.R. Carlson / Data & Knowledge Engineering 17 (1995) 159-181

Table 1 R e l a t e d database design approaches Method Andonoff Requirement language / input Natural language Modeling capability - Simple static objects - Simple static objects Dynamic object behavior - Simple static objects
-

Conceptual model - Functional and multivalued dependencies - E R diagram - Entity data flow diagram - Entity dictionary E R diagram

Target system / output A n y obiectoriented data model None

Bailin

Natural language

Batini

Chen Nijssen ( N I A M )

- Forms Natural lang. - Conv. file systems Natural language

-

Relational model None Records / data struct. maps - Relational model

Natural language

Rumbaugh (OMT)

Natural language

Silva ( M O O D D )

Natural language/ RSL

- Simple static objects - Simple static objects - Dynamic object behavior - Simple static objects Dynamic object behavior - Complex static objects - Dynamic object behavior
-

E R diagram - Facts - Rules - ENALIM - Object diagram - State diagram - D a t a flow diagram - N E R diagram - U P M expressions

A n y objectoriented data model

and analysts. Unfortunately, misunderstandings of the user requirements are perceived too late, after a lengthy and costly implementation of the system has already been completed [29]. M O O D D ' s approach to this problem is to specify requirements in RSL, a restricted subset of English. RSL uses formally structured English sentences to describe "real world" requirements. The intention is to reduce the misunderstanding gap between the user and the analyst, since the user should be able to read the requirements with little help and validate whether it does describe the system. The RSL syntax provides sentences that describe both the static and dynamic aspects of a system. It is possible to describe both binary and n-ary relationships, with their respective cardinalities, in order to better represent the semantics of the system. Finally, RSL was designed to represent all the features of the target models, i.e. N E R and UPM. Therefore, there exists a direct mapping between each sentence in RSL and N E R / U P M . Another advantage to using RSL is that the English sentences used to describe the requirements provide long term system documentation. In addition, one can develop computerized tools to analyze and validate the RSL specifications, because it was defined with formally structured sentences using keywords. The validation would check for inconsistencies

M.J.V. Silva, C.R. Carlson / Data & Knowledge Engineering 17 (1995) 159-181

163

in the RSL requirements (e.g. a complex entity which has been mentioned in one sentence, but not defined with attributes or component objects). The main features of RSL are: It defines data using sentences that incorporate the concept of data abstraction, specifically aggregation and generalization. It supports sentences which define integrity constraints of a system. It supports sentences that represent events. A University database specification is described in Fig. 2 illustrating some of the RSL syntax rules. This specification will be used later to illustrate the steps of the MOODD method. A full description of the RSL syntax rules is given in Appendix A.

3. Translating RSL into an object-oriented conceptual model

In this section we describe the second phase of MOODD, showing the translation of RSL requirements into an object-oriented conceptual model composed of NER diagrams and UPM expressions. The NER and UPM models are used to represent the static and dynamic aspects of the schema respectively. We use the following steps to translate RSL sentences into NER diagrams and UPM expressions: (i) Check for synonyms and homonyms (ii) Use a glossary to ensure uniform use of words. (iii) Group sentences describing the static properties of the same subject into paragraphs called O-paragraphs. (iv) Group sentences describing the dynamic properties of the same subject into paragraphs called BR-paragraphs (Business Rules). (v) For each O-paragraph, analyze each sentence converting it to the corresponding NER object. (vi) For each BR-paragraph, analyze each sentence converting it to the corresponding UPM expression. Subsection 3.2 illustrates the translation process, applying the steps described above to the university database described in Fig. 2. However, before we get into the translation itself, it is important to have an understanding of the object-oriented conceptual model, briefly described below.
3.1. Object-oriented conceptual model ( N E R diagrams/UPM expressions)

The object-oriented conceptual model is composed of NER diagrams and UPM expressions. The NER diagrams represent the static aspects of the schema, and provide both a natural and theoretically sound database description [10]. The NER model employs multi-level diagrams, where each subdiagram is composed of a set of entity types and relationship types. The main difference from the entity-relationship model [11] is that entities and relationships in the NER model can be both simple or complex. Complex objects can be expanded into subdiagrams, where a more detailed specification is provided. Complex entities are represented by a bold rectangle and complex relationships are represented by a bold diamond. Another advantage of using NER diagrams is that they support aggregation and generaliza-

164

M.J.V. Silva, C.R. Carlson / Data & Knowledge Engineering 17 (1995) 159-181

Static_l) Database Object/Major Object: - "lhe University model consists of Departments and Employees. Static_2) Entity Object/Attributes - Each Employee is identified by a SS# and is characterized by its unique name, salary, address and phone number. Each Department is identified by a name and is characterized by its unique department number and location. Each Student is identified by a SS# and is characterized by its unique name, major, and number of credit hours completed. - Each Faculty member is characterized by its unique academic rank and degree. Each Course is identified by a name and is characterized by its u m q u e course number and credits.
-

Static_3) Entity / Aggregation - Each Department consists of related Faculty, Students and Courses. Static_4) Entity/Generalization - Each Employee can be either a Faculty member or a Staff member. - Each Faculty member can be either an Instructor or an Assistant Professor or a Associate Professor or a Full Professor or a Chairman. A Student can be either a Undergraduate or a Master of Science Student or a Ph.D. Student.

Static_5) Relationship/Attributes - Each Student enrolls in one or more Courses for each semester. - Each Professor advises one or more Students. - Each Faculty member teaches one or more Classes. Static_6) Relationship/Generalization - There is no application of this rule in the University database. Static_7) Relationship/Aggregation - Employee and Department are involved in a work relationship through the following subrelationships: a Faculty member is an Employee, Department has Courses, Department has Students, a Faculty member teaches Courses and a Faculty member advises Students. Dynamic_l) Business Rules / Events with Triggers - When a University hires a new Faculty member, if he has a Ph.D. Degree implies that he would be assigned the rank of Assistant Professor, otherwise he would be assigned the rank of Instructor. When a Faculty member has retired, resigned or been fired implies that the Faculty member doesn't teach anymore and implies that the Faculty member doesn't advise anymore.
-

Dynamic_2) Business Rules/Events with Preconditions. - When a Faculty member is assigned Courses, he is subject to the following constraint: a Faculty member cannot teach more than two Courses in a semester. Dynamic_3) Business Rules/Events with Postconditions. - When a Faculty member is promoted to Assistant-Professor, it must hold that: this Faculty member is an Assistant-Professor.

F i g . 2. U n i v e r s i t y

database

described

with RSL

syntax

rules.

M.J.V. Silva, C.R. Carlson / Data & Knowledge Engineering 17 (1995) 159-181

165

tion [28], for constructing complex objects. Generalization can be used to represent class hierarchies among objects, describing the relationships between a generic object type and its sub-object types. Aggregation is used to describe one object in terms of other objects. UPM is a formal language for expressing update semantics. As such, it provides a precise notation for expressing the dynamic aspects of the schema. In particular UPM supports: (a) multiple refinements to interpretation of the relationship concept; (b) data abstractions, such as generalization and aggregation; and (c) behavioral schemas, describing permissible activities or events which change the static aspects of the schema. UPM consists of a powerful collection of update protocols which can be defined over objects. An update protocol consists of three parts, a list of protocol context, an optional list of constraint expressions, and an optional list of trigger expressions. The BNF definition of the update protocol is described below:
(Update-Protocol) ::= (Protocol Context List) J[(Constraint Expression List)]l[(Trigger Expression List)] (Protocol Context List) ::= (Protocol Context) ( ( Protocol Context) } (Protocol Context)::= INSERT object IN class l DELETE object FROM class l REPLACE object IN class (Constraint Expression List) ::= (Constrain Expression) { (Constrain Expression) } (Constraint Expression) :: = PRECOND (Predicate Expression) I POSTCOND (Predicate Expression) (Predicate Expression) ::= [(Range Expression)] I (Boolean Expression) (Range Expression) ::= [31V] object E~class [( Range Expression)] (Trigger Expression List)::= (Trigger Expression){(Trigger Expression)} (Trigger Expression) ::= IMPLIES (begin) (Protocol Context) : (Predicate Expression) (end) (begin) ::= { (end) ::= }
3.2. Translating the University database in R S L into N E R and U P M

The first and second steps, checking for synonyms, homonyms and building a glossary of terms, is a good way to understand the meaning of terms and remove ambiguities from the requirements. In our example, the terms Faculty member and Professor (in static rule 5) refer to the same concept. Classes and Courses also refer to the same concept. We correct these ambiguities, changing all appearances in the text of the term Professor to Faculty member and the term Classes to Courses. Then, we apply the third and fourth steps, partitioning the sentences into O-paragraphs(static) and BR-paragraphs(dynamic), according to its subject. We can determine if a sentence represents a static or a dynamic aspect by identifying which RSL syntax rule was used to derive the sentence. For instance, from our example, the only sentence used to describe the subject University was derived by applying RSL static rule 1. Therefore, this sentence should appear in the University O-paragraph. From our example we identify seven major subjects: University, Employee, Department, Student, Faculty Member, Course, Staff. In Fig. 3(a) we list all these subjects showing the partitioning of the sentences into O-paragraphs. In Fig. 3(b), we show the partitioning of the sentences into DR-paragraphs. Only one BR-paragraph related to the subject Faculty member was created, since there are no sentences describing dynamic aspects for other subjects. Next, we apply step 5, deriving the NER diagrams from the O-paragraphs described in Fig. 3(a). Subsection 3.2.1 describes the details of this translation. Finally, we apply step 6,

166

M.J.V. Silva, C.R. Carlson / Data & Knowledge Engineering 17 (1995) 159-181

(a)
O-Paragraphs:

Subject: University . The University model consists of Departments and Employees

Subject: Employee

Each Employee can be either a Faculty member or a Staff member. Employee and Department are involved in a work relationship through the following subrelationships: a Faculty member is an Employee, Department has Courses, Department has Students, a Faculty member teaches Courses and a Faculty member advises Students. Each Employee is identified by a SS# and is characterized by its unique name, salary, address and phone number. Subject: Department Each Department consists of related Faculty member, Students and Courses. Each Department is identified by a name and is characterized by its unique department number and location.
Subject: Student

A Student can be either a Undergraduate or a Master of Science Student or a Ph.D. Student. Each Student is identified by a SS# and is characterized by its unique name, major, and number of credit hours completed Each Student enrolls m one ore more Courses for each semester. Subject: Faculty member Each Faculty member can be either an Instructor or an Assistant Professor or Associate Professor or a Full Professor or a Chairman. Each Faculty member is characterized by its unique academic rank and degree. Each Faculty member advises one or more Students. Each Faculty member teaches one or more Courses.
Subject: Course

Each Course is identified by a name and is characterized by its unique course number and credits.

Fig. 3(a). P a r t i t i o n i n g R S L s e n t e n c e s i n t o O - p a r a g r a p h s .

(b}
BR-Paragraphs:

Subject: Faculty member When a University hires a new Faculty member, if he has a Ph,D. Degree implies that he would be assigned the rank of Assistant Professor, otherwise he would be assigned the rank of Instructor. When a Faculty member has retired, resigned or been fired implies that the Faculty member doesn't teach anymore and implies that the Faculty member doesn~ advise anymore. . When a Faculty member is assigned Courses, he is subject to the following constraint: a Faculty member cannot teach more than two Courses in a semester. . When a Faculty member is promoted to Assistant-Professor, it must hold that: this Faculty member is an Assistant-professor.

Fig. 3 ( b ) . P a r t i t i o n i n g R S L s e n t e n c e s i n t o B R - p a r a g r a p h s .

M.J.V. Silva, C.R. Carlson / Data & Knowledge Engineering 17 (1995) 159-181

167

deriving the UPM expressions from the BR-paragraphs defined in Fig. 3(b). Subsection 3.2.2 describes the details of this translation. 3.2.1 Translating O-paragraphs into N E R diagrams We start by analyzing each sentence in an O-paragraph. For each such sentence we determine which RSL static rule (see Appendix A.1 for details) was used to derive it. By determining the RSL static rule we automatically determine the NER object, because each RSL static rule represents a particular type of NER object. For instance, the sentence used to describe the subject Course was generated by applying RSL static rule 2, which represents an entity/object with attributes. Therefore, an entity Course with attributes name, course number, and credits should be created in the NER diagram. Once we have identified all the NER objects, we can start designing our diagram. Usually, we begin drawing our NER diagram at level 1, representing the database major object. From the sentence which describes the database major object, we determine its name and all of its subentities. Then, we create a complex entity with the database name at level 1. Next, we create a level 2 diagram, where we represent all the subentities of the database major object. At level 2, we also refine each subentity with its attributes and relationships '~xtracted from the related O-paragraph. In our example, University is the database major object and the subentities are Department and Employee. Finally, for each complex object (entity or relationship) we create a new level diagram where we refine it. The creation of new levels of refinement only stops, when a diagram with only simple objects has been reached. Fig. 4 illustrates the NER diagram derived from the O-paragraphs in Fig. 3(a) with the following NER objects: Database Major Object (University), Aggregate Entity (Department), Generalized Entities (Employee, Faculty member, Student), Aggregate Relationship (Work), Simple Entities (Course), and Simple Relationships (Teach, Advise, Enroll). 3.2.2 Translating BR-paragraphs into UPM expressions We begin by analyzing each sentence in a BR-paragraph. For each such sentence we determine which RSL dynamic rule was used to derive it. According to the RSL dynamic rule we apply a set of heuristics to the sentence, generating the equivalent UPM expression. There are three types of sentences (see Appendix A.2) generated by applying RSL dynamic rules. RSL dynamic rule 1 produces sentences that describe events with triggers. An event is composed of an agent, an action, and an object receiver. A trigger can have an associated event and a conditional phrase. RSL dynamic rule 2 produces sentences that describe events with preconditions. The preconditions are defined by a list of preconditions. RSL dynamic rule 3 produces sentences that describes events with postconditions. The postconditions are defined by a list of postconditions. The translation of BR-paragraphs into UPM expressions using a set of heuristics is described in the following subsection. 3.2.2. 1 Heuristics for translating BR-paragraphs into UPM expressions. We defined a set of heuristics which guides the translation of BR-paragraphs into UPM expressions. The heuristics are based on the syntactic description of the three types of RSL dynamic rules given in

168

M.J.V. Silva, C.R. Carlson / Data & Knowledge Engineering 17 (1995) 159-181

Level 1:

Level 2 : ~

Unbendty- Dstebwe Msjwr O b ~

I.~,d 3: D a ~ q

- c ~ t ' a d i ~ l Zan

s
Levi 4 : I ) ~ r l b l / g Delmrfmeut - A g g r e l p t e Earl~

I :-ll
~ s :u , , ~ w~ -~ s , , ~ . k ~ J a p

I [-----~- q

I~.~I 6: D,~t'll~ I ~

Member'- Generslb~ Itnmy

rdl6on~ip ~ - n:fmil~a ~ p i ~ t objoetto tl~ rl~ Icwl

Fig. 4. NER diagram of the University database.

Appendix A.2. For each rule we apply a combination of different heuristics. The heuristics are: heuristic_l) Identify the UPM syntactic parts from the sentence, i.e. Event, Agent, Action, Object Receiver, Trigger, Associated Event and Conditional Phrase, List of Preconditions, and List of Postconditions. heuristic_2) Analyze the action of the event and determine if the UPM statement will be applied to the agent of the event, to the object receiver, or to the relationship between the agent of the event and the object receiver. If the action indicates that: (i) a new element is being created, then generate a UPM INSERT statement. (ii) an element is being deleted, then generate a UPM D E L E T E statement. (iii) an element is being replaced, then generate a UPM R E P L A C E statement.

M.J.V. Silva, C.R. Carlson / Data & Knowledge Engineering 17 (1995) 159-181

169

heuristic_3) For each trigger create a UPM IMPLY statement. Then, for each trigger apply heuristic_l and heuristic_2 to its associated event constrained by the conditional phrase. heuristic_4) If the object receiver is an specialization of a general object, create an UPM IMPLY statement. Then, apply heuristic_l and heuristic_2 to a new event that has the same agent and action of the original event, but change the object receiver to be the generalized entity. heuristic_5) Generate an UPM P R E C O N D statement followed by a List of Preconditions. heuristic_6) Generate an UPM POSTCOND statement followed by a List of Postconditions. We illustrate the translation process for each type of dynamic rule with three examples. We show the intermediate and final UPM expressions generated after applying the set of heuristics described above to a sentence. A sentence defined by RSL dynamic rule 1 is translated into an UPM expression by applying heuristics 1, 2, 3, and 4, as illustrated below:
Example (i). Sentence: When a University hires a new Faculty member, if he has a Ph.D. Degree implies that he would be assigned the rank of Assistant Professor, otherwise he would be assigned the rank of Instructor.
(a) Applying heuristic_l to the sentence above we have the following: Event: University hires a new Faculty member Agent: University Action: hires = create Object Receiver: Faculty member Trigger: Associated Event: Assigned rank of Assistant Professor Conditional Phrase: rank = Ph.D. Associated Event: assigned rank of Instructor Conditional Phrase: rank ~ Ph.D. (b) Applying heuristic_2 The action (hires) is applied to the object receiver(Faculty member). The action(hires) of the event represents a creation of a new Faculty member. Thus, we have an UPM INSERT to Faculty member. UPM: INSERT f in Faculty-member (c) Applying heuristic_3 We have two triggers, so we generate two UPM IMPLIES. We have two associated events with actions indicating creation. Thus, we generate an UPM INSERT for each associated event (Assistant-Professor, Instructor).

UPM:
INSERT f in Faculty-member IMPLIES {INSERT a in Assistant-Professor I a[SS#] = f[SS#] AND f[rank] = "Assistant-Professor" AND a[TA - SS#] = INPUT (Assistant-Professor, a[SS#], Ta - SS#) AND f[degree] = "Ph.D." } IMPLIES {INSERT a in Instructor I i[SS#] = f[ss#] AND f[rank] = "instructor" AND a[Ti - SS#] = INPUT (Instructor, a[SS#], T i - SS#) AND

170

M.J.V. Silva, C.R. Carlson / Data & Knowledge Engineering 17 (1995) 159-181
f[degree] not = "Ph.D." }

(d) Finally, applying heuristic_4 Generalized Entity of Faculty member:Employee. Create an UPM IMPLY statement and then create a new event hiring an Employee. UPM: INSERT f in Faculty-member IMPLIES {INSERT e in Employeel e[SS#] = f[SS#] AND e[te - SS#] = INPUT (Employee, e[SS#], te - SS#) } IMPLIES {INSERT a in Assistant-Professorl a[SS#] = f[SS#] AND f[rank] = "Assistant-Professor" AND a[Ta - SS#] = INPUT (Assistant-Professor, a[SS#], Ta - SS#) AND f[degree] = "Ph.D." } IMPLIES {INSERT a in Instructor I i[SS#] = f[SS#] AND f[rank] = "instructor" AND a[Ti - SS#] = INPUT (Instructor, a[SS#], Ti - SS#) AND f[degree] not = "Ph.D." }

A sentence defined by RSL dynamic rule 2 is translated into an UPM expression by applying heuristics l, 2 and 5, as illustrated below:
Example (ii). Sentence: When a Faculty member is assigned Courses, he is subject to the following constraint: a Faculty member cannot teach more than two Courses in a semester.
(a) Applying heuristic_l to the sentence above we have the following: Event: Faculty member is assigned Courses Agent: Faculty member Action: Assigned = create Object Receiver: Course List of Precondition: A Faculty member cannot teach more than two Courses in a semester. (b) Applying heuristic_2 The action (assign) is applied to the relationship (Teach) between the agent of the event(Faculty member) and object receiver(Course). The action(assign) of the event represents a creation of a new relationship between Faculty member and Course. Thus, we have an UPM INSERT to the relationship Teach. UPM: INSERT t in Teach (c) Applying heuristic_5 to the sentence: Generate UPM PRECOND followed by the precondition that a Faculty member cannot teach more than two Courses in a semester. UPM" INSERT t in Teach PRECOND ~- f E~Faculty-member f[SS#] = t[FACULTY_SS#] AND COUNT (t[FACULTY_SS#] < 2)

A sentence defined by RSL dynamic rule 3 is translated into an UPM expression by applying heuristics 1, 2 and 6, as illustrated below:

M.J.V. Silva, C.R. Carlson / Data & Knowledge Engineering 17 (1995) 159-181

171

Example (iii). Sentence: When a Faculty member is promoted to Assistant-Professor, it must hold that: this Faculty member is an Assistant-Professor. (a) Applying heuristic_l to the sentence above we have the following: Event: Faculty member is promoted to Assistant-Professor Agent: Faculty member Action: Promoted = replace Object Receiver: Assistant-Professor List of Postcondition: Faculty member is an Assistant-Professor. (b) Applying heuristic_2 to the sentence. The action (promote) is applied to the Agent(Faculty member).
The action(promote) of the event represents an update to an existing Faculty member. Thus, we have an UPM REPLACE to Faculty member. UPM: REPLACE f in Faculty member

(c) Applying heuristic_6 to the sentence: Generate UPM POSTCOND followed by the postcondition that the Faculty member is an AssistantProfessor. UPM: REPLACE f in Faculty-member
POSTCOND --- f ~EFaculty Member

f[rank] = "Assistant-Professor"

4. Implementing NER diagrams and UPM expres:~ions using an object-oriented data model An object-oriented data model represents both the static (structures and associations) as well as the dynamic (behavior) aspects of real world objects. Previous approaches to mapping semantic networks and ER diagrams into an object-oriented data model have been proposed by [7, 8, 21, 26]. The problem with these approaches is that they have not dealt with the transformation of complex objects nor considered the dynamic aspects of objects. We address this problem, since our approach maps simple and complex objects and their dynamic properties into an object-oriented data model. We implement the NER diagrams and UPM expressions with an object-oriented data model, using the following steps: (i) Define classes (ii) Define persistent classes (iii) Define Methods Examples of the implementation process are given for a particular OODBS called 02. But, we believe that our approach is general enough to be used by any OODBS, as long as it supports the concepts of classes, methods and persistent classes. Before we get into the implementation itself and show some examples in 02, it is important to have an understanding of the 0 2 data model.
4.1. Brief description o f the 0 2 data model

The basic elements of the 0 2 data model are objects and types, type constructors and type hierarchies [19]. The data nanipulation language is called CO2 [15], composed of the C language with embedded 0 2 expressions.

172

M.J.V. Silva, C.R. Carlson / Data & Knowledge Engineering 17 (1995) 159-181

In the 0 2 data model an object is an abstract machine, which encapsulates data and operations. An object has an identifier (the name of the object) and a value. The value can be atomic (e.g. string, integer, real . . . . ), tuple structured, set structured or list structured. Objects can also be built from constructors like sets, lists or tuples, defining complex objects. For example:
(objl: [obj2, obj3]) (obj2: [name: "John", age: 24]) (obj3: [name: "Mary", age: 20])

A type is a description of an object, organized to support aggregation and generalization. A type i~ declared to be subtype of another type, if all instances of the subtype are also instance of the supertype. A class is a set of objects of the same type. The following expressions are examples of classes:
Employee = [name: string; address: string; salary: real] Faculty = [i1: Employee; degree: string]

The operations of a type are described by methods. An object of a given type can only be accessed through methods. The definition of an object's state (data structure) and implementation of methods are hidden inside the object. This hiding concept introduces the notion of encapsulation, emphasizing object independence. In order to become persistent, objects must be named. This is referred to as the extension concept in 0 2 [14]. For instance, the following declaration defines an extension N for class X:
add name N: set(X);

The CO2 language supports the declaration of types and methods. A method is characterized by its signature (its name, its type and the type of its parameters), and its body (procedure) [19]. An example of the CO2 language describing types and methods is given below:
/* type declaration */

add class Employee type tuple (ss: string, name: string, address: string, salary: real) add class Faculty inherits Employee type tuple (degree: string)
/* method declaration */

add method init( ): Employee in class Employee is public body init( ): Employee in class Employee C 0 2 { self-)ss= input (02 string);
self-)name = input (02 string); self-)address = input (02 string); self-)salary = input (02 real);

M.J.V. Silva, C.R. Carlson / Data & Knowledge Engineering 17 (1995) 159-181
return (self);}$; add name EXTEMPLOYEE: set(Empolyee);

173

The keyword inherits defines hierarchies of types. The keyword is public makes the method visible from anywhere. The keyword in class defines to which class the method belongs. The brackets { } delimit the C code with embedded 0 2 expressions. The variable self inside the method represents the object to which the method is being applied. Finally, the keyword add name defines the extension for class Employee.
4.2. Defining classes

System classes are created by applying a set of rules to the NER diagram, and for each rule an example in 0 2 is given. The 02 example is the result of applying the corresponding rule to the NER diagram defined in Fig. 4. The rules are: el_l) Translate all the entities of the NER diagram into classes. 02 Example: Mapping the entity Employee into a class.
Add class Employee;

c1_2) Map all the attributes of an entity into the corresponding class. 02 Example: Mapping the attributes of entity Employee (described in diagram level 2).
add class Employee

type tuple
(ss: string, name: string, address: string, phone: string);

c1_3) Define a superclass for each specialized subentity. The superclass has the same name of the generalized entity. Each subentity inherits all the attributes of the generalized entity. 02 Example: Mapping the generalized entity Employee (superclass), which has two subentities: Faculty member and Staff member (described in diagram level 3).
add class Faculty-member inherits Empolyee; add class Faculty-member inherits Employee;

c1_4) Map an aggregate entity into a class with reference attributes to each subentity class. Then, for each subentity add a new attribute referencing the aggregate entity class. 0 2 Example: Mapping the aggregate entity Department (described in diagram level 4) which has Faculty member, Student and Course as subentities. A class Department is created with three reference attributes F, S, and C referencing the classes Faculty-member, Student and Course respectively. Then, a reference attribute D to the class Department is added to each subentity class definition (Faculty member, Student and Course).
add class Department...

type tuple (... F: Faculty_member,

174

M.J.V. Silva, C.R. Carlson / Data & Knowledge Engineering 17 (1995) 159-181
S:Student, C:Course); class Faculty_member... tuple ( . . . . D: Department); class Student.., tuple ( . . . . D: Department); class Course... tuple ( . . . . D: Department);

add type add type add type

el_5) Map a simple/complex relationship according to the multiplicity and degree of the relationship. (a) Binary relationship with no attributes. Map a binary relationship with no attributes as a reference attribute to the classes representing the entities involved in the relationship. Binary relationships with no attributes are represented as follows: One-to-one relationship (1:1) between entities A and B. Create classes A and B from entities A and B respectively. Add a reference attribute al referencing class B in class A, and add a reference attribute bl referencing class A in class B. One-to-many relationship ( I : N ) between entities A and B. Create classes A and B from entities A and B respectively. Add a reference-set attribute al referencing class B in class A, and add a reference attribute bl referencing class A in class B. Many-to-many relationship ( N : M ) between entities A and B. Create classes A and B from entities A and B respectively. Add a reference-set attribute a l referencing class B in class A, and add a reference-set attribute bl referencing class A in class B. 0 2 Example: Mapping the complex binary relationship Works (described in diagram level 2) between Department and Employee. A new reference attribute DE in class Department is created to reference class Employee and a new attribute ED is created to reference the class Department.
add class Department...
type tuple ( . . . . DE: Employee); add class Employee... type tuple ( . . . . ED: Department);

(b) Binary relationship with attributes. Map a binary relationship with attributes as a new class using the same name of the relationship. The attributes of the new class are a combination of all the relationship attributes and reference attributes to the classes representing the entities involved in the relationship. Binary relationships with attributes are mapped exactly the same way in the case of a one-to-one, one-to-many, and many-to-many relationship. Thus, for a 1:1, I : N and N : M relationship R with attribute rl between entities A and B, create a new class R with attribute r l and two other reference attributes r2 and r3 referencing classes A and B respectively. 0 2 Example: Mapping the relationship Enrolls (described in diagram level 4) with attribute semester between Student and Course. A new class Enroll is created with an attribute

M.J.V. Silva, C.R. Carlson / Data & Knowledge Engineering 17 (1995) 159-181

175

semester and two other reference attributes S and C referencing classes Student and Course respectively.
add class Enroll... Type tuple ( . . . . semester: string, S: Student, C: Course);

(c) Non-Binary relationships. We do not distinguish between non-binary relationships with or without attributes, because they are mapped exactly the same way as binary relationship with attributes. The non-binary relationship is always mapped as a new class. The only difference is on the number of reference attributes, which varies with the number of entities involved. In the university database there are no non-binary relationships. However, to illustrate the point let's assume we have a relationship R involving entities A, B, and C. 0 2 Example: Mapping the non-binary relationship R. A new class R is created with three reference attributes al, b l and el referencing classes A, B and C respectively.
add class R . . . type tuple ( . . . . al : A, bl : B, c1: C);

4.3. Defining persistent classes

A persistent class contains objects that are persistent, i.e. they remain in the database after the end of the transaction which created them [14]. There are many ways that an object can become persistent [30]: (i) Object is connected to some persistent structure. (ii) Object is stored in persistent storage. (iii) Object is issued an explicit message to make itself persistent. (iv) Object is instantiated from a persistent class. We define which classes are going to be persistent based on which information needs to be stored, and which updates and queries should be supported on the database. However, this is not a trivial task. For instance, sometimes it is not clear in which level of the class hierarchy should be persistent. Since the UPM expressions define how the information is going to be accessed, our approach is to define persistent classes for each entity or relationship which appears in those expressions. We don't create persistent classes for relationships, which were not converted into classes. For example, we only define the following persistent classes for the UPM expression given in Section 3.2.2.1 Example i: Faculty-member, Employee, Assistant-Professor, and Instructor. In 0 2 , we can represent these persistent classes by defining extensions, described as follows:
add name EXTFACULTY: set(Faculty_member); add name EXTEMPOLYEE: set(Employee);

176

M.J.V. Silva, C.R. Carlson / Data & Knowledge Engineering 17 (1995) 159-181

add name EXTASSISTANT_PROFESSOR: set(Assistant_Professor); add name EXTINSTRUCTOR: set(Instructor);

4.4. Defining m e t h o d s

In MOODD, UPM expressions describe the behavior of the objects to which they apply. Our approach is to create a method for each UPM expression. Each method is attached to the class representing the entity or relationship to which the UPM expression refers. For instance, the following method is defined from the UPM expression given in Section 3.2.2.1 Example i to insert a new faculty:
add method insert( ): Faculty_member in class Faculty_member is public; /* insert a new faculty member */ body insert( ): Faculty_member in class Faculty_member CO2 { 0 2 Assistant_Professor ap; 0 2 Instructor instr; [self init@Employee] /* initialize fields of superclass */ self->degree = input (02 string); if (strcmp(degree, "Ph.D.") = = 0) { ap = new(Assistant_Professor); ap->name = self->name; ap->address = self->address; ap->salary = self->salary; [ap init]; /* initialize other fields */ EXTFACULTY + = set(ap); EXTASSISTANT_PROFESSOR + = set(ap);

}
else { instr = new(Instructor); instr->name = self->name; instr->address = self->address; instr->salary = self->salary; [instr init]; /* initialize other fields */ EXTFACULTY + = set(instr); EXTINSTRUCTOR + = set(instr);

}}$:

5. Summary
In this paper we outlined a consistent method for object-oriented design called M O O D D , which guides the development of applications from its natural language specification to its object-oriented data model definition. The advantage of our approach is that it starts with the natural language RSL for requirements specification, modeling both the static and dynamic behavior properties of complex objects. Further, it provides heuristics to translate the RSL requirements into an object-oriented conceptual schema composed of the NER and UPM

M.J.V. Silva, C.R. Carlson / Data & Knowledge Engineering 1"7 (1995) 159-181

177

models. This conceptual schema is independent of the terminology used in any database system, therefore it is easily mapped into existing database systems. Finally, we have shown how the NER diagrams and UPM expressions are implemented by an object-oriented data model. Examples to illustrate the method are given for a specific object-oriented data model called 02. Therefore, the systems resulting from the application of the MOODD method have the benefits of the object-oriented approach, specifically modularity, extensibility and reusability. In order to contribute to this research as well as to enhance the validity of our method, we must implement and integrate all the three phases of MOODD. To date, we have only automated portions of MOODD. A prototype for specifying requirements in RSL has been developed in Smalltalk. What remains to be done is the integration between the objectoriented modeling tool with RSL and an OODBS.

Acknowledgments
Thanks to Rosana S.G. Lanzelotte and to all referees for their insightful and helpful comments.

Appendix A. Requirement Specification Language (RSL)

A . 1. B N F definition o f R S L static rules
Static_l) Database Object/Major Object General Format: The (Database Name) model consists of (List of Entity Objects).

(Database Name)::= (Entity Object) (List of Entity Objects)::= (Entity Object) (, (Entity Object)} (Entity Object) ::= noun
e.g. The Aircombat model consists of Airbases, Aircraft types, Units and Supplies. Static_2) Entity Object/Attributes General Format: Each (Entity Object) is identified by (List of Key attributes) and is characterized by (List of attributes). (List of Key attributes)::= (Attribute name) {, (Attribute name)}

(List of Attributes) ::= [unique lcollection] (Attribute name), {, [unique lcollection] (Attribute name) } (Attribute name) ::= noun
e.g. Each Alrbaem is identified by a name and is characterized by its unique location, size and role. Static_3) Entity/Aggregation

178

M.J.V. Silva, C.R. Carlson / Data & Knowledge Engineering 17 (1995) 159-181

General Format: Each (Complex Entity Object~ consists of related (List of Entity objects). (Complex Entity Object) ::-- noun e.g. Each Department consists of related Faculty, Students and Courses. Static_4) Entity/Generalization General Fromat: Each (Complex Entity Object) can be [exclusively] either a (SubenUty) or a (Subentity~ or . . . . (Subentity~ ::= ~Entity Object) e.g. Each Employee can be either a Staff or a Faculty member. Static_5) Relationship/Attributes General Format (binary): Each (Entity Object) (Relationship Phrese~ (Cardinality Phreee~ (Entity Object) [ ( List of Attributes ~]. (Relationship Phrase ~ :: = verb Iverb-phrase (Cardinality Phrase~ ::= [one or more]l[at most one]l[zero or more]l[exactly one] e.g. Each Employee works on one or more Projects for a % of time. Each Project is worked on by one or more Employees. General Format (n-ary): Each (Relationahip-phraee~ involves [Who? (Cardinality Phrase~ (Entity-ObjectS] [What? (Cardinality Phraee~ (Entity-Object)] [From (Cardinality Phrase~ (Entity-Object)] [To ~Cardinality Phrase) (Entity-ObjectS] [How? (Cardinality Phrase) (Entity-Objeet)] [Why? (Cardinality Phrase~ (EnUty-Objeet~] [When? (Cardinality Phrase) (EnUty-Object)] [and is characterized by (List of Attributes~] e.g. Each Purchase involves Who? an Employee What? a Part From a supplier To a Department How? with a Purchase Order StaUc_6) Relationship/Generalization General Format: (List of Entity Objects) are involved in (Complex Relationship) relationship in several [exclusive] ways: (List of SubrelaUonships). (Complex Relationship) ::= noun (List of Subrelationships ~ :: = (Subrelationship) (, (Subrelationship ~} (Subrelationship) ::= (static_5) I (static_6~ I <~static_7)

M.J.V. Silva, C.R. Carlson / Data & Knowledge Engineenng 17 (1995) 159-181

179

e.g. Companies and Schools are involved in a support relationship in several ways: Companies donate equipment to Schools, Schools consult with Companies. Static_7) Relationship/Aggregation General Format: (List of Entity Objects) are involved in (Complex Relationship) relationship through the following subrelationships: (List of Subrelationships). e.g. Schools and Companies are involved in a consult relationship through the following subrelationships: Schoold have Departments, Companies have Divisions, Department consults with Divisions.

A . 2 . B N F definition o f R S L dynamic rules

Dynamic.I) Business Rules/Events with Triggers General Format: When (Event) (List of Implies). (Event) ::-- (Agent) (Action) (Object Receiver) (Agent) ::= (Entity Object) (Action) ::= (Relationship Phrase) (Object Receiver) ::= [(Entity Object) I (Relationship)] (List of Implies) ::= (Trigger) (land I or] (Trigger)} (Trigger) ::= [If (Conditional Phrase)] Implies that (Associated Event) [Otherwise (Associated Event)] (Associated Event)::= (Event) (Conditional Phrase) :: = sentence e.g. When a School hires a new Faculty member, if he has a Ph.D. degree implies that he would be assigned the rank of Assistant Professor otherwise he would be assigned the rank of Instructor. Dynamic_2) Business Rules/Events with Preconditions General Format: When (Event) subject to the following constraint(s): (List of Preconditions) (List of Preconditions)::= (Conditional Phrase), (, (Conditional Phrase)} e.g. When a Faculty member is assigned courses, he is subject to the following constraint: A Faculty member cannot teach more than two courses in a semester. Dynamic_3) Business Rules/Events with Postconditions General Format: When (Event) it must hold that: (List of Postconditions) (List of Postconditions)::= (Conditional Phrase) {, (Conditional Phrase)} e.g. When a Faculty member is promoted to Assistant-Professor, it must hold that: this Faculty member is an Assistant-Professor.

180

M.J.V. Silva, C.R. Carlson / Data & Knowledge Engineering 17 (1995) 159-181

References
[1] E. Andonoff et al., Interactive design of object oriented databases, 4th Int. Conf. CAiSA (May 1992). [2] M. Atkinson, F. Bancilhon, D. Dewitt, K. Dittrich, D. Maier and S. Zdonik, The object-oriented database system manifesto, in Proc. ACM SIGMOD Conf., Atlantic City (1990). [3] S.C. Bailin, An object-priented requirements specification method, Commun. ACM 32 (5) (May 1989) 608-623. [4] F. Bancilhon, Object-oriented database systems, Proc. 7th A CM Symp. on the Principles of Database Systems, Austin, TX (March 1988). [5] J. Banerjee et al., Data model issues for object-oriented applications, in Readings in Object-Oriented Database Systems, S.B. Zdonik and D. Maier (Morgan Kaufmann, San Mateo, CA, 1990) 197-208. [6] C. Batini, S. Ceri and S.B. Navathe, Conceptual Database Design an Entity-Relationship Approach (Benjamin Cummings, Redwood City, CA, 1992). [7] M. Bouzeghoub and E. Metais, Semantic modeling of object-oriented databases, Proc. 17th Int. Conf. on Very Large databases, Barcelona (Sept. 1991). [8] H. Briand and D. Ravelet, Transformation d'un schema Entite-Association en base de donnees orientee objet, Proc. EC2 Conference, Toulouse, France (Dec. 1990). [9] C.R. Carlson and A.K. Arora, UPM: A formal tool for expressing database update semantics, EntityRelationship approach to software engineering, Proc. Third Int. Conf. on Entity-Relationship (North Holland, NY, 1983) 517-526. [10] C.R. Carlson and W. Ji, The nested Entity-Relationship model, 8th Int. Conf. on Entity-Relationship Approach (Oct. 1989). [11] P.P. Chen, The Entity-Relationship Model - toward an unified view of data, ACM Trans. Database Syst. 1 (1) (Mar. 1976) 9-36. [12] P.P. Chen, English sentence structure and Entity-Relationship diagram, Informat. Sci. 29 (1983) 127-149. [13] G.P. Copeland and S. Khoshafian, Object identity, Proc. Object-oriented Programming Systems, Languages and Applications (ACM, 1986). [14] Deux et al., The story of 02, IEEE Trans. Knowledge an Data Eng. 2 (1) (Mar. 1990). [15] L. Haux, C. Lecluse and P. Richard, The CO2 V0.4 Language and Some Extensions, Release 3.1, Technical Report Altair 4-88, Oct. 1988. [16] R. Hogan, A Practical Guide to Database Design (Prentice Hall, Englewood Cliffs, 1990). [17] W. Ji, The nested Entity-Relationship model, Ph.D. Thesis, Illinois Institute of Technology, 1990. [18] W. Kim, Object-oriented database system strengths and weakness, J. Object-Oriented Programming 4 (4) (July 1991) 21-28. [19] C. Lecluse, P. Richard and F. Velez, 02, an Object-Oriented Data Model, Proc. ACM-SIGMOD Conf. on the Management of Data, Chicago, IL (June 1988). [20] D. Maier and J. Stein, Development and Implementation of an Object-oriented DBMS, in Readings in Object-Oriented Database Systems, S.B. Zdonik and D. Maier (Morgan Kaufmann, San Mateo, CA, 1990) 167-185. [21] W. Meng et al., Construction of a relational front-end for object-oriented database systems, Proc. IEEE 9th Int. Conf. on Data Engineering, Los Alamitos, CA (1993) 476-483. [22] D.E. Monarchi and G.I. Puhr, A research typology for object-oriented analysis and design, Commun. ACM, 35 (9) (Sept. 1992) 35-47. [23] G.M. Nijssen and T.A. Halpin, Conceptual Schema and Relational Database Design: a Fact Oriented Approach (Prentice Hall, New York, 1989). [24] O. Nierstrasz, A survey of object-oriented concepts, in Object-Oriented Concepts, Databases, and Applications, W. Kim and F. Lochovsky (ACM Press, 1989) 3-21. [25] J. Rumbaugh et al., Object-oriented Modeling and Design (Prentice Hall, Englewood Cliffs, 1991). [26] P. Rob and C. Coronel, Database Systems: Design, Implementation, and Management (Wadsworth, 1993). [27] M.J.V. Silva and C.R. Carlson, R S L - a formal English-like requirement Specification Language, Master Project, Illinois Institute of Technology, IL, May 1992.

M.J.V. Silva, C.R. Carlson / Data & Knowledge Engineering 17 (1995) 159-181

181

[28] J. Smith and D. Smith, Database abstractions: Aggregation and generalization, A C M Trans. Database Syst., 2 (2) (June 1977) 105-133. [29] I. Vessey and S.A. Conger, Requirements specification: Learning object, process, and data methodologies, Commun. ACM 37 (5) (May 1994). [30] S.B. Zdonik and D. Maier, Fundamentals of object-oriented databases, Readings in Object-Oriented Database Systems, S.B. Zdonik and D. Maier (Morgan Kaufmann, San Mateo, C A , 1990) 1-33.
Mauricio J.V. Silva received a B.S.

degree in computer engineering from the Pontifical Catholic University of Rio de Janeiro in 1991 and a M.S. degree in computer science from Illinois Institute of Technology in 1992. He received the Ph.D. in Computer Science from the Illinois Institute of Technology in 1995. His research interests include object-oriented modeling, object-oriented databases, and natural language interfaces to databases.

C. Robert Carlson received the Ph.D. from the University of Iowa in 1972. Currently, he is a professor and chairman of the Computer Science Department of the Illinois Institute of Technology. He is well known for his modeling research, design tools and design methodologies in the field of relational and object-oriented databases. His current research interests include object-oriented modeling, design and query languages.