Modelado Orientado a Objetos

Vista previa del material en texto

Modelado Orientado a Objetos Aplicado a 
Entornos de Desarrollo Relacionales 
Oscar Pastor, Emilio Insfrán, Vicente Pelechano 
Departament de Sistemes Informàtics i Computació 
Universitat Politècnica de València 
Camí de Vera, S/N, 46071 València 
tlf: 34 + 6 3877350 fax. 34 + 6 3877357; 
e-mail: {opastor,einsfran,pele}@dsic.upv.es 
 
Resumen 
En este trabajo se presentan las ventajas del uso del Modelo Orientado a Objetos para el modelado 
conceptual y la implementación de sistemas de información. La mayoría de las metodologías actuales [Rum91], 
[Boo94], [BRJ96] carecen de guías precisas y rigurosas (desde el punto de vista del proceso de especificación) 
que nos permitan obtener productos finales a partir de los modelos conceptuales construidos. Nuestro trabajo 
intenta cubrir dichas carencias proporcionando un enfoque metodológico (OO-Method [Pas96], [Pas97]) que 
abarca la construcción de modelos de análisis y la definición de un patrón de traducción preciso de estos 
modelos a esquemas de bases de datos relacionales avanzados. Este artículo presenta un proceso de traducción 
fácil y preciso a la vez, que nos va a permitir implementar los modelos conceptuales de OO-Method sobre un 
entorno de desarrollo relacional (usando ORACLE v7 como servidor de datos y Developer/2000 como 
herramienta de desarrollo), explicando cómo trasladar los aspectos estáticos y dinámicos recogidos durante la 
fase de análisis, a estructuras relacionales y código para constituir el producto software final. 
 
1. Introducción 
Muchas de las aplicaciones que se desarrollan actualmente utilizan técnicas de Análisis OO para obtener el 
modelo conceptual del sistema y entornos de desarrollo visuales con bases de datos relacionales para su 
implementación. En este tipo de aplicaciones, el modelo conceptual OO obtenido en la fase de análisis se traduce 
básicamente en un esquema relacional específico de la base de datos subyacente sin incluir la dinámica de la 
aplicación. 
Nuestro trabajo se centra en el Modelado Conceptual OO y en la generación automática de código a partir de 
los modelos obtenidos, incluyendo estática y dinámica, siguiendo el paradigma de la programación automática 
[Bal83]. Uno de los objetivos más interesantes es producir aplicaciones de calidad a partir de los modelos de 
análisis, utilizando la tecnología ofrecida por los entornos de bases de datos relacionales. Para conseguirlo, 
hemos desarrollado OO-Method [Pas96] [Pas97] un enfoque metodológico que proporciona entre otras 
características una estrategia de traducción bien definida que permite implementar los modelos conceptuales en 
entornos relacionales avanzados. Dicha estrategia utiliza las características (procedimientos almacenados, 
paquetes y disparos) que aportan estos nuevos entornos, y proporciona un patrón a utilizar por los diseñadores 
para generar el producto software final. 
Para mostrar esta estrategia hemos usado Oracle v7 como servidor principal y Developer/2000 como 
herramienta de desarrollo, aunque el enfoque puede ponerse en práctica en cualquier otro entorno de similares 
características. 
La propuesta metodológica OO-Method tiene dos fases principales: 
1. Modelado conceptual: se recogen las propiedades esenciales que definen el sistema. Las principales 
características de esta fase son las siguientes: 
• Se obtienen tres modelos de análisis: modelo de objetos, dinámico y funcional. 
• Se obtiene una especificación formal y orientada a Objetos en OASIS [Pas92] [Pas95-1] que 
constituye un diccionario de datos de alto nivel y que se genera automáticamente a partir de los 
modelos de análisis. 
2. Modelo de Ejecución: establece los detalles a considerar para implementar adecuadamente el Modelo 
Conceptual obtenido. Especifica claramente cómo trasladar cada una de las nociones recogidas en los 
modelos de análisis a estructuras asociadas a un entorno relacional avanzado, en este caso Oracle. Este 
Modelo de Ejecución se utilizará para generar el producto software final. 
Este proceso de traducción sigue estos pasos: 
• generación de las sentencias CREATE TABLE correspondientes, que incluyen atributos y 
restricciones de integridad 
• generación de los procedimientos, paquetes y disparos de la BD (PROCEDURES, PACKAGES y 
TRIGGERS) correspondientes a la especificación OO. 
• generación de las ventanas necesarias (FORMS) para implementar la interfaz de usuario. 
• definición de roles, usuarios y privilegios otorgados para establecer el modelo final de protección. 
El trabajo que presentamos está estructurado como sigue a continuación. En el siguiente punto introducimos 
brevemente la metodología OO-Method mediante un ejemplo práctico que nos va a permitir exponer en el tercer 
punto cómo se implementa dicho ejemplo en Oracle, mostrando que la conexión entre los modelos de análisis y 
la implementación es lo suficientemente fácil como para ser usada por un grupo de desarrollo de aplicaciones 
Oracle. Este trabajo es la continuación de un proyecto de I+D entre la Universidad Politécnica de Valencia y la 
Conselleria de Sanidad y Consumo de la Generalitat Valenciana y cuyos primeros trabajos se han presentado en 
[Pas94] [Pas95-2]. 
2. La metodología: OO-Method 
OO-Method es una metodología OO de producción de software que ofrece un marco riguroso para la 
especificación de sistemas de información. OO-Method incluye: 
• una notación gráfica para abordar la fase de análisis. 
• Oasis como un lenguaje de especificación formal y OO que constituye el repositorio de alto nivel del 
sistema. 
• la definición de un modelo de ejecución preciso que guía la fase de implementación. 
En la fase de modelado conceptual determinaremos los componentes de la sociedad de objetos sin considerar 
ningún detalle de implementación. El problema a este nivel consiste en obtener una definición precisa del 
sistema a desarrollar. A continuación, el modelo de ejecución determinará las características del producto 
software final en términos del control de acceso a usuarios, activación de servicios, interfaz de usuarios, … es 
decir, todas aquellas propiedades dependientes de la implementación que no forman parte directa del espacio del 
problema. 
Para ilustrar los conceptos que aparecen en el trabajo vamos a hacer referencia a un Sistema de 
Administración de Personal. Observando el problema desde el punto de vista estático, los ejemplares de una 
clase Trabajo se identificarán con un único número, tendrán una descripción y una especialidad. Un trabajo 
particular podrá asignarse a un Centro y a un Programa Económico y estar en una situación (libre, contratado). 
Desde la perspectiva dinámica, tendremos eventos que crean ejemplares, eventos que los destruyen y otros 
eventos como contratar que relaciona un trabajo con una persona. Un trabajo se marca cuando se realiza una 
operación sobre él y no puede ser contratado hasta que un evento desmarcar ocurra. Más adelante iremos dando 
detalles del problema según sean necesarios. 
2.1. Modelo Conceptual 
En la fase de análisis se construyen tres modelos del sistema: Modelo de Objetos, Dinámico y Funcional. 
Estos tres modelos describen la sociedad de objetos desde tres puntos de vista ortogonales pero 
complementarios. 
2.1.1. Modelo de Objetos 
El Modelo de Objetos utiliza un Diagrama de Configuración de Clases (DCC) para definir y mostrar la 
estructura y comportamiento de todas las clases identificadas en el dominio del problema, así como sus 
relaciones. El DCC es un modelo semántico extendido. 
Una clase se representa gráficamente como una caja dividida en tres áreas: 
• Cabecera: contiene la declaración del nombre de la clase. 
• Parte Estática: contiene la definición de los atributos que representan el estado de los objetos de la 
clase. Los atributos podrán ser constantes, variables y derivados. Aquellos atributos utilizados para 
identificar objetos se subrayan. 
• Parte Dinámica: contiene la declaración de los servicios1 de la clase. Cada serviciose declara 
especificando su nombre y argumentos (con sus tipos respectivos). Se distinguirá (gráficamente) entre 
los eventos de creación, borrado y los eventos compartidos con otras clases2. 
Las acciones son servicios que un objeto 
puede activar (actuando como agente) para 
consultar o modificar el estado de otro objeto. En 
la Figura 1, un objeto de la clase ADMIN puede 
crear o destruir un objeto de la clase TRABAJO, 
también se puede observar que el evento 
contratar es un evento compartido entre 
PERSONA y TRABAJO. 
Las relaciones estructurales que podemos 
modelar son la agregación (parte-de) y la herencia 
(es-un). En la Figura 2 se presenta la relación de 
agregación entre clases, incluyendo información 
sobre cardinalidades (mínimas y máximas) que 
determinan cuántos objetos componentes forman 
parte de un objeto compuesto e inversamente, 
cuántos objetos compuestos pueden estar 
compuestos de un objeto en particular. 
La herencia se define gráficamente trazando una flecha 
desde la subclase hacia la superclase correspondiente. Esta 
flecha de especialización puede etiquetarse con una 
condición de especialización o con los eventos 
correspondientes de activación/cancelación de la 
especialización temporal (rol). Ver Figura 3. 
En el modelo de objetos, una clase estará completamente 
definida por un conjunto de fórmulas que cubren el resto de 
propiedades, como son las: 
• restricciones de integridad: establecen condiciones que el estado de los objetos debe satisfacer siempre 
(estáticas) o durante un determinado período de su existencia (dinámicas). 
• Derivaciones: sirven para calcular el valor de los atributos derivados. Dicho valor se determinará en 
función de otros que ya fueron definidos. 
2.1.2. Modelo Dinámico 
En el Modelo Dinámico se representan aspectos relacionados con las secuencias posibles de eventos (vidas 
posibles) y la interacción entre objetos. Para representar estos aspectos, tenemos dos tipos de diagramas: El 
Diagrama de Transición entre Estados (DTE), uno por clase, y el Diagrama de Interacción entre Objetos (DIO), 
uno por aplicación. 
Diagramas de Transición entre Estados 
Los DTE se utilizan para describir el comportamiento de los objetos estableciendo las sus vidas posibles. Una 
vida válida de un objeto, es una secuencia de eventos que caracteriza un comportamiento correcto para todos los 
objetos de la clase. 
En este contexto, los estados del DTE denotan situaciones3 en las que pueden encontrarse los objetos durante 
su existencia como consecuencia de la ocurrencia de eventos relevantes. Las transiciones representan cambios de 
 
1 Servicios: Cuando hablemos de servicios de una clase nos referiremos a los servicios de los objetos de una clase, exceptuando el evento de 
creación que es de la clase. Además utilizamos el término servicio porque un objeto visto desde una perspectiva servidor ofrece a la sociedad 
de objetos eventos (unidades de proceso atómicas que ocurren en un instante de tiempo), transacciones (unidades de proceso moleculares 
compuestas de servicios que poseen las propiedades de no observabilidad de estados intermedio y la política de todo-o-nada durante su 
ejecución). 
2 Eventos compartidos: eventos cuya ocurrencia afecta al estado de dos o más objetos de clases distintas en el mismo instante de tiempo. 
3 Situación: conjunto de estados (valores de los atributos del objeto en un momento dado) a los que llegamos o que abandonamos mediante 
la ocurrencia de eventos, acciones o transacciones locales. 
 
 
Figura 1. Un evento compartido y una relación de agente. 
 
Figura 2. Relación de agregación. 
Figura 3. Relación de herencia. Un caso general y un 
ejemplo. 
estado permitidos que pueden restringirse introduciendo condiciones. La especificación de una transición posee 
la sintaxis siguiente: 
evento | acción | transacción [if precondición] [when condición-de-control ] 
donde precondición es una condición definida sobre atributos del objeto que debe satisfacerse en el estado de 
partida para que el servicio pueda 
ocurrir. Una condición-de-control es 
una condición que sirve para evitar el 
posible no-determinismo entre dos o 
más transiciones que partiendo del 
mismo estado van a estados 
diferentes, estando etiquetadas con la 
misma acción. En la Figura 4 se 
puede ver un ejemplo de DTE. 
Diagrama de Interacción entre 
Objetos 
La interacción entre objetos se 
modela gráficamente mediante un 
Diagrama de Interacción entre Objetos (DIO). En el DIO podemos especificar dos interacciones básicas: 
• disparos: son servicios de una clase que se activan de forma automática cuando se satisface una 
condición en un objeto dicha clase. 
• interacciones globales: son transacciones compuestas por servicios de clases diferentes. 
En el DIO representamos las clases como cajas con una cabecera en la que se incluye el nombre de la clase. 
Los servicios de los objetos de la clase se 
representan mediante pequeñas cajas 
rectangulares dentro de la clase. Las cajas de 
los servicios se conectarán para definir los 
anteriores tipos de interacción. Los disparos se 
definirán dibujando una flecha que vaya de la 
cabecera de una clase a la acción disparada y 
etiquetada con la condición de disparo. Las 
interacciones globales se introducen 
conectando los servicios que componen la 
interacción y nominándola mediante un 
identificador de interacción global común 
(idIG). En la Figura 5, puede ver un modelo 
general de DIO. 
2.1.3 Modelo Funcional 
El propósito del Modelo Funcional es capturar la semántica asociada a los cambios de estado de forma fácil e 
intuitiva. En este modelo especificaremos mediante un diálogo interactivo el efecto de un evento sobre los 
atributos. El valor de cada atributo se modificará dependiendo de la acción ocurrida, de los argumentos del 
evento y del estado actual del objeto. 
OO-Method proporciona un modelo mediante el cual el analista sólo tiene que categorizar cada atributo de 
entre un conjunto predefinido de tres categorías no disjuntas. Estas categorías determinan qué información se 
necesita para determinar cómo cambia el valor del atributo ante la ocurrencia de determinados eventos. Las tres 
categorías de atributos son: cardinales, independientes del estado y enumerados. 
• Cardinales: sus eventos relevantes incrementan o decrementan su valor en una determinada cantidad. En 
la Figura 6 podemos ver el atributo cardinal numero_marcas de la clase Trabajo, con Adm:marcar como 
acción incrementadora. 
Clase: Trabajo Atributo : numero_marcas Categoría : cardinal 
Tipo de 
acción 
Acción Efecto Condición de 
Evaluación 
Incr. Adm:marcar +1 - 
 Figura 6. Atributo cardinal numero_marcas. 
Adm:crear_trabajo
TRA
Adm: marcar if control = 0
Adm:desmarcar if control <> 0
TRA
Adm:contratar if situacion = 0
Adm:borrar_trabajo
Adm:actualizar
 
 
Figura 4. Diagrama de Transición de Estados para la clase TRABAJO. 
Clase1
evento1
idIG
Clase2
evento2
Clase3
evento3
idIG
evento4
self::(condicion)
 
Figura 5. Diagrama de Interacción entre Objetos General. 
• Independientes del estado: tienen un valor que sólo depende de la última acción ocurrida. Una vez ha 
ocurrido una acción relevante el nuevo valor del atributo es independiente del valor que tenía antes. En la 
Figura 7 podemos ver el atributo independiente del estado control de la clase Trabajo, con Adm:marcar 
como acción portadora. 
Clase: Trabajo Atributo : control Categoría: indep.estado 
Acción Efecto Acción Condición de 
Evaluación 
Adm: marcar = uc 
 Figura 7. Atributo independiente del estado control 
• Enumerados: Mediante la activación de una acción portadora se le asigna al atributo un valor de un 
dominio discreto.Vamos a considerar como ejemplo el atributo situación de la clase Trabajo. El valor de 
situación indica cual es la situaciónactual de un objeto de la clase trabajo (libre, contratado...). El evento 
portador contratar deja al objeto en el estado en el cual el atributo situación tiene el valor contratado. Ver 
Figura 8. 
Clase: Trabajo Atributo : situación Categoría: enumerado 
Valor 
Actual 
Acción 
Portadora 
Nuevo valor Condición de 
Evaluación 
libre Adm:contratar contratado 
Figura 8. Atributo enumerado situación. 
La información que se obtiene al finalizar la construcción de los tres modelos constituye la especificación del 
sistema, y posee una representación textual en OASIS un lenguaje de especificación formal OO desarrollado en 
nuestro departamento. La especificación textual OASIS constituye un repositorio completo y formal del sistema, 
y además se puede obtener en cualquier momento ya que existen traductores que permiten obtenerla a partir de la 
información gráfica. 
2.2. El Modelo de Ejecución 
El modelo de ejecución es un patrón genérico de comportamiento, aplicable a cualquier modelo conceptual 
construido siguiendo la estrategia propuesta por OO-Method. Una vez recogida en la especificación toda la 
información relevante del sistema, el modelo de ejecución explicará cómo se ejecuta/prototipa la sociedad de 
objetos en cualquier entorno de desarrollo. La idea consiste en dar una visión abstracta de un modelo de 
ejecución que determinará directamente el patrón de programación a seguir cuando un desarrollador (o una 
herramienta CASE) tenga que implementar un modelo conceptual. El modelo de ejecución tiene tres fases 
esenciales: 
1. Control de acceso: en primer lugar, el objeto4 que desee conectarse al sistema deberá identificarse 
como miembro de la sociedad de objetos. 
2. Vista del sistema: una vez se ha conectado un usuario (u otro objeto del sistema), éste tendrá una 
visión clara de la sociedad de objetos (qué clases de objetos puede ver, servicios que puede activar y 
atributos que puede consultar). 
3. Activación de servicios: por último después de las fases anteriores, el objeto deberá ser capaz de 
activar cualquier servicio disponible en su visión del mundo, y de realizar las observaciones 
pertinentes. 
Cualquier petición de servicio se caracterizará por la siguiente secuencia de acciones: 
1. Identificación del objeto: en primer lugar, se identificará el objeto que ha de servir la petición. La 
existencia de este objeto es una condición implícita para poder ejecutar el servicio, excepto si se 
trata del evento de creación5. Si el objeto existe se recuperarán los valores de los atributos que 
caracterizan su estado. 
 
4 En nuestra visión de las aplicaciones los usuarios son también objetos. Lo que nos da una gran potencia a la hora de prototipar porque 
podemos introducirnos en el sistema como cualquier objeto y observar que visión de la sociedad tendría 
5 Formalmente, el evento de creación es un servicio de un metaobjeto que representa a la clase, y que actúa como fábrica de objetos capaz de 
crear ejemplares individuales pertenecientes a la clase. Este metaobjeto (uno por cada clase) tiene como propiedades destacables el atributo 
población de la clase, el atributo siguiente oid y el evento de creación. 
2. Introducción de los argumentos del evento: se introducen el resto de argumentos del evento a 
activar. 
3. Corrección de la transición entre estados: verificaremos en el estado actual y para el servicio en 
cuestión que existe en el proceso una transición entre estados válida. 
4. Satisfacción de precondiciones: Comprobaremos que se cumple la precondición asociada al 
servicio que va a ejecutarse. Si no se cumple se elevará una excepción informando que el servicio no 
puede activarse porque se ha violado su precondición. 
5. Realización de las evaluaciones: una vez verificada la precondición, se hacen efectivas en el 
sistema de almacenamiento las modificaciones en el estado del objeto inducidas por el evento. 
6. Comprobación de las restricciones de integridad en el nuevo estado: para asegurar que la 
activación del servicio deja al objeto en un estado válido, se debe comprobar que las restricciones de 
integridad (estáticas y dinámicas) se cumplen en el estado final resultante. 
7. Comprobación de las relaciones de disparo: después de un cambio de estado válido, y como acción 
final, se deben verificar el conjunto de reglas condición-acción que representan la actividad interna 
del sistema. Si alguna de ellas se cumple, se disparará la correspondiente activación de servicio. Será 
responsabilidad del analista garantizar la terminación y confluencia de los disparos. 
Los pasos anteriores guiarán la implementación de cualquier aplicación para asegurar la equivalencia 
funcional entre la descripción del sistema recogida en el modelo conceptual y su reificación en un entorno de 
programación de acuerdo con el modelo de ejecución. 
3. Implementación en ORACLE 
Vamos a presentar una implementación concreta del modelo de ejecución anterior. En este caso 
describiremos de forma simple, el conjunto de reglas necesarias para implementar un modelo conceptual OO de 
OO-Method en un entorno Oracle-v7. 
Resumidamente, por cada clase se genera una tabla ORACLE, cuya clave primaria estará formada por los 
atributos subrayados en la especificación gráfica de la clase. Cada atributo constante o variable se implementará 
como una columna en la tabla. Además, cada clase generará un usuario y un esquema. Las clases cuyos objetos 
sean activos (agentes de otros) generarán un rol. Este rol incluirá todos los privilegios concedidos a los usuarios. 
Cada clase tendrá un conjunto de formularios que se utilizarán para implementar las transacciones de los objetos 
de la clase, como veremos más adelante. 
El proceso de traducción lo podemos dividir en dos fases, en las cuales generamos: 
• El modelo lógico relacional. 
• Los paquetes, procedimientos, funciones, disparos y formularios necesarios para introducir la 
dinámica en nuestro sistema. 
3.1. El Modelo de Datos 
Para obtener el modelo lógico relacional nos centraremos en dos secciones de la especificación de la clase: 
• Definición de atributos. 
• Restricciones de integridad estáticas. 
Cada clase se representa como una tabla dentro de su propio esquema. Las columnas de esta tabla serán cada 
uno de sus atributos constantes y variables. Cada ejemplar de la clase será una fila en la tabla. Los atributos 
derivados se representarán como una columna de la tabla o como una función dependiendo del diseñador. Si se 
ven como atributos virtuales, la función que calcule su valor tendrá que definirse en el paquete que, como 
veremos más tarde, incluirá los servicios del objeto. Si elegimos almacenarlos, se definirán de la misma manera 
que los otros, pero además será necesario declarar disparos que mantengan actualizado este campo (por ejemplo, 
disparos pre-insert y pre-update asociados a la tabla). 
Los atributos que componen el identificador de los objetos de la clase se representarán como la(s) columna(s) 
que constituye(n) la clave primaria de la tabla. Los atributos constantes por definición son not null. Los 
atributos variables se definirán como not null si deben introducirse obligatoriamente como un argumento del 
evento de creación o si se han declarado con un valor por defecto. Toda esta información se habrá introducido a 
nivel conceptual durante la definición de la clase. Las restricciones de integridad estáticas se representarán como 
restricciones de la tabla, que se validarán sobre los atributos del objeto. Como ejemplo, podemos ver la siguiente 
sentencia CREATE TABLE para la clase Trabajos: 
 CREATE TABLE Trabajos 
(nro_trabajo(6) CONSTRAINT pk_trabajo PRIMARY KEY 
 CONSTRAINT ck_trabajo CHECK(nro_trabajo<200000), 
descripcion varchar(50) NOT NULL, 
centro_trabajo number(5) CONSTRAINT fk_cen REFERENCES 
centros(cen_num), 
especialidad_trabajo number(3) CONSTRAINT fk_esp REFERENCES 
especialidades (esp_num),programa_economico number(2) CONSTRAINT fk_peco REFERENCES 
programas(num_pro), 
situacion number(2) DEFAULT 0, 
nro_marcas number(2) DEFAULT 0, 
control number(2) DEFAULT 0) 
Agregación 
Cuando se define una clase como agregada la cardinalidad asociada al enlace establecido entre la clase 
compuesta y su clase componente determinará dónde se incluye la restricción de clave ajena correspondiente. La 
clave ajena representará la agregación. 
Como se hace normalmente, una cardinalidad (máxima) de 1:M generará una clave ajena en la clase que 
participa con cardinalidad M en la agregación. Esto ocurre por ejemplo con trabajos y centros, siendo 
centro_trabajo la clave ajena de trabajos. En este caso, centros es una agregación de trabajos con cardinalidad 
1:M. Una cardinalidad 1:1 generará (al menos) una clave ajena, y una cardinalidad M:N generará una tabla 
nueva cuya clave primaria será la compuesta por las claves de las clases componentes, en este caso la clave 
primaria de la nueva tabla también será la clave ajena que referenciará las tablas componentes. Las claves ajenas 
que representan a las clases componentes se definirán como atributos NOT NULL en la tabla agregada si la 
cardinalidad mínima es 1. 
De forma muy resumida, la agregación en Oasis tiene una taxonomía muy rica que determina una gran 
cantidad de situaciones que se pueden dar en una agregación. Dependiendo de los tipos de agregación 
(especificados en el modelo conceptual) sabremos la cardinalidad de la relación entre contenedor y componentes. 
Una vez conocido el tipo de agregación manipularemos la cardinalidad como se hace normalmente [Teo86], y 
etiquetaremos la restricción de clave ajena con null, restrict o cascade para las operaciones de 
actualización y borrado según corresponda. Esta conversión se explica con ejemplos en [Pas94]. 
Herencia 
En Oracle una clase especializada se representará como una tabla que tendrá como clave primaria la de su 
clase padre. Las columnas de esta tabla serán los atributos que no pertenecen a la clase padre. Si no existen 
atributos especializados podremos implementar la herencia como una vista de la clase padre. 
3.2. La Dinámica 
La dinámica de los objetos se define mediante los eventos y transacciones que pueden activarse, los estados 
válidos por los que puede pasar un objeto durante su vida (process), las restricciones de integridad dinámicas que 
deben satisfacerse y la interfaz de usuario que caracteriza la interacción del usuario. Por ello en Oracle debemos 
ser capaces de representar: 
• Eventos: Evaluaciones, Precondiciones y Disparos. 
• Transacciones y Procesos 
• Interfaces 
Eventos, Transacciones y Disparos se implementan mediante procedimientos y disparos almacenados en el 
esquema asociado a la clase. Para representar los procesos adecuadamente será necesario introducir el concepto 
de orden en el espacio de eventos y transacciones, un concepto que no existe en el Modelo Relacional. 
Los eventos de un objeto se representan como procedimientos y funciones en un paquete. El paquete 
correspondiente a la clase trabajos de nuestro ejemplo será: 
 
 
 
create package trabajos_pack as 
procedure crear_trabajo (nro_trabajo number, descrip char, cent_trab 
number, esp_trab number,pro_economico number); 
procedure borrar_trabajo (num_trab number); 
procedure marcar (nro_trabajo number, uc number); 
procedure desmarcar (nro_trabajo number); 
procedure contratar (nro_trabajo number, dni number); 
procedure cerrar_trabajo (nro_trabajo number) 
end trabajos_pack; 
Los eventos y las transacciones se representarán como procedimientos que podrán tener argumentos. 
Los argumentos de los procedimientos se podrán utilizar en las acciones definidas en la fórmula de evaluación. 
Cada procedimiento posee una excepción que representará la precondición del evento. Si no se cumple la 
precondición, se eleva la excepción asociada y se efectúa un rollback de los cambios. Vamos a ver por ejemplo 
el procedimiento asociado al evento marcar de la clase trabajos: 
procedure marcar (nro_trab number,uc number) is 
 exc_marcar exception; 
 uc_ac number(2); 
begin 
select control into uc_ac from trabajos where nro_trabajo=nro_trab 
if uc_ac !=0 then 
 raise exc_marcar; 
end if; 
update trabajos set control = uc, nro_marcas = nro_marcas + 1 where 
nro_trabajo=nro_trab; 
end marcar; 
y para la transacción cerrar_trabajo tenemos el siguiente procedimiento: 
procedure cerrar_trabajo (nro_trab number) is 
begin 
 borrar_trabajo (nro_trab); 
 personas_pack.despedir(nro_trab); 
end cerrar_trabajo; 
Los eventos compartidos los representamos mediante un procedimiento que está presente en los paquetes de 
las clases en las que está definido. Para reutilizar código lo implementaremos en el paquete de una clase y los 
demás paquetes lo tendrán definido como una referencia a éste. 
En el paquete de una clase especializada, tendremos que definir los eventos de la clase padre 
referenciándolos como hemos visto anteriormente. 
El evento de creación inserta una fila (se corresponderá con un nuevo objeto) en la tabla. Cuando se cree un 
objeto activo también se creará un usuario para dicho objeto. Con este fin se definirá una transacción en la que se 
incluirá la secuencia de eventos que han de ocurrir y se traducirá a Oracle como un procedimiento que ejecute la 
secuencia de eventos y realice un commit cuando termina cada una de las operaciones. Si ocurre una excepción 
asociada a un evento componente de la transacción, entonces se hará un rollback de los cambios que hayan 
tenido lugar para asegurar la política de "todo-o-nada" y la "no-observabilidad de estados intermedios". Las 
transacciones también pueden tener argumentos. 
Los disparos podrán implementarse como disparos de la base de datos que se ejecutan como resultado de una 
acción de inserción o borrado. 
En la especificación de una clase, el proceso (la sección process en Oasis o el DTE en el modelo dinámico) 
define la secuencia válida de eventos en la vida de un objeto. Un objeto cambia de estado ante la ocurrencia de 
un evento o transacción, por lo que, para saber si el evento ocurrido es válido tendremos que comprobar si forma 
parte de una secuencia válida de eventos (comprobando que en el estado6 en el que se encuentra y ante la 
ocurrencia del evento, puede alcanzar un nuevo estado en el proceso definido). Para poder realizar estas 
comprobaciones podemos incluir en la tabla asociada a la clase un nuevo atributo donde guardaremos el estado 
actual (en el proceso) del objeto. Con esta información podremos invalidar la ocurrencia de un evento que no 
forme una vida válida (secuencia de eventos), añadiendo una nueva excepción en el código del procedimiento 
asociado con el evento o transacción. 
 
6 En este punto con estado nos referimos a los estados (situaciones) del DTE o del process de la clase en OASIS 
Las acciones que pueden activar los objetos se especifican como interfaces entre objetos y se implementan 
como privilegios concedidos a los usuarios. Por ejemplo, si en la especificación hemos dicho que un objeto O1 
de la clase C1 puede ser actor de un evento E2 definido en la clase C2, lo traduciremos a Oracle-v7 dándole al 
rol asociado con C1 permisos de ejecución sobre el procedimiento E2 definido en el paquete correspondiente a 
C2, y añadiremos el objeto O1 al rol de C1. En el ejemplo propuesto, hemos asumido que los administradores 
serán los usuarios finales activos. Así pues, como podemos ver a continuación para un usuario crearemos un 
usuario administrador adm1, y lo incluiremos en el rol admin (se asume ya creado) que tendrá concedidos los 
privilegios de ejecución sobre los procedimientos del paquete 'trabajos_pack': 
grant execute on trabajos_pack to admin; 
create user adm1 identified by xxx; 
alter role admin add adm1 
La interacción del usuario con el sistema se realizará mediante formularios. Creándose tantos formularioscomo eventos o transacciones se hayan especificado. 
Un breve escenario del uso de la aplicación será el 
siguiente: El usuario se conectará al sistema (Ver 
Figura 9). Una vez conectado le aparecerá un menú 
con una opción con el nombre de cada clase. Si el 
usuario elige una opción, aparecerá un menú asociado 
a la clase seleccionada, incluyendo una opción por 
cada evento o transacción que el usuario puede activar 
(de la cual es actor). 
Cada opción del menú tendrá asociado su 
correspondiente formulario (ver Figura 10), que se 
utilizará para pedir los parámetros necesarios para 
ejecutar el evento/transacción. El botón OK tendrá 
asociada una llamada al procedimiento que implementa 
el evento/transacción. 
4. Conclusiones 
En este trabajo se ha presentado una estrategia para implementar objetos en un entorno ORACLE, en la cual 
el patrón de una clase de objetos pasivos se representa mediante un usuario, un esquema (incluyendo una tabla 
(estado), un paquete (métodos) y un conjunto de disparos de la base de datos (disparos). Una clase de objetos 
activos necesita además un rol. En este caso un objeto es un usuario que tiene asociado el correspondiente rol de 
su clase. Cuando un objeto le pide un servicio a otro equivale a que el usuario ejecuta un procedimiento de otro o 
el mismo (si es de la misma clase) esquema. Esto se gestiona declarando los permisos correspondientes. La 
interfaz de usuario se determina asociando un formulario a cada una de las acciones que el usuario puede 
ejecutar. 
Para concluir podemos decir que esta aproximación nos permite afirmar que para desarrollar cualquier 
aplicación se puede realizar un análisis y diseño orientado a objetos, incluso si se implementa sobre una base de 
datos relacional. 
 
 
Figura 9. Conexión del usuario al sistema. 
 
Figura 10. Entrada de datos para el evento marcar y código asociado al botón OK. 
procedure ok_marcar (nro_trab number,uc 
number) is 
begin 
trabajos_pack.marcar (nro_trab, uc); 
commit; 
 exception 
 when others then rollback; 
end ok_marcar; 
Bibliografía 
[Bal83] Balzer R. et al. Software Technology in the 1990s: Using a New Paradigm IEEE Computer, Nov.1983 
[Boo94] Booch,G. OO Analysis and Design with Applications. Addison-Wesley, 1994. 
[BRJ96] Booch,G.,Rumbaugh,J.,Jacobson,I. Unified Modeling Language. Version 0.91. Rational Software Corporation. 
[Pas92] Pastor,O; Hayes,F.; Bear,S. Oasis:An Object Oriented Specification Language; Proc. of CAiSE-92 Conference 
Lecture Notes in Computer Science (593), Springer-Verlag, pag. 348-363. (1992) 
[Pas94] Pastor,O; García,R. El Modelo Orientado a Objetos aplicado al Diseño e Implementación de entornos ORACLE; in 
the Proceedings of CUORE-94, Benalmádena Málaga (Spain). (1994) 
[Pas95-1] Pastor,O., Ramos, I. Oasis 2.1.1: A Class-Definition Language to Model Information Systems Using an Object-
Oriented Approach, February 94 (1ª ed.) ,Mars 95 (2ª ed.), October 95 (3ª de.). 
[Pas95-2] Pastor,O.;Garcia,R.;Cuevas,J. Implementation of an OO Design in an Oracle7 Development Environment. Proc. 
of the European Oracle Users Group Conference, EOUG-95. Vol.4 pags: 35-47, Firenze (Italy). (1995) 
[Pas96] Pastor, O.; Pelechano, V.; Bonet, B.; Ramos, I. : An OO Methodological Approach for Making Automated 
Prototyping Feasible. Proceedings of DEXA96, Springer-Verlag, September (1996). 
[Pas97] Pastor, O.; Insfrán, E.; Merseguer, J.; Romero, J.; Pelechano, V.: OO-METHOD: An OO Software Production 
Environment Combining Conventional and Formal Methods.CAiSE97, June (1997). Accepted for presentation. 
[Rum91] Rumbaugh J.,Blaha M., Permerlani W., Eddy F.,Lorensen W. Object Oriented Modeling and Design. Englewood 
Cliffs, Nj. Prentice-Hall. 
[Teo86] Teorey,T.;Yang,D.;Fry,J.; A logical Design Methodology for Relational Databases Using the Extended Entity-
Relationship Model; Computing Surveys, Vol.18,No2,June (1986).