OBJECT-ORIENTED CONCEPTUAL MODELING ... - CiteSeerX

Oscar Pastor, Emilio Insfrán, Gaspar Quiles, José Barberá

1

OBJECT-ORIENTED CONCEPTUAL MODELING TECHNIQUES TO DESIGN AND IMPLEMENT A SOUND AND ROBUST ORACLE ENVIRONMENT Oscar Pastor, Emilio Insfrán, Gaspar Quiles, José Barberá Departament de Sistemes Informàtics i Computació Universitat Politècnica de València Camí de Vera s/n 46071 Valencia (Spain) {opastoreinsfran}@dsic.upv.es Abstract The paper will introduce the advantages of using the Object-Oriented Model for conceptual modeling, as a kind of knowledge model to capture information system properties. Next, the paper will explain how to properly implement such a system description in an advanced ORACLE environment, using ORACLE v7 as server and Developer/2000 as execution model tool. The main contribution is the definition of a precise mapping between OO notions at the conceptual model level, and ORACLE structures for implementation at the programming level. This allows us to connect OO modeling with a sound and functionally equivalent relational implementation in Oracle.

1. Introduction The use of the object notion in Software Production Environments is becoming more and more extended. We have OO Databases, Analysis and Design Methods, Programming Languages, etc. In our case, we are interested in the use of an OO model to deal with the Conceptual Modeling step, where the interaction between users and analysts is expected to produce a model including all the relevant system properties. We cannot forget that our main objective is to produce a sound and robust final software product. This is why we are specially interested in connecting the good properties (from our point of view) attached to an OO Analysis with a powerful and reliable software development environment. When referring to such a software development environment, in our case, we mean ORACLE v7 with Developer/2000 basically, because we have a pool of designers who have experience with it, and who are at the moment reasonably satisfied with the results. The basis of our experience is to be able to properly implement objects in a ORACLE relational context. To do so, we follow a methodological approach that has two main steps: 1. A conceptual Modeling step, where after interaction with clients (users) an set of graphical models are built following an OO methodological approach called OO-METHOD [Pas96] [Pas97]. The main features of this methodology are the following: After having obtained the analysis models (object, dynamic and functional) which characterize what we call the conceptual model, a corresponding OO formal specification constitutes a highlevel data dictionary that is generated in an automated way. 2. A precise execution model determines the details that have to be taken into account to properly implement the quoted conceptual model. In this paper, we will present this conversion for ORACLE development environments, clearly specifying how to map the OO notions collected in the OO-METHOD analysis models in the structures attached to a well-defined ORACLE relational environment. This is the basic document used by designers to generate the final software product. This translation process has the following principal phases: • the generation of CREATE TABLE statements, which include attributes and integrity constraints • the generation of the Data Base PROCEDURES, PACKAGES and TRIGGERS attached to the OO specification.

Oscar Pastor, Emilio Insfrán, Gaspar Quiles, José Barberá

2

• the forms needed to implement the user interface. • the definition of the ORACLE v7 roles and users, and the privileges granted to set the final protection model. Throughout the paper, we will try to show that this approach takes advantage of both the use of an OO paradigm in order to have a clear system model and the power of a well-known relational environment. We will also show that this connection is easy enough to be used by any Oracle Development team. Furthermore, it is important to remark that this work is the continuation of a R&D project tackled by the Technical University of Valencia and the Health Dept. of the Local Government of Valencia, whose first results were presented in [Pas95-2].

2. OO-Method: the methodology OO-Method is an OO methodology for software production that offers a rigorous framework for specifying information systems including: • an easy-to-use graphic notation for dealing with the analysis phase • OASIS [Can95] [Pas95-1] as an OO formal specification language that constitutes a highlevel system repository covering the design phase. • a definition of a precise execution model to guide the implementation phase. In short, when facing the conceptual modeling step of a given Information System, we have to determine the object society components without being worried about any implementation consideration. The problem at this level is to obtain a precise system definition. Then, a well defined execution model will determine all the characteristics of the final software prototype in terms of access control, service activation, user interface, etc. In short, it will determine all the implementationdependent properties. We will use the Job class of a Personnel Information System as a simple example to introduce the methodology. From the static point of view, a job is identified with a unique number, has a description and a speciality, is assigned to a Centre and to an Economic Program, and is in a situation (empty, engaged, etc.). From the dynamic point of view, we have create and destroy events, and an engage event to relate a person to a job. A job can be marked when some modification is to be done in it. It cannot be engaged by any person until an unmark event occurs. Every mark has a marking code attached to it. We will give more details as needed.

2.1. Conceptual Model We start with the analysis step where three models are generated: the Object Model, the Dynamic Model and the Functional Model. These three models describe the object society from three orthogonal, but complementary, points of view within a well-defined OO framework.

2.1.1. Object Model The Object Model is described graphically by a Class Configuration Diagram (CCD). It is an Extended Semantic Model showing the structure and behaviour of all the classes identified in the problem domain and their relationships. The class graphical representation is a box with three areas (see Figure 1): • Header: the class name declaration. • Static section: definition of the attributes that represent the state of the object. Attributes used for identifying objects in a class are underlined. Other (non graphical) important attribute informations are: its data type and its property (constant, variable or derived).

Oscar Pastor, Emilio Insfrán, Gaspar Quiles, José Barberá

3

• Dynamic section: declaration of the services1 of the class. Each one includes information about its arguments and distinguishes among new and destroy events, and among private and shared events2. JOB job_number description ... create_job delete_job update_job engage ...

Figure 1. A class graphical representation. Actions are services requested by an object that can consult or modify another object´s state when acting as agent. In Figure 2, an instance of a class ADMIN can create or destroy a JOB and there is a shared event engage between a PERSON and a JOB. PERSON

ADMIN

JOB

dni_number

job_number description ...

name ... create_person

rank ... create_admin

create_job delete_job update_job engage ...

delete_person engage ...

delete_admin ...

Figure 2. A shared event (engage) and an agent relationship. For dealing with complexity, we can define hierarchical structure relationships modeled in terms of aggregation (part-of) and inheritance (is-a). We represent the aggregation relationship between two classes including its cardinality (minimum and maximum) to determine how many components can be attached to a given container and how many containers a component class can be associated with. The graphic representation is shown in Figure 3. CENTRES centre_number address ... create_centre delete_centre ...

1:1

0:M

JOB

0:M

1:1

SPECIALITIES

job_number description ...

spe_num description ...

create_job delete_job update_job engage ...

create_spe delete_spe ...

Figure 3. Aggregation relationship. Additionally, an aggregation can be labeled as inclusive/referential and static/dynamic. A detailed explanation of these features can be found in [Pas95-1]. An association is a special case of aggregation for dealing with collections of objects using a GROUP BY clause. A relevant property of association is the existence of implicit insertion and deletion events. As an example, in Figure 4, given an aggregation relationship between Job and Speciality, we can group Jobs by Specialities. 1

Services: a class viewed from a server perspective offers to the object society events (atomic units of processing that occurs in an instant of time). The class also offers to the object society transactions (mollecular units of processing composed of services that have the properties of: non-observability of intermediates states and the all-or-nothing policy during execution). 2 Shared event: event whose occurrence affects the state of two or more classes at the same instant in time.

Oscar Pastor, Emilio Insfrán, Gaspar Quiles, José Barberá

JobBySpe

group by specialities

quantity ... ...

JOB

4

0:M

1:1

SPECIALITIES

job_number description ...

spe_num description ...

create_job delete_job update_job engage ...

create_spe delete_spe ...

Figure 4. Association relationship. Inheritance is graphically depicted as an arrow from a given subclass to its superclass. This arrow can be labeled with a condition of specialization, or with the events that activate/cancel the child role, respectively. The graphical representation is introduced in Figure 5. Base Class

PERSON new / destroy

condition

kind=“adm” Specialized Class

Specialized Class

ADMIN

Figure 5. Inheritance relationship, a general case and an example. Finally, a class is completely defined by a set of formulae of different kinds to cover the rest of the properties: • integrity constraints (static and dynamic) to state conditions that objects must satisfy. • derivations, that define derived attributes in function of others which already exist.

2.1.2. Dynamic Model The Dynamic Model represents the aspects related to the object control, possible lives, sequences of event occurrences and interaction between objects. This model is made up of two kind of diagrams: State Transition Diagrams (STD) and an Object Interaction Diagram (OID).

State Transition Diagrams STDs are used to describe correct behaviour by establishing valid object lives. By valid life, we mean a correct sequence of states that characterizes the correct behaviour of the objects for every class. In this context, states denote the different available situations for class objects, and are depicted using a circle labeled with the state name. Transitions represent valid changes of state that can be constrained by introducing conditions. They follow the syntax shown below: event | action | transaction [if precondition] [when control-condition ] where precondition and control-condition are conditions defined on the object attributes that must hold for a service to occur in the precondition, and to avoid the possible non-determinism for a given action in control condition. An example of a STD can be seen in Figure 6.

Oscar Pastor, Emilio Insfrán, Gaspar Quiles, José Barberá

Adm:engage if situation = 0

5

Adm:update_job Adm:unmark if update_control 0

JOB1 Adm:create_job

JOB2 Adm: mark if update_control = 0

Adm:delete_job

Figure 6. State Transition Diagram for Job class

Object Interaction Diagram To deal with object interaction, we introduce an Object Interaction Diagram (OID, one for the whole System). We declare two basic interactions: • triggers, which are services of a given class which are activated in an automated way when a condition is satisfied by an object of the same or of a different class. • global interactions, which are transactions involving services of different classes. Basically, we represent classes in the OID as boxes with a header including the class name. Class services are declared as smaller boxes inside the corresponding class box. The class service boxes are connected when one of the previous types of interactions is defined. Triggers are introduced by starting the corresponding solid line in the header of the class and ending it in the triggered action, and global interactions are introduced by connecting the involved services with a common global interaction identifier (GIid). The general model for an OID can be seen in Figure 7. self::(condition)

Class1

event1

GI id

Class3

event4 event3

Class2

event2

GI id

Figure 7. Object Interaction Diagram with a Global Interaction and a Trigger.

2.1.3. Functional Model The aim of the Functional Model is to capture semantics attached to any change of state in an easy and intuitive way. This model specifies the effect of an event on its relevant attributes through an interactive dialogue. The value of every attribute is modified depending on the action that has been activated, the involved event arguments and the current object state. The specification of an action effect should be made declaratively, as proposed in Oasis. OO-Method provides a model where the Analyst only has to categorize every attribute among a predefined set of three categories and introduce the relevant information depending on the corresponding selected category. The three categories of attributes are: push-pop, state-independent and discrete-domain valued.

Oscar Pastor, Emilio Insfrán, Gaspar Quiles, José Barberá

6

• Push-pop attributes are those whose relevant events increase or decrease their value by a given quantity. Events that reset the attribute to a given value can also exist. An example of this category is num_marks of the Job class, with Adm:mark as an increasing action. Class: Job

Attribute : num_marks

Action Type Incr.

Action Adm:mark

Effect +1

Category : push-pop Evaluation Condition

Figure 8. Push-pop attribute. • State-independent attributes have a value that depends only on the latest action that has occurred. Once a relevant action is activated, the new attribute value of the object involved is independent of the previous one. In such a case, we consider that the attribute remains in a given state, having a certain value for the corresponding attribute. Class: Job

Attribute : update_control

Carrier Action Adm: mark

Action Effect = uc

Category : state-independent Evaluation Condition

Figure 9. State-independent attribute •

Discrete-domain valued attributes take their values from a limited domain. The different values of this domain model the valid situations that are possible for objects of the class. Through the activation of carrier actions (that assign a given domain value to the attribute) the object reaches a specific situation. The object abandons this situation when another event occurs (a “liberator” event). As an example, let’s consider the situation attribute of the Job class. The situation value tells us what the current Job situation is. The carrier event: engage lets the object into a situation where situation has the value engaged. Class: Job

Attribute : situation

Actual Value empty

Action Adm:engage

New Value engaged

Category : discrete-domain valued Evaluation Condition

Figure 10. Discrete-valued attribute. All this information, which constitutes the system description, has a textual representation in OASIS, the formal OO specification language which has been developed in our department. The specification is obtained at any moment by executing an automated process of translation that converts the collected graphic information into a textual OO specification [Pas96]. This OASIS specification constitutes a complete, formal System Repository.

2.2. Execution Model The execution model is a generic pattern applicable to any conceptual model built following the strategy of OO-Method. It is a scheme to be followed by any developer (or CASETool) whose aims is to implement the properties detailed in the conceptual model. Any objects can act as a client (requesting services from other objects) or as a server (responding to messages that arrive to their interface). Once all the relevant system information in the specification that we have called conceptual model is collected , the execution model has to accurately state the implementation-dependent features associated to the selected object society machine representation. More precisely, we have to explain the pattern to be used in implementing object properties in any target software development environment. Our idea at this point is to give an abstract view of an execution model that will determin the programming pattern to follow when dealing with the problem of implementing the conceptual model contents. This execution model has three main steps: 1. access control: first, as users are also objects, the object logging in the system has to be identified as a member of the corresponding object society.

Oscar Pastor, Emilio Insfrán, Gaspar Quiles, José Barberá

7

2. object system view: once the user is connected, he must have a clear representation of which classes he can access. In other words, the user´s object society view must be clearly stated, specifying the set of object attributes and services that the user will be allowed to see or activate, respectively. 3. service activation: finally, after being connected and having a clear object system view, the object will be able to activate any available service in the user’s world view. Among these services, we will have event or transaction activation served by other objects, or system observations (object queries). Any service execution is characterized by the following sequence of actions: 1. object identification: as a first step, the object acting as server has to be identified. The existence of this object is an implicit condition for executing any service, except if we are dealing with a new3 event. At this instant, their values (those that characterize the object´s current state) are retrieved. 2. introduction of event arguments: the rest of the arguments of the event being activated must be introduced. 3. state transition correctness: we have to verify in the STD that a valid state transition exists for the selected service in the current object state. 4. precondition satisfaction: the precondition associated to the service that is going to be executed must hold. If not, an exception will arise, informing that the service cannot be activated because its precondition has been violated. 5. valuation fulfillment: once the precondition has been verified, the induced modifications are effective in the selected persistent object system.

event

6. integrity constraint checking in the new state: to assure that the service activation leads the object to a valid state, we must verify that the (static and dynamic) integrity constraints hold in this final resulting state. 7. trigger relationships test: after a valid change of state, and as a final action, the set of rules condition-action that represents the internal system activity has to be verified. If any of them holds, the corresponding service activation will be triggered. It is the analyst’s responsibility to assure the termination and confluence of such triggers. The previous steps guide the implementation of any program to assure the functional equivalence among the object system description collected in the conceptual model and its reification in a software programming environment according to the execution model.

3. Implementation in ORACLE In this section, we are going to define a concrete implementation of the execution model introduced above. In particular, we will present the set of rules needed to implement the OO conceptual model built with OO-Method in an ORACLE-7 environment, in a simple way. In short, every class generates an Oracle table, having as primary key attributes those underlined in the class graphical specification. Every constant or variable attribute will be implemented as columns of the table. Additionally, every class will generate a user and a squema. Classes denoting active objects will also generate additionally a role. This role will include all the privileges granted to the users (role members). For every class we will also have a set of forms wich will be used to implement the class transactions as we will see below. We can divide this translation process into two main phases, in which we will generate: • The relational logic model 3

Formally, a new event is a service of a metaobject representing the class, which acts as an object factory for creating individual class instances. This metaobject (one for every class) has the class population attribute, the next oid and the quoted new event as main properties.

Oscar Pastor, Emilio Insfrán, Gaspar Quiles, José Barberá

8

• The packages, procedures, functions, triggers and forms needed to introduce the dynamic into our system.

3.1. DATA MODEL To obtain the Relational Logic Model, we will focus on two sections of the class specification: • Attribute definition • Static Integrity restrictions. Every class is represented as a table inside its own squema. The columns of this table are every constant or variable attribute. Derived attributes are represented as a table column or as a function depending on the designer´s choice. If they are viewed as virtual attributes, the function to obtain their value has to be defined in the package that, as we will see, contains the set of object services. We can also choose to store it. In this case, they will be defined in the same way as the others being necessary to declare triggers to maintain this field (for instance, pre-insert and pre-update triggers attached to the table). The identifier attributes underlined during the class specification are represented as the column(s) that constitute(s) the primary key of the table. As expected, every instance of the class is a row in the table. Constant attributes are not null attributes by definition. Variable attributes will be defined as not null if they must be introduced as a new event argument or if they have been declared with a corresponding default value. All this information is introduced at the conceptual level during the class definition. Static Integrity restrictions are represented as table constraints that validate the conditions stated in the specification on the class atributes. In our example, we have the following CREATE TABLE statement for jobs: CREATE TABLE JOBS (job_number number(6) CONSTRAINT pk_job PRIMARY KEY CONSTRAINT ck_job CHECK(job_number