Parte III

Modelo
Orientado a
Objetos

77
 Parte III Modelo orientado a objetos.
En estos momentos el MOO ha cobrado un reconocimiento internacional que se demuestra
con la expansión y utilización de productos de software que soportan éste modelo. El
paradigma de la OO es un nueva forma de pensar acerca del proceso de descomposición de
problemas y del desarrollo de soluciones, que es el resultado de la evolución de los
conceptos de la informática y que llevó a una revolución en éste campo. Esta tecnología
afecta al análisis, diseño y a la programación de sistemas y a la interfaz del usuario final
con el entorno de aplicación.

78
 Capítulo 4
Introducción al
modelo orientado
a objetos.

79
 Capítulo 4 Introducción.

Buscándole solución a la crisis del software surgió, en el campo de la programación, la

programación estructurada y un poco más tarde la programación modular y el diseño
estructurado. A pesar de sus muchas ventajas, al aumentar las expectativas de los usuarios
acerca de lo que se podía hacer con la computadora, surgieron un mayor número de
problemas más complejos a resolver. Además , para reducir el tiempo de realización de un
producto se hace necesario reutilizar elementos que han sido desarrollados por otros
sistemas, pero las técnicas existentes no ayudaban lo necesario en éste sentido. Es por esto
que surgió la tecnología OO que introduce nuevos conceptos en el campo de la informática
y que ha provocado una revolución en todos los órdenes.
Khoshafian y Abnous analizaron las posibles alternativas para unir las capacidades de las
BD y los conceptos de la OO, llegando a 6 posibles soluciones:
1. Extender los lenguajes OO con las capacidades de las BD.
2. Crear un modelo de datos y lenguaje de datos nuevo.
3. Extender los lenguajes de BD con las capacidades OO.
4. Proporcionar bibliotecas extendibles para manejo de BD.
5. Incluir lenguaje de BD en lenguajes de POO o viceversa.
6. Productos específicos para manipular BDOO.
Todas estas alternativas han sido explotadas por las compañías que se han dedicado a
producir éste tipo de productos.
Las características de éste modelo y lo que se espera de los SGBDOO, son abordadas en
éste capítulo. Además se hace referencia a un modelo que es la muestra de la coexistencia
de los modelos relacional y OO, el modelo híbrido.
Las preguntas que proponemos son:
 ¿En qué se fundamenta la no compatibilidad del MR con las BDOO?.
 ¿Qué caracteriza al modelo híbrido?.


Khoshafian, S. and Abnous, R. “Object-orientation: concepts, languages, databases, user interfaces. Jhon
Wiley & Sons, Inc.1990.

80
Tecnología Nueva filosofía
Orientada que permite
a Objetos representar más
semántica. Los usuarios
necesitan incorporar
persistencia a los
Tecnología Técnicas que lenguajes orientados a
de las han mostrado objeto
Bases de datos su eficacia en el
almacenamiento
y manipulación
de la información.

4.1 – Conceptos de la orientación a objetos.

Todas las ventajas de éste enfoque giran alrededor de la posibilidad de aumentar la

productividad, pero esto no es tarea fácil. Depende del analista lograr un diseño que explote
todas las posibilidades que brinda porque todo depende de la manera que miremos y
representemos el mundo. Como plantea Timothy Budd: “La programación orientada a
objetos es una nueva forma de pensar acerca de lo que significa computar, acerca de cómo
pensamos estructurar la información dentro de un computador. (...) Aplicar con
efectividad los nuevos recursos exige un cambio de percepción, es decir, una forma de
pensar completamente nueva en cuanto a la resolución de problemas”.
Para comprender cómo ha sido el impacto que ha tenido en el campo de los sistemas de
gestión, es preciso formalizar antes los principales conceptos que caracterizan ésta nueva
tecnología.

4.1.1 – Clase.

Es la implementación de un tipo de dato abstracto que (Figura 4.1):

 los usuarios pueden definir y
 representa una idea simple o conceptos y características de objetos que tienen
operaciones semejantes y propiedades útiles, por lo tanto, agrupa comportamiento y
atributos comunes de objetos del mundo real.
Esto garantiza la independencia de los datos porque:
 Dependencia de los datos: Una aplicación es dependiente de los datos si es imposible
alterar la estructura de almacenamiento ( la organización física de los datos) o la técnica
de acceso ( la forma de accesar a ellos) sin afectar la aplicación.

 An introduction to object-oriented programming. Addison-Wesley Publishing Co. 1991.

81
 Independencia de los datos: Inmunidad de las aplicaciones a los cambios en la estructura
de almacenamiento y en la técnica de acceso.
Entonces, se puede cambiar la representación de los objetos y la forma de accesar la
información sin tener que volver a escribir ninguna de las aplicaciones que utilicen esos
objetos.
Mamífero Atributos
Perro León
 Nombre
 Cantidad de Patas
… Métodos
Mundo real

 Informar cantidad de patas.

 Informar nombre.
Implementación de los …
métodos
…

Implementación en un lenguaje
de programación orientado a
objetos.
Figura 4.1 Clase.

4.1.2 – Objeto.

 Es un concepto del mundo real que puede ser modelado por una clase. Es una
abstracción del mundo real (Figura 4.2).
 Tiene un tipo, es decir, es una variable de un tipo dado.
 Tiene un valor, es decir, en cada momento está en un estado que depende del valor de
sus atributos.
 Posee un identificador de objeto único generado por el sistema que nunca puede ser
modificado, no es una propiedad del objeto (como lo eran las llaves primarias) y el
programador no conoce su valor ni le interesa (puede considerarse como un atributo
oculto en el sentido de que por lo general no puede percibirse ni manipularse
directamente).
 Los atributos pueden ser atómicos (los definidos por el sistema, por ejemplo, entero) y
complejos (otros objetos).

Perro León

Mundo real
Figura 4.2 Objetos.

82
4.1.3 – Encapsulamiento

 Cada tipo de dato abstracto se puede ver como si tuviera dos caras. Desde el exterior, el
cliente (usuario) de un tipo de datos abstracto ve nada más un conjunto de operaciones,
que definen el comportamiento de la abstracción. En la otra cara el programador, que
define la abstracción, ve las propiedades que se usan para mantener el estado interno del
objeto y la implementación del comportamiento (Figura 4.3).
 Lo anterior se basa en dos principios de David Parnas expuestos en “On the criteria to be
used in descomposing systems into modules”, en 1972:
Uno debe proporcionar al usuario toda la información necesaria para usar correctamente
el módulo, y “nada más”.
Uno debe proporcionar al implantador toda la información necesaria para completarlo,
y “nada más”.
Dicho de otra manera, si usted no necesita conocer determinada información, no debe tener
acceso a ella.


Este encubrimiento explícito e intencional de información es la “ocultación de
información” o “encapsulamiento”. El concepto de independencia de los datos está muy
relacionado con él, por esto al encapsulamiento de los objetos se le conoce como
abstracción de la información.

 Valores:array[1..max] of integer
 Meter  TopeActual:0..max
 Sacar  Function Tope:Boolean
 Tope Begin
Tope:=TopeActual=max
End;
…

Cara de la interfaz de la pila Cara de la implementación de la pila

Figura 4.3 Encapsulamiento.

4.1.4 – Comunicación a través de mensajes.

 Es la forma en que un objeto interactúa con otros objetos. Un objeto emisor (cliente)
envía un mensaje a otro receptor (servidor) (Figura 4.4).

83
 Ignorar.
Acciones del Contestar.
receptor Ejecutar una acción que implique modificaciones
internas de su estado.
Enviar un mensaje a otro objeto.

 Cada objeto será capaz de responder a diferentes peticiones de servicio. Esto no debe
confundirse con tradicionales llamadas de funciones de la programación tradicional. Las
llamadas a funciones son utilizadas para aplicar algún proceso estándar a los datos, que
se reciben como parámetros, como parte de la ejecución de otra función.

Cliente Mensaje
M4 M1 Servidor/cliente
Objeto 1 M2 M3
M3 M2 Objeto 2
Mensaje M1
M4 M3
Objeto 3
M1 M2

servidor
Figura 4.4 Comunicación a través de mensajes.

4.1.5 – Meronimias.

Reflejan el concepto de “parte de”, donde se llama:

 holónimo : entidad compuesta
 merónimo : a cada uno de sus componentes
Los tipos que existen representan distintos aspectos del concepto “ser parte de” o “formar
parte de”.
Tipos:
 porción/masa
 materia/objeto

84
 actividad/subactividad
 lugar/área
 componente/objeto integral (agregación)
 miembro/colección (agrupamiento)

Agregación

 Es un tipo de datos definido en términos de otros. Si tenemos tipos de objetos E1, E2, …,
En; se puede definir un objeto agregado E tal que E1, E2, …, En son componentes del
objeto tipo E si todos se relacionan para cumplir una función. E1, E2, …, En pueden ser
simples o complejos. De estos últimos se tiene el identificador.

 Pueden distinguirse:
 Agregación simple de atributos para construir un objeto.

Persona Nombre, Edad y Sexo.

 Agregación de tipos de objetos para construir un objeto.

Profesor (complejo)
Curso (Complejo)
Conferencia Día (simple)
Lugar (simple)
Hora (simple)
Agrupamiento (covering)

 Un tipo de objeto es un cover de un tipo de objetos M, si toda la instancia de E

corresponde a un conjunto de instancias de M.

E - tipo cover
M - Tipo miembro

Flota cover(barco)

Departamento Nombre
cover(Curso que imparte)
cover(Persona que trabaja en él)

85
Generalización

 Sean Object1, Object2, …, Objectn tipos de objetos con propiedades comunes, entonces
se puede definir un tipo de objeto Object tal que sus atributos y comportamiento, son
los comunes para los Objecti/i= 1,2,…,n de forma que los Objecti son subtipos de
Object.

Trabajador
 Nombre
 CI
 Dirección
 Salario
 Cambiar salario
 Cambiar dirección

Docente Administrativo
 Categoría  Área
 Departamento  Labor
 Cambiar categoría  Cambiar área
 Cambiar departamento  Cambiar labor
 Cambiar salario  Cambiar salario
Pueden clasificarse, tal como se vio en la parte anterior, en:
 Total sin solapamiento.
 Total con solapamiento.
 Parcial sin solapamiento.
 Parcial con solapamiento.

4.2 – ¿Porqué no el modelo relacional para base de datos orientadas a objeto?.

El modelo relacional se basa en la teoría matemática de las relaciones por lo que una base
de datos relacional se ve como una tabla en la que se almacenan datos atómicos. Los
objetos del mundo real son más complejos al encerrar más semántica y una BDOO pretende
manipular ésta complejidad.

86
No obstante existen autores (entre ellos C. J. Date) que buscan similitudes entre ambos
modelo, pero aunque hay conceptos que coinciden, un objeto es algo más.

4.2.1 – Problemas de los SGBDR y soluciones.

El modelo relacional no es la solución a todos los problemas ni nunca se aseguró que lo

fuera, existen un grupo de problemas a los que no le da directamente solución:
1. Los SGBDR centran su atención en sistemas de gestión por lo que hay aplicaciones
para los cuales resultan inadecuados.
Ej.: • CAD (Computer-Aided Design)
• CASE (Computer-Aided Software Engineering)
• Hipertexto ( Ej.: el diseño de un periódico)
2. No soportan igualmente bien todos los sistemas de gestión.
Ej.: Sistema de seguro
 Nombre y cobertura de cada persona asegurada.
 Imágenes fotográficas del suceso al que se refiere la reclamación.
 Facsímil del impreso original en el que se escribió la reclamación.
3. Enriquecimiento de la base de datos a partir de aplicar reglas que deduzcan nueva
información a partir de la existente.
Ej.: Diseño de una revista, se deduce ubicación de cada nuevo reporte, propaganda,
etc., teniendo en cuenta características de la información a mostrar, no exista
propaganda de competidores en una misma página, entre otras condiciones.
4. Necesidad de hacer consultas recursivas.
Ej: Ensamblajes …
Ensamblaje
Ensamblaje Piezas
Piezas

Soluciones
a. Ampliar el modelo relacional en forma apropiada. En este sentido han surgido
extensiones del modelo que agregan más semántica de manera que se pueden representar
otras abstracciones tal como se dan en le mundo real.
Ej.: • Los tipos de datos de una columna pueden ser otra tabla (para datos complejos).
• Métodos asociados con tablas.
• Tablas organizadas en jerarquías que heredan los esquemas de las tablas
ancestras.

87
b. Desechar por completo el modelo relacional y sustituirlo por algo nuevo. Los modelos
que han surgido a partir de aquí son:
• semántico
• deductivo
• orientado a objetos

Modelos nuevos  Definen a los SGBD de

3ra generación

4.2.2 – Principios de los SGBD de 3ra generación.

(según el manifiesto del SBD de 3ra generación, 1991)

1. Más allá de lo servicios tradicionales de gestión de datos, los SGBD de 3ra generación
proporcionarán apoyo a estructuras de objeto y reglas más ricas.
1.1 Deben tener un sistema rico de tipos, siendo deseable:
 Un sistema de tipos de datos abstractos para construir nuevos tipos
básicos.
 Un constructor de tipos de matrices.
 Un constructor de tipos de secuencias.
 Un constructor de tipos de registros.
 Un constructor de tipos de conjuntos.
 Funciones como tipos.
 Un constructor de tipos de unión.
 Composición recursiva de los constructores anteriores.
1.2 Permitir que los tipos se organicen en una jerarquía de herencia (simple y
múltiple).
1.3 Inclusión de funciones (métodos de las clases) en la BD y permitir que los
diseñadores de aplicación tengan a su alcance los beneficios de la
encapsulación.
1.4 Asignación automática de identificadores solo cuando no se disponga de una
clave primaria.
1.5 Inclusión de reglas (activaciones, restricciones) en la BD no asociadas con
los métodos.
2. Los SGBD de 3ra generación deben subsimir a los SGBD de 2da generación.
2.1 Todo el acceso a una BD debe hacerse a través de un lenguaje de consulta no
procedimental y de alto nivel.

88
 2.2 Permitir realizar cambios sin afectar la aplicación a través del uso de vistas
actualizables o colecciones virtuales que en los SGBD de 2da generación
garantizan mejor que en los de 1ra encapsular el acceso a la BD, pero se
debe trabajar más en esto.
2.3 Debe quedar oculta la gestión interna que haga el sistema de gestión (los
detalles físicos) a los programadores de aplicaciones. No se puede renunciar
a la independencia de los datos.
2.4 Para especificar colecciones (tales como matrices, conjuntos, secuencias,
etc.) se debe usar alguna de las siguientes vías:
 Extensional : la representación es una colección de
apuntadores en el que la condición de miembro de cada conjunto se
determina manualmente por el programador de la aplicación.
Ej.: Alumnos (nombre,edad,promedio)
Grupos (número, integrantes)
Apuntadores a los alumnos que
pertenecen al grupo
 Intencional: la representación se especifica mediante expresiones
SQL, de manera que el establecimiento de la condición de miembros
se mantiene de forma automática.
Ej.: Supongamos que los alumnos se clasifican teniendo en
cuenta la edad.
Grupos (número, edad mínima, edad máxima, integrantes)
3. Deben estar abiertos a otros subsistemas.
3.1 Ser accesibles desde múltiples lenguajes de alto nivel.
3.2 Lenguaje común de definición y manipulación de datos.
3.3 SQL es la forma universal de expresar consultas por lo que es un candidato
razonable como lenguaje de consulta.
3.4 La relación entre el servidor y una estación de trabajo remota debe ser
usando expresiones de consultas.

4.2.3 Situación actual.

 Hay muchas propuestas de las anteriores que cumplen los SGBDOO, pero hay otras
donde hay profundos desacuerdos.
 El modelo relacional se basa en fundamentos tan sólidos como el álgebra y el cálculo
relacionales por lo que resulta casi imposible desechar por completo el modelo
relacional y sustituirlo por algo nuevo, pero requiere de grandes cambios para
satisfacer las demandas.
 Actualmente en el mercado:

89
  Numerosos SGBDR
 Más de 20 SGBDOO.
 SGBDR que incluyen capacidades de la orientación a objetos y viceversa.
 No existe un modelo de datos (de objetos) comúnmente aceptado y a la vez no existen
suficientes fundamentos formales que soporten un posible modelo.
 Existe una fuerte actividad experimental y se están desarrollando sistemas al mismo
tiempo que se proponen modelos.

4.3 – Sistemas de Gestión de Base de Datos Orientados a Objeto.

Los SGBDOO surgen de la convergencia entre la tecnología de las BD y el paradigma de la

OO, con el fin de entender a requisitos para los cuales los productos relacionales no dan
una respuesta satisfactoria.
Ejemplos de aplicaciones que los requieren:
 textos: automatización de oficinas CAP (Computer-Aided Publishing),
 multimedia,
 eventos: tiempo real, control de procesos y gestión de redes,
 objetos complejos: sistema de información geográfica,
* multidimensiones: simulación modelación,
* reglas heurísticas y
* grafos de 2da y 3ra dimensión.

BDOO = Orientación a objetos+Capacidades de las BD

 Tipos abstractos de datos  Persistencia

 Herencia  Transacciones
 Identidad de objetos  Control de ocurrencias
 …  Recuperación
 Mecanismo de consulta
 Versiones
 Integridad
 Seguridad
 Requisitos de ejecución
4.3.1 – Definición.

Una BDOO es una colección de clases e instancias de clases (objetos) que pueden ser
almacenados y recuperados por un SGBDOO. Es un sistema diseñado para almacenar y
recuperar objetos complejos en lugar de artículos contenidos en tipos de datos simples. No

90
existe una definición estándar de los que es un SGBDOO, no obstante se aceptan las reglas
propuestas en la 1ra Conferencia Internacional de BDOO y BDD.
Grady Booch plantea que es un programa de computación que combina la semántica de los
lenguajes de programación orientado a objetos con la manipulación de datos y facilidades
de consulta de un sistema de gestión de base de datos convencional.

4.3.2 – Reglas de Oro.

(Manifiesto de los SGBDOO, 1ra Conferencia Internacional de BDOO y BDD, Kyoto, 1988)

1. Soporte para el tratamiento de objetos complejos (“Prestará soporte a los objetos

complejos”).
Incluye  Constructores de objetos complejos (conjuntos, matrices, listas).
 Operadores para tratar dichos objetos, es decir, las operaciones sobre
un objeto complejo deben propagarse transitivamente a todos sus
componentes.
2. Identidad del objeto (“Prestará soporte a la identidad del objeto”).
Cada objeto debe poseer un identificador (OID- Object Identifier) que suministra
automáticamente el sistema lo que reduce la duplicación y libra al diseñador de la
necesidad de crear llaves únicas.
3. Encapsulamiento (“Encapsularás tus objetos”).
 Hay un solo modelo de datos y operaciones de manera que la información se
encapsula.
 Se puede permitir violar el encapsulamiento bajo ciertas condiciones porque las
consultas son frecuentemente expresadas en términos de predicados con los
valores de los atributos. Por lo tanto casi todos los SGBDOO permiten el acceso
directo a los datos suministrando operaciones definidas por el sistema para leer y
modificar los atributos. Estas operaciones son proporcionadas como parte del
sistema de una forma eficiente y a bajo nivel.
4. Herencia (“Tus clases o tipos heredarán de sus ancestros”).
5. Posibilidad de crear nuevos tipos a partir de los existentes (“serás extensible”).
6. Soportar la noción de tipo y la de clase (“Prestarás ayuda a los tipos y clases”).
Tipo: rasgos comunes a un conjunto de objetos con las mismas características.
Corresponde a la noción de tipo de datos abstracto. Tiene dos partes: la
interface (visible a los usuarios del tipo) y la implementación (visible al
diseñador del tipo). Se usan principalmente en tiempo de compilación para
comprobar la corrección de programas.
Clase: su especificación es la misma que la del tipo, pero es más una noción de
implementación. Contiene dos aspectos:
 Fábrica de objetos: creación de objetos nuevos de algún objeto prototipo
representativo de la clase.

91
  Almacén de objetos: a cada clase se le asocia su extensión (conjunto de
objetos que son muestra de ella). El usuario puede manipularlos aplicando
operaciones sobre todos o algunos de los objetos que lo forman.
7. Sobrecarga, enlace tardío y redefinición (“No unirás prematuramente”).
Sobrecarga: utilización del mismo nombre para diferentes operaciones.
Enlace tardío: traducción de los nombres de las operaciones a direcciones de memoria
en tiempo de ejecución.
Redefinición: redefinición de la implementación de las operaciones con el mismo
nombre por cada objeto según su tipo.
8. Posibilidad de hacer cálculos complejos (“Harás cálculos complejos”).
Expresar cualquier función computable utilizando el DML de un sistema de BD sin
necesidad de diseñar nuevos lenguajes de programación. Los cálculos complejos
pueden introducirse a través de la conexión con los lenguajes de programación
existentes.
9. Persistencia (“Recordarás tus datos”).
Capacidad de un objeto de conservar su valor en el espacio y en el tiempo.
10. Gestión de almacenamiento secundario (“Manejarás bases de datos muy grandes”).
Incluye  Indice
 Agrupamiento de datos
 Introducción de datos en memoria interna
 Selección de la vía de acceso
 Optimización de consulta
Estas características son invisibles para el usuario (el programador no debe escribir
código para mantenerlas), pero deben existir para garantizar el buen funcionamiento
de las aplicaciones.
11. Control de concurrencia (“Aceptarás a los usuarios concurrentes”).
Asegurar una coexistencia armoniosa entre los usuarios que trabajan simultáneamente
sobre la BD.
12. Recuperación (“Te recuperarás de los fallos de Hardware y Software”).
El sistema debe volver a algún estado coherente de los datos en caso de fallos,
cuando se realicen transacciones.
13. Facilidad de consulta Ad hoc (“Dispondrás de un mecanismo simple de consulta de
datos”).
 No es necesario que se haga en la forma de un lenguaje de consulta sino que se
proporcione el servicio.
 Debe satisfacer los siguientes criterios:

92
 a. Consultas de alto nivel (declarativas) donde se enfatice en el qué y no en el
cómo.
b. La formulación debe permitir alguna forma de optimización de la consulta.
c. Independiente la consulta de la aplicación para que pueda funcionar en cualquier
BD.
Defensores de las BDOO Detractores de las BDOO
Plantean que no se necesita mucha Una de las grandes ventajas de los SGBDR
complejidad porque en la descripción es el lenguaje de consultas y los usuarios se
del comportamiento se especifica todo han acostumbrado al uso de SQL. Sería un
lo que se desea de él. error desechar estas ideas. Además los
SGBD de 3ra generación deben subsimir a
los de 2da generación.


OQL (Object Query Language)
Tiene una sintaxis parecida al SQL, pero
Situación actual es más rico porque provee de primitivas
de alto nivel para tratar estructuras como
arreglos, listas y conjuntos de forma
eficiente. Su gramática está
perfectamente definida, su
implementación total es un reto.

4.3.3 – Características opcionales.

1. Herencia múltiple
2. Comprobación e inferencia de tipo
3. Distribución: objetos ubicados en diferentes procesadores.
4. Transacciones de diseño: soporte a transacciones largas y/o anidadas.
5. Versiones: Posibilidad de mantener las distintas versiones que de un objeto (como
objeto no como clase) puede haber.

4.3.4 – Comparación entre BDOO y BDR.

BDR BDOO
La normalización convierte a los atributos en Los atributos de las clases no solo son tipos
no descomponibles y en la práctica tienden a de datos simples, sino que además pueden
ser tipo de datos simples (entero, real, ser referencias a otras clases.
cadena, fecha , etc.)

93
 BDR BDOO
Las operaciones que se pueden hacer sobre Las clase encapsulan el comportamiento de
las relaciones se restringen a la actualización los objetos con las estructuras de datos. Se
y recuperación de tuplas. pueden acceder a facilidades
implementadas en otras clases a través de la
herencia.
Se necesitan muchas tablas normalizadas Los objetos están almacenados como un
para representar a un objeto del mundo real todo coherente por lo que la recuperación de
por lo que para recuperar objetos complejos, un objeto es una operación única, aunque
hay que hacer uniones de tablas. Esto es un puede ser grande. Esto se hace siguiendo los
proceso lento. identificadores.
Las propiedades de una entidad son Todos los objetos tienen un identificador
suficientes para identificar, es decir, uno o único que no tiene nada que ver con los
varias propiedades únicas y constantes atributos.
identifican a las tuplas de la entidad. Las
propiedades de unicidad y constancia no
siempre están presentes en el mundo real por
lo que a veces hay que introducir
identificadores artificiales.
Requieren que se fuerce la integridad Las clases son una abstracción que además
referencial. Algunos sistemas ofrecen de datos encapsulan a operaciones que
facilidades para especificarla, pero aún en pueden ser aplicadas sobre las instancias de
estos casos es responsabilidad del las clases. Además es posible cambiar la
programador asegurar que todas las implementación de estas operaciones sin
restricciones se cumplan. afectar otras clases ni las transacciones en
El modelo relacional es incapaz de que pueda aparecer (independencia) .
representar toda su semántica (por ej., no es Esto significa que las reglas de integridad
posible representar el hecho de que una pueden ser implementadas como métodos.
relación es de 1:1 ó 1:m). Como las aplicaciones comparten clases, no
Entre las aplicaciones no se comparte el solo comparten estructuras de datos sino
código, por lo que es muy difícil asegurar la también restricciones.
consistencia de los datos
Brindan pocas posibilidades para expandir o Están implementadas para permitir añadir
modificar la estructura de datos. Cambiar el más semántica.
dominio de los atributos, por ej., implica Ej.: ORION
reescribir las relaciones y cambiar las  cambiar contenido de clases
aplicaciones que hacen uso de ellas.  cambiar la jerarquía de clases
 cambiar el esquema

94
 BDR BDOO
Lenguajes de acceso no basados en Fundamentalmente basados en
procedimientos, es decir, son declarativos, procedimientos y no declarativos en el modo
basados en una lógica que está sometida a la de acceso, a través de relaciones declarativas
optimización de una consulta. explícitamente entre objetos y de estructuras
de clasificación. Por lo que requieren menos
optimizaciones y para las consultas de
objetos complejos pueden ser más
eficientes.
Existe un número fijo predefinido de eventos Cada método es un evento potencial, esto
primitivos (Insertar, Modificar, Eliminar). provoca que sea más difícil su detección.

4.3.5 – Problemas que resuelven.

1. La brecha semántica.
Elimina la llamada “brecha semántica” entre el dominio de la aplicación y su
representación en el medio de almacenamiento persistente. Esto es posible a través de
los conceptos de la OO que permiten representar las complejas entidades del mundo
real y manipularlas.
2. Requerimientos para aplicaciones ingenieriles y de automatización.
3. Errores de impedancia
Alivia los errores de impedancia entre los lenguajes de programación y los SGBD. En
aplicaciones complejas, los datos son recuperados de la BD usando un lenguaje de
consulta (Ej.: SQL) y entonces se manipularán a través de rutinas escritas en
lenguajes de programación convencionales, que son procedurales (Ej. : C, PL/1). Los
lenguajes de consulta son de alto nivel y más declarativos. Los lenguajes de la BD y
los lenguajes de programación son fuertes en alguno de los dos. Los LMD se una
BDOO típicamente incorporan:
 estructuras de control,
 variables e instrucciones de asignación,
 rica colección de tipos de datos y clases, y
 construcciones para definir métodos, funciones, tipos abstractos de datos (clases).
Algunas BD convencionales incorporan constructores de programación a través de
los Lenguajes de 4ta Generación (L4G).

95
4.3.6 – Limitaciones.

1. No existe un modelo de datos OO universalmente aceptado por lo que cada sistema

resuelve los problemas de manera particular sin considerar criterios de
compatibilidad.
2. En la práctica es difícil implementar la identidad de los objetos.
3. No es posible realizar optimizaciones sin comprometer los objetivos de la OO porque
para optimizar hay que examinar la implementación y se rompe el encapsulamiento.
4. Los problemas de la herencia múltiple.
5. Problemas con la escalabilidad, se dice que “grandes” volúmenes de datos no han
sido probados.
Ej: Sistema de Información Geográfica (GIS)
 20 clases
 10 000 líneas
 2 000 objetos
 500 métodos
 300 Mb disco duro
6. El desempeño con gran número de usuarios concurrentes y frecuentes transacciones “
no ha sido probado”.
Ej: Sistema de control de procesos
 120 usuarios
 300 clases
 3 millones de objetos
 2.5 Gb
7. Los productos son débiles en cuanto al manejo de los datos sobre todo en la
concurrencia, evolución del esquema y la optimización de consultas.

4.4 – Modelo híbrido.

Los modelos relacional y OO tienen dos puntos comunes importantes. Por un lado resultan
una mejora significativa contra el almacenamiento en ficheros y, por otro lado, ambos
intentan modelar cosas reales del mundo real y las relaciones entre ellas. Su diferencia
radica en que lo que vemos del mundo se capta de diferente forma en dependencia del lente
que usemos.
El MR y el SQL son aceptados como estándares, pero tienen problemas para trabajar con
datos complejos. A las BDOO se les critica sus limitaciones en el apoyo a las capacidades
de las bases de datos, en particular lo referente al lenguaje de consulta.

96
Hay un conjunto de aplicaciones que requieren aprovechar lo bueno de ambos modelo, por
lo que en los últimos años ha ido cobrando una mayor fortaleza la necesidad de un modelo
híbrido u objeto-relacional que permita dar soporte a las exigencias de éstas aplicaciones.
Existen compañías, como la Petrotechnical Open Software que ya decidieron moverse hacía
éste modelo por la necesidad de manipular videos, imágenes en 2 y 3 dimensiones, etc.; y
seguir explotando las capacidades administrativas de la tecnología relacional.
Expertos de compañías productoras de gestores de BD que trabajan en ésta línea plantean
que las dos tecnologías son complementarias y pueden trabajar juntas en beneficio de los
usuarios, y que Internet abre un campo de aplicaciones donde éste modelo es factible de
aplicar.

4.4.1 Definición.

No existe una definición estándar de lo que es un SGBD objeto–relacioonal (SGBDOR),

pero un factor importante es que apoye de manera integrada ambos modelos. La idea es
tomar del modelo relacional su seguridad, integridad y fiabilidad; y del modelo OO su
capacidad de almacenar datos complejos. Esta unión requiere extender SQL hacía el
tratamiento de objetos complejos.

4.4.2 Características.

Judth R. Davis definió un conjunto de rasgos que debe cumplir un SGBDOR, no obstante
ninguno de los productos existentes apoya todos estos rasgos, y cada uno lo hace a su
manera. Estas características son:
1. Permitir tipos de datos extensibles como listas, tipos de datos definidos por el usuario,
series y jerarquías de objetos.
2. Permitir funciones extensibles como funciones definidas por el usuario.
3. Permitir métodos de acceso definidos por el usuario que puedan mejorar la actuación
de los tipos de datos definidos por el usuario.
4. Navegación entre objetos a través del identificador único, lo que ofrece una nueva
forma de definir índices y accesar a datos denormalizados eficientemente.
5. Habilidad para entender y manipular los volúmenes de tipo de datos complejos que
permitan hacer consultas como: encontrar todos los lugares con una textura
determinada en un álbum fotográfico.
6. Integridad lógica al nivel del modelo de objeto: cuando un objeto se elimina, todos los
objetos que dependen de él se eliminan.
7. Apoyo para SQL y tablas relacionales.

“Object-relational database managers (ORDBMD)”. Distributed computing monitor, Feb 1995 V10 n2
p3(27).

97
8. Funciones de manipulación de BD robustas (seguridad, integridad a través de la
manipulación de transacciones, facilidades para salva/restaura, capacidades de BD
distribuidas, replicación de datos, procesamiento paralelo, etc.).
9. Acceso a datos heterogéneos.
10. Herramientas para visualizar y manipular datos complejos.

4.4.3 Estado del mercado.

Existen diferentes formas de manifestarse los sistemas híbridos: construir una solución
total, usar herramientas de desarrollo OO (front-end) con un back-end relacional, y
adicionar características OO a SGBDR.
Michael Stonebraker se considera el padre de la tecnología híbrida pues empezó a trabajar a
finales de los ’80, en la Universidad de California, con un grupo de estudiantes
universitarios y un programador a tiempo completo, en el desarrollo de una BD objeto-
relacional. Como resultado se obtuvo Postgres, que está basado en SQL en vez de en un
lenguaje de 3ra generación OO. La madurez de ésta tecnología la alcanzó con Illustra.
Illustra Information Technologies fue fundada en 1992 por Stonebraker y es la productora y
comercializadora de éste producto.
La primera versión de Illustra aparece en Agosto de 1993, en 1995 ya contaba con 180
clientes. Es más cercana al MR y se caracteriza por:
 No siempre se almacenan datos en tablas, se pueden escribir objetos complejos, como
datos multimedios, en ficheros físicos que son manipulados por el SGBD aparte de los
datos tabla.
 Una columna puede tener datos simples o tipos de datos declarados por el usuario a
través de sentencias de Illustra.
 Una tabla puede heredar columnas de otra.
 Con la sentencia SELECT se pueden recuperar todas las cosas, invocar métodos y usar
su retorno como columna.
 El front-end es C++ o C, pero se ofrecen herramientas para Visual Basic y Excel.
Desde 1996 Illustra se integró al servidor Universal Informix, lo que provocó que Oracle
acelerar su paso en ésta tecnología para no quedarse atrás. Cuando todavía Oracle no había
incursionado en esto, Hewlett-Packard brindó Odapter que es una capa de software que
opera sobre un modelo relacional (la versión 7.0 de Oracle), brindando una vista OO,
aunque como Illustra está más cercana al MR. Odapter tiene más de 10 años y empezó
como un proyecto de BDOO (Iris).
Ya Oracle 8 incluye un soporte a objetos agregando una capa sobre la BD. Se permite
trabajar con datos que son videos, texto, Web y espaciales. Soporta SQL, PL/SQL y
extensiones de C++. Manipula imágenes, serie de tiempo y datos definidos por el usuario.

98
En 1992 aparece la primera versión de UniSQL desarrollado por el Dr. Won Kim que venía
trabajando desde hacía varios años en el campo de las BDOO tanto en el campo práctico
como en las investigaciones. UniSQL es un reflejo de estos esfuerzos pues, a diferencia de
otros productos, tiene más sabor OO por ,lo menos a nivel de sintaxis. Se caracteriza por:
 Lenguaje de consulta conocido como SQL/X que es un SQL reforzado que agrega
nuevas cláusulas para apoyar colecciones, herencia, métodos, tipos de datos definidos
por el usuario y otras para facilitar la manipulación de objetos.
 Hay una jerarquía para los datos multimedia.
 Se pueden definir disparadores para clases que necesiten restricciones de integridad,
pero por lo general está dentro de los métodos.
 Se usa SELECT y se puede invocar métodos excepto en la cláusula HAVING.
 Interface con C++ y Smalltalk. Además hay una herramienta gráfica (Visual Editor),
un generador de reportes (Media Master) y una herramienta para el desarrollo rápido
de prototipos de aplicaciones (Object Master).
En estos momentos compañías como IBM, Informix, Oracle, Sybase y Microsoft continúan
trabajando en el desarrollo de éste tipo de productos.

Conclusiones.

El avance de los SGBDOO tiene un largo camino por delante, sobre todo porque éste nuevo
paradigma trata de acercarnos más a la realidad y ésta no es fácil de modelar. En estos
últimos año se ha avanzado algo en la fundamentación del modelo y los productos tienen
un soporte teórico más sólido.
Ante la situación actual de debilidad de los SGBDOO existentes en el mercado frente a los
SGBDR, se impone mezclar las técnicas OO con las relacionales y las últimas versiones de
SGBD fuertes en el MR (como Oracle con su versión 8.0) comienzan a implementar éste
modelo híbrido.
Las respuestas a las preguntas iniciales serían:
 En qué se fundamenta la no compatibilidad del MR con las BDOO?.

En el propio concepto de objeto que encierra no solo datos

sino comportamiento y además la posibilidad de que los
atributos no sean atómicos.

99
 ¿Qué caracteriza al modelo híbrido?.

Para tener éxito un SGBDOR tiene que hacer lo siguiente:

 Demostrar una coexistencia eficaz con los SGBDR
porque los usuarios los dominan y tienen muchas cosas
hechas en ellos.
 Deben subsimir a los SGBDR.
 Permitir el trabajo con objetos complejos.

Referencias bibliográficas.

[Alagic, 1989] Alagic, Saud. “Object-oriented Database Programming”, 1989.

[Bertino, 1993] Bertino, E. And Martini, L. “Object-oriented Database Systems: concepts
and architectures”, 1993.
[Brooks, 1998] Brooks, P.L. “Consulting the database crystal ball”. DBMS April 1998 v11
n4 p57(4).
[Brooks, 1994] Brooks, P. “ORDBMS technology in action”. DBMS Dec 1994 v7 n13
p88(4).
[Budd, 1991] Budd, Timothy. “An introduction to object-oriented programming”.Addison-
Wesley Publishing, Co., 1991.
[Busse, 1996] Buse, T. “Database partners to craft hybrids”. InfoWorld March 18, 1996
v18 n12 p40(1).
[Chakravarthy, 1994] Chakravarthy, S.; Amuar, E.; Maugis, L. and Mishra, D. “Design of
SENTINEL: An object-oriented DBMS with Event-Based Rules”. P1(24) 1994.
[Date, 1991] Date, C. J. “An introduction to object-oriented programming”, 1991.
[Davis, 1995] Davis, J.R. “Object-relational database managers (ORDBMS)”. Distributed
computing monitor Feb 1995 v19 n2 p3(27).
[DeWitt, 1988] DeWitt, D. ; Maier, D. ; Bancilhon, F. ; Dittrich, K. ; Atkinson, M. and
Zdonik, S. “El manifiesto del sistema de base de datos orientada al objeto”. 1ra
Conferencia Internacional de BDOO y BD deductivas”, Kyoto, Japán, 1988.
[Dudman, 1996] Dudman, J. “Relative values”. Computer Weekly June 13, 1996 p46(1).
[Francett, 1995] Francett, B. “Hybrid DBMSs offer best of both words.” Software
Magazine August 1995 v15 n8 p61(5).

100
[Frank, 1995] Frank, M. “Object-relational hybrids: a look at technology and products that
blend object and relational”. DBMS July 1995 v8 n8 p46(7).
[Foley, 1996m] Foley, J. “Open the gates to object”. InformationWeek May 13m 1996
n579 p44(5).
[Foley, 1996a] Foley, J. “The race heats up”. InformationWeek August 19, 1996 n593
p14(2).
[Goddard, 1995] Goddard, D. “Object database technology: what’s ahead?”. DataBased
Advisor Nov. 1995 v13 n19 p64(5).
[Graham, 1994] Graham, I. “Object-oriented Databases”. 2da Edición. 1994.
[Hughes, 1991] Hughes, J.G. “Object-oriented Databases”. ”. Prentice Hall International
Group. 1991.
[Khoshafian, 1990] Khoshafian, S. and Abnous, R. “Object-orientation: concepts,
languages, databases, user interfaces. Jhon Wiley & Sons, Inc.1990.
[León, 1996] Leon, M. “Object database server up news”. InfoWorld Dec 9 1996 v18 n50
p14(1).
[Smith, 1995] Smith, t. “The objetct of VAR’S desires: vendors try to integrate DB,
relational DB”. Computer Reseller News, Oct 2 1995 n651 p59(1).
Stonebraker, 1991] Stonebraker, M. ; Lindsay, B. ; Gray, J. ; Carey, M. ; Brodie, M. ;
Bernstein, P. “Manifiesto del sistemas de BD de 3ra generación”. Novática, Vol. XVII
No. 91. 1991.
[Taschek, 1995] Taschek, J. “ODBMSs take on relational models”. PC Week Oct 9 1995
v12 n40 p89(2).
[Vowler, 1995] Vowler, J. “The business case for object database”. Computer Weekly
April 20, 1995 p16(1).

101
 Capítulo 5
Capacidades de
las bases de datos
orientadas a
objeto.

102
 Capítulo 5 Introducción.

Los diferentes sistemas que están apareciendo en respuesta a las demandas, no disponen
todavía de una base teórica consolidada, es decir, no hay un modelo común, por lo tanto
cada uno de ellos resuelve los problemas que se presentan de manera particular sin
considerar criterios de compatibilidad. Los SGBDR se desarrollaron sobre bases teóricas
tan sólidas como el álgebra y el cálculo relacional. En el caso de las BDOO el proceso ha
sido inverso, primero surgieron los productos.
A pesar de que la semántica que se representa en el MOO es más compleja que la reflejada
en el MR, la mayoría de los productos presentes en el mercado adaptan los algoritmos
tradicionales para el control de concurrencia, gestión de almacenamiento secundario, entre
otras capacidades de las BD. En estos momentos están apareciendo nuevos algoritmos que
explotan las potencialidades y características de éste enfoque. Sobre cómo se implementan
las capacidades de las BD en los SGBDOO trata éste capítulo.
Al finalizar debe conocer las respuestas a las siguientes preguntas:
 ¿Qué ventajas ofrece el uso del OID sobre la llave?.
 ¿Qué complejidad introduce para el control de concurrencia que se almacenen objetos?
 ¿Qué cambios presenta OQL respecto a SQL?.
 ¿Cómo se ha adaptado la definición de índices a las características del modelo?.

5.1 – Identificación de objetos.

 Estado: es representado por los valores de los atributos del objeto.

Objeto del  Comportamiento : está definido por el efecto de los métodos en el
mundo real estado de los objetos por invocación de las
correspondientes operaciones.
 Identificación : valor que identifica unívocamente al objeto.

Técnicas para identificar objetos:

 Dirección o referencia de memoria.
 Nombre que da el usuario.
 Identificar llaves (atributos) que identifiquen unívocamente a objetos de un mismo tipo.
En el enfoque OO cada objeto está identificado por un único identificador (OID- Object
Identifier). El identificador tiene una existencia independiente de los valores de los
atributos del objeto.

103
5.1.1 – Llave vs OID.

Llave
 Es un atributo o conjunto de atributos que identifican unívocamente a una tupla en el
conjunto de tuplas que conforman una relación. Dos tuplas son diferentes si sus
identificadores (llave) son diferentes aunque el resto de sus atributos tengan el mismo
valor.
 Diferencias:
Llave OID
Valores de uno o más atributos. Independiente del estado del objeto.
Requiere unicidad en la relación. Requiere unicidad en la BD.
Puede ser modificada No puede ser modificada
Tiene que ser definida por el diseñador a Son definidos a bajo nivel por el sistema.
partir del conocimiento que se tenga del
dominio de los atributos.
En ocasiones no tienen significado No es importante el valor que tenga, por
semántico porque es la sustitución de lo general no se brindan formas para
varios atributos llave. conocer su valor.

5.1.2 – Características.

Idénticamente iguales
 Dos objetos son idénticos si ellos son los mismos objetos, es decir, si tienen el mismo
identificador.

Igualdad de valores
 Dos objetos son iguales si los valores de todos sus atributos son iguales.
IDENTIDAD IGUALDAD

Igualdad superficial
 Dos objetos son iguales superficialmente, aun cuando no son idénticos, si todos sus
atributos compartidos tienen valores y referencias iguales.

104
 Físicos: contienen la dirección actual del objeto.
OID
Lógico: tiene la dirección actual que sirve para llegar a la
localización del objeto.
5.1.3 – Tipos de OIDs.

Tipos de OID:
1. Dirección:
Es la forma más simple de identificar un objeto por lo que es la forma tradicional que
usan los lenguajes de programación: dirección física. Las direcciones son generalmente
de 32 bits o menos y es la forma más eficiente para llegar a la información. Raramente
se usa por los sistemas de gestión porque ellos no permiten a un objeto ser movido o
eliminado si todas las referencias a ese objeto son encontradas o restablecidas.
2. Dirección estructurada:
Es la más usada por el modelo relacional, extensiones del relacional y el orientado a
objetos. Contiene componentes lógicos y físicos por lo tanto está formado por dos
partes:
 # segmento y # página en el disco (físico)
 # lógico del canal para poder determinar la posición dentro de la página.
Con ésta representación el objeto puede ser movido o eliminado relocalizando la
posición dentro de la página del canal.
3. Sustituto:
Un OID puramente lógico se genera usando cualquier algoritmo que garantice la
producción de identificadores únicos (por ejemplo, usar hora y fecha).
4. Sustituto tipado:
Es una variante del tipo anterior que contiene una identificación del tipo y una
identificación del objeto. La porción del objeto es generada para diferentes contadores
para cada tipo, segmentando el espacio de direcciones. Permite identificar el tipo de un
objeto con facilidad.

5.1.4 – Implementación en SGBDOO.

Producto Año Implementación

Orion 1990 Es un par (identificador de clase, modelo de identificador), donde el
1ra identificador de clase es el identificador de las clases a la cual el objeto
pertenece y el identificador del modelo es el identificador del modelo
sin la clase o sin la base de datos completa.
Cuando un mensaje es enviado a un objeto, el sistema puede

105
 Producto Año Implementación
extraer el identificador de clase del objeto del identificador de
objeto especificado, y mirar la clase para determinar si el mensaje
es válido, y entonces puede buscar el objeto y enviar el método
correspondiente.
GemStone 1987 Es implementado físicamente con un puntero. Cuando un puntero a
1ra un objeto cesa de ser referenciado, entonces cesa de existir. No
existe una función “borrar un objeto” un objeto existe mientras lo
referencien.
Los métodos y las estructuras comunes de todas las instancias de
una clase son contenidas en un objeto conocido como definidor de
objetos de una clase (CDO- Class Defining Object) Todas las
instancias de una clase tienen una referencia a su CDO como parte
del identificador.
Permite a los usuarios asignar a los objetos nombres y crea con
ellos un diccionario de símbolos de manera que cada usuario tiene
su propio diccionario. Se puede llegar a un objeto a través de su
nombre.

5.2 – Persistencia.

Manipulación de los
objetos en un SGBDOO

Temporal Persistentes

Son válidos dentro de un programa o Capacidad de conservar su valor

transacción de manera que cuando el
programa o transacción terminan, el
dato deja de existir.
(estado y comportamiento) en el espacio
y en el tiempo, es decir, conservan su
valor fuera de la transacción y
programa pudiendo utilizarse en otra
aplicación y manteniendo su valor aún
cuando la máquina se apague.

Modelo de persistencia en BDR

Todo es persistente

106
Modelos de persistencia en SGBDOO
1. Por tipo: Es una característica implícita de todas las instancias de la clase. La creación
de una clase tiene el efecto de insertar la instancia en la BD. Por tanto la creación de
una instancia automáticamente implica persistencia.
Ej : ORION Para hacer un objeto persistente solo necesita crear el objeto.
2. Por llamado explícito: La creación de una instancia no tiene el efecto de insertarla en la
BD. Una instancia creada durante la ejecución de un programa es eliminada al final del
programa sin que sea persistente. Para hacerla persistente el usuario podría darle
nombre o insertarla en una colección de objetos persistentes.
Ej : O2 Utiliza las dos formas
GemStone: Asociar un nombre externo al objeto.
3. Por clasificación : Las clases se clasifican en clases persistentes y temporales. Todas las
instancias de clases persistentes son automáticamente creadas como instancias
persistentes.
Ej : GemStone Posee clases persistentes por lo que todos los objetos definidos a partir
de ellas o de sus hijas son persistentes aún cuando no se le haya añadido un nombre.

5.3 – Transacciones.

Una transacción es una unidad de trabajo que corresponde directamente a una unidad activa
de la empresa que la BD modela. En el contexto de un sistema multiusuario de BD a los
procedimientos se les llama frecuentemente transacciones.

5.3.1 – Características.

Simples actualizaciones interactivas.

Tipos de transacciones
Programas muy grandes y complejos que involucran quizás
cientos de operaciones sobre la BD.

Propiedad de todas las transacciones:

Deben preservar la consistencia y corrección de los datos almacenados en la BD, es decir,
las operaciones realizadas por una transacción deben transformar la BD de un estado
consistente a otro. Los estados intermedios pueden ser inconsistentes.

Para garantizar la consistencia de la BD se requiere que las

transacciones de actualización se procesen enteramente o no haga
nada.

107
Las transacciones son unidades atómicas de actualización, esto es, el SGBD asegura que
todos los cambios en la transacción se hacen permanentes en la BD o no se hacen.
Cuando una transacción no se hace completamente, se debe retroceder a su estado inicial y
restaurar la BD a su estado inicial.
Una transacción solo puede tener dos posibles resultados: terminó con éxito o abortó.

SGDB Generalmente soportan transacciones cortas usando la técnica de bloqueo.

Bloqueo de escritura Bloqueo de lectura

(asegura un acceso (permite accesos
exclusivo al objeto concurrentes al
especificado) objeto especificado
siempre que no sea
una actualización)

5.3.2 – Modelo de transacciones.

Modelo de transacciones convencional

Asume que las transacciones son cortas y accesan a pocos datos, pero las aplicaciones
actuales requieren transacciones que pueden durar días o más tiempo y pueden abarcar
varias aplicaciones.

Componentes del modelo de transacciones en SGBDOO

1. Transacciones cortas: contiene una actualización atómica.

2. Sección : Está formada por varias transacciones cortas. El fallo de una de ellas afecta a
la sección.
3. Transacciones largas : Está formada por varias secciones. Puede durar horas y días
(Figura 4.5).

108
 Transacción larga
Sección . . . Sección
Transacción Transacción Transacción Transacción
corta corta corta corta

Figura 4.5 Transacciones largas.

4. Transacciones anidadas: Cada transacción consiste en una subtransacción atómica.
Cada subtransacción es una transacción anidada. Esto significa que cada transacción
puede tener asociada transacciones hijas. Esto es válido en objetos complejos.
Soportadas por Ontos y no permitidas por GemStone, Orion y O2.
Para poder garantizar estos tipos de transacciones, el sistema de gestión debe prever
tratamiento para diferentes cosas. Por ejemplo,
 Finalizó con éxito una transacción
 Abortó una transacción que era corta
 Abortó una transacción corta que estaba dentro de una sección
 Chequear los objetos para lectura o escritura en transacciones largas.
 ...
Los lenguajes de las BD deben proporcionar primitivas para identificar las secciones de
código que incluyen las transacciones. Típicamente se soportan las siguientes constructores
(Figura 4.6):
 Begin transaction
 End transaction
 Abort transaction

Ej : Begin transaction
Incrementa a José el salario un 10%
Promueve a José como J’dpto
End transaction
Figura 4.6 Segmento de código de una transacción.
En GemStone el sistema recibe mensajes que le indican el resultado de la transacción :
System commitTransaction
System abortTransaction

109
5.4 – Control de concurrencia.

Los mecanismos de control de concurrencia tradicionales imponen la serialización del

orden de ejecución.
Ejecución serial: Las transacciones son ejecutadas secuencialmente sin que interfieran unas
en otras porque en un instante de tiempo solo se está ejecutando una
(Figura 4.7).

Transacción 1
Ejecución debe estar
Transacción 2 Base de datos sincronizada, es decir, los
efectos de la transacción
... compartida sobre la BD debe ser el que
se obtendría si ninguna otra
transacción estu- viera
Transacción n ejecutando
(se ejecutan concurrentemente
concurrentemente)

Figura 4.7 Procesamiento serial de transacciones.

Si la secuencia de operaciones de un conjunto de transacciones ejecutando

concurrentemente es tal que:
“Los efectos de varias transacciones ejecutando
concurrentemente es el mismo como si fueran ejecutadas
serialmente en algún orden”.

Se dice que la secuencia es serializable

5.4.1 – Técnicas de procesamiento tradicional aplicables a BDOO.

a) Algoritmos pesimistas o de cerrojos (Locking).

Permiten a múltiples usuarios acceder al mismo objeto en la misma BD y al mismo
tiempo de una manera cooperativa, controlada y previsible.
Tipos de jerarquías de cerrojos permitidos en BDOO

110
 a) Granularidad de cerrojos
 Grado de granularidad: Tamaño de los items que se pueden cerrar en un sistema
de BD.
 Objeto: Es la elección obvia para un item cerrable.
 Cuando una transacción desea el acceso a la mayoría de las instancias de una
clase Se debe asignar un cerrojo del mismo tipo sobre cada instancia de la
clase.
 Por los conceptos de herencia, y en particular el de generalización, se
recomienda usar un protocolo de granularidad múltiple que implique que un
cerrojo de un tipo en un nodo hijo se traduzca en la asignación de un tipo de
cerrojo al nodo padre.
 Tipos de cerrojo:
Da acceso de lectura a un objeto y previene que cualquier otra
Lectura transacción actualice el objeto. Es con frecuencia llamado lectura
compartida ya que cualquier transacción puede poseer un cerrojo
de lectura sobre un objeto al mismo tiempo.
Escritura Da acceso de lectura/escritura a un objeto y, mientras está activo,
previene a cualquier otra transacción que trate de accesar el objeto.
Es con frecuencia llamado escritura exclusiva ya que da a una
transacción acceso exclusivo a un objeto mientras el cerrojo está
activo.

b) Cerrojo para entrelazado de clases

Se basa en dos protocolos:
 Protocolo de granularidad múltiple para los hijos o subclases.
 Se cierran las clases y sus superclases con cerrojos de intención lo que
permitiría a otras transacciones poder trabajar con las instancias de estas
superclases si en ese momento no están cerradas de manera exclusiva.
Soportada por ORION.
c) Cerrojo para objetos complejos
Los protocolos de granularidad de cerrojos en objetos complejos requieren
de muchos cierres  se define un protocolo que trata de prevenir que una
transacción actualice o lea un objeto componente de un objeto compuesto
mientras otra transacción está leyendo o actualizando el objeto entero
compuesto.
2. Algoritmos optimistas.
 Se usa cuando es baja la competencia por el acceso exclusivo a objetos.
 A las aplicaciones se les permite acceder libremente a los objetos.

111
  Cuando se realiza una actualización se crean copias locales de los objetos y en ellos
es donde se hacen los cambios.
 Antes de actualizar la BD se comprueba si han ocurrido modificaciones con
respecto al estado inicial, en tal caso se reinicia la transacción. En caso contrario se
llevan los cambios a la BD.
3. Marcaje de tiempo (Time stampig).
 A cada transacción se le marca un identificador, que puede ser :
 el tiempo
 el lugar que ocupa en la serialización de las transacciones ejecutando
concurrentemente.
 Las operaciones de lectura/escritura se realizan en el orden del “Timestamp”.
Lista serial  orden cronológico del comienzo de cada transacción.

Ejemplo:

GEMSTONE Control de concurrencia híbrido

Optimista sobre los objetos que es poco Pesimista sobre objetos que
probable que produzcan conflictos, es probable que produzca
evitando así el gasto de cerrojos. conflictos.

5.4.2 – Nuevos requerimientos.

Operaciones con los datos

lectura
Transacciones
Convencionales

Se actualizan
escritura
Objetos Métodos

Por lo tanto, existen más accesos concurrentes.

Solución: Desarrollo de mecanismos para el control de concurrencia que no son los

tradicionales porque se basan en:
 Semántica de los datos y operaciones.
 No es posible la serialización.

112
  Trabajos muy recientes que aún no
Situación hasta
tienen el nivel de acuerdo a la teoría que
1994
existe en el procesamiento tradicional de
transacciones.
 Ninguno de los mecanismos propuestos
ha sido implementado.

5.5 – Versiones.

Aplicaciones

CAD
Requieren tener conocimiento de
CASE la evolución del estado de los
objetos, es decir, necesitan de
CAM todas o parte de la versiones que
de los objetos han existido.
Automatización
de oficinas

...
Los SGBDOO requieren un controlador
(otras para las cuales
de versiones.
se hizo necesario el
MOO)

Funciones del controlador de versiones

 Crear/destruir versiones de objetos.

 Destruir/archivar versiones viejas de un objeto cuando no se necesite.
 Recuperar sucesores/antecesores de una versión.

Versiones pueden ser Creadas por un usuario o

programa declarado al objeto
versionable.

Se crean automáticamente
cuando el objeto se modifique.
Son implementadas en: Orion
Iris
Ontos
Objectivity/DB

113
5.6 – Lenguaje de consulta.

Uno de los rasgos Proporcionan un lenguaje para recuperar,

más importantes
es manipular y definir datos.
de los SGBD

En los SGBDR a estos lenguajes se les llama LENGUAJE DE CONSULTA.

Los SGBDOO brindan un lenguaje que incluye juntos los lenguajes de consulta
(declarativo) y de programación (procedural), y otras capacidades reduciendo los errores de
impedancia.
Los dos grupos que están desarrollando normas en el campo de los SGBD, están trabajando
hacía la convergencia de un lenguaje de consulta objeto. ODMG desarrolló ODMG-93 que
es el estándar para los SGBDOO y utiliza como lenguaje de programación OO a C++ y
Smalltalk, como lenguaje de consulta OQL y como lenguaje de definición de datos a ODL.
ANSI lleva varios años trabajando en la versión SQL3, lo nuevo en cuanto al tratamiento de
objetos se refiere a:
 Identificación única de los objetos y referenciarlos usando éste identificador.
 Encapsulamiento de objetos y valores complejos.
 Generalización/especialización de tipos y tablas.
SQL3 no toma en cuenta lo definido en ODMG. Este estándar incluye nuevos tipos de
datos, nuevos predicados, consultas recursivas, disparadores y utilización de objetos dentro
de la consulta. Es decir, responde a las exigencias de los gestores de 3ra generación.

5.6.1 Características.

1. Cada SGBDOO proporciona diferentes tipos de lenguajes de consulta.

 No tienen lenguaje de consulta, es necario escribir programas para navegar por la
BD.
 Las consultas son usadas para seleccionar objetos que satisfagan determinadas
restricciones a partir de una colección de objetos.
Ej: GemStone, ObjectStore, Ontos y Orion.
 Lenguajes de consulta con el mismo poder de SQL.
 Lenguajes de consulta objeto (OQL-Object Query Language) que pueden producir
cualquier tipo de resultado.
Ej: O2

114
2. El encapsulamiento de los objetos es violado por algunos sistemas que permiten que los
lenguajes de consulta tengan accesos a todos los atributos de un objeto.
3. Inclusión de nuevas operaciones al lenguaje como cierres transitivos, recursión y reglas.
4. De manera general pueden ser aplicados los algoritmos usados para el procesamiento de
consultas en el modelo relacional sin embargo las consultas en el modelo objeto pueden
ser más complejas porque el modelo de datos es más rico. Por ejemplo, la introducción
de una jerarquía de tipos requiere que el procesamiento de la consulta busque por ella
para dar respuesta a una consulta.

5.6.2 Lenguaje de definición de objetos.

El estándar ODMG-93 (Object Database Management Group).

 Lenguaje de definición de objetos (Object Definition Language – ODL).

Define los tipos de objetos para que puedan ser implementados en una variedad de
lenguajes de programación.
 Plantilla para definir clases.
INTERFACE <nombre de la clase> [:<nombre de superclase 1[,...]>] {
EXTENT
KEYS <nombre del atributo llave 1 [,...]>;

ATTRIBUTE <tipo> <nombre>,

. Atributos
. simples
.

RELATIONSHIP <nombre con la <nombre de

que se relaciona> la relación>
INVERSE <clase con la que <nombre que se le da la relación
se relaciona> en la clase con que se relaciona>

Atributos El atributo es
complejos un objeto de
una clase dada.

115
 RELATIONSHIP<agrupamiento><clase con la que <nombre de la
. LIST se relaciona> relación>
. SET
INVERSE<clase con la que :: <nombre que se le da a la relación en
relación> la clase con la que se relaciona

El atributo es
Atributos un grupo de
complejos objetos de una
. clase dada.
.
.

<nombre ([IN <clase con la que se comparte [RAISES(<lista de condiciones

del método> la responsabilidad>],[...]) que pueden existir
para que no se
ejecute>)];
.
.
.
}

Ejemplo:
Curso
Nombre
Número
Prerrequisitos
Secciones Sección
INTERFACE Curso{
Número
EXTENT Cursos;
KEYS Nombre, Número;
ATTRIBUTE string Nombre;
ATTRIBUTE string Número;
RELATIONSHIP LISP <sección> tiene_secciones
INVERSE sección::es_sección_de;
RELATIONSHIP SET <curso> tiene_prerrequisitos
INVERSE curso::es_prerrequisitos_para;
RELATIONSHIP SET <curso> es_prerrequisito_para
INVERSE curso::tiene_prerrequisitos;
Ofrece (IN Semestre) RAISES (ya_ofrecido);
Baja (IN Semestre) RAISES (no_ofrecido);
}
INTERFACE Sección{

116
 EXTENT Secciones;
KEYS Número;
ATTRIBUTE string Número;
RELATIONSHIP curso es_sección_de
INVERSE curso::tiene_secciones;
}

5.6.3 – OQL.

Lenguaje de consulta objeto (OQL):Es un lenguaje de consulta declarativo cuya sintaxis

está basada en SQL con la particularidad de que una consulta puede enviar mensajes a
objetos (es decir, puede activar los métodos de los objetos).
Ejemplos:
Pregunta Respuesta Consulta
Seleccionar los Retorna un literal SELECT DISTINCT x.empleo
empleos de las que es del tipo FROM x in Personas
personas que se Set<integer> WHERE x.nombre=”Juan“
llaman Juan
(DISTINCT- elimina los duplicados)
Seleccionar los Retorna una SELECT DISTINCT
empleos y sexos estructura (del tipo STRUCT
de las personas tabla) que es un (a:x.empleo,s:x.edad)
que se llaman Juan literal del tipo FROM x IN personas
set<estruct> WHERE x.nombre=”Juan“

Seleccionar el Retorna una SELECT DISTINCT

nombre de los estructura que es un STRUCT(
empleados y los literal del tipo nombre:x.nombre,
subordinados de set<struct( sub(SELECT y
cada uno, que nombre:string, FROM y in subordinados
ganan salarios sub:bag WHERE y.salario-min))
mínimos <empleado>)> FROM x IN empleados

y.salario-min es la invocación a un método

que indica si ese subordinado tienen salario
mínimo.

En el caso de SQL3 se requiere especificar el objeto al que se hace referencia pues estos se
ven desde la perspectiva de SQL. La diferencia de una consulta en SQL3 y OQL puede ser
muy sutil, pero existe.

117
Ej.:

SQL3 OQL
SELECT * FROM persona WHERE SELECT * FROM persona WHERE
persona.nombre = “Juan” nombre = “Juan”

5.7 – Gestión de almacenamiento secundario.

SGBD1 = SGBD2  La decisión se basa frecuentemente en su gestión de

almacenamiento secundario.

¿CUÁN RÁPIDO RESPONDE A CONSULTAS COMPLEJAS?

¿CUÁN RÁPIDO SE PUEDE ACTUALIZAR LA BD?

¿CUÁNTOS USUARIOS PUEDEN ACCEDER CONCURRENTEMENTE A LA

BD?

Los manejadores de BD establecen 4 estrategias para mejorar la gestión del sistema:

a) Índices..
b) Almacenamiento.
c) Optimización de consultas.
d) Agrupamiento.

5.7.1 – Indices.

Aspectos a tener en cuenta por las técnicas de indexación en SGBDOO

 Herencia: una consulta puede aplicarse a la clase o a la clase y todas las subclases.
 Métodos: los métodos pueden ser usados en consultas para devolver un objeto, un valor
lógico o cualquier otra cosa.
 Predicados anidados: los objetos pueden ser complejos por lo que una consulta puede
invocar a métodos de un objeto que lo forma.

Formas válidas para los SGBDOO

1) Grafo de agregación:
 Se definen caminos que indican el camino a recorrer en la búsqueda de acuerdo a
los objetos que lo forman.

118
 Ejemplo:
Proyecto Compañía

Nombre Nombre
Compañía Dirección
Fecha Teléfono
Inicio Fax
Fecha Fin Divisiones
Tareas Persona J’compañía
J’ proyecto
Nombre División
Edad
Ciudad
Profesión
J’división
Tarea

Nombre
J’tÁrea

Caminos:
 Proyecto.Compañía.Divisiones.J’división.Nombre
 Proyecto.Tareas.Nombre
 Proyecto.J’proyecto.Nombre
...
 Estrategias de búsquedas:
 Backward: Se conoce el valor del objeto que está al final en el camino.
Ej.: Seleccionar todos los proyectos que la compañía, para la cual
se desarrolla, tiene divisiones en New York.

 Forward: Se conoce el valor del objeto que está al inicio del camino.
Ej.: Determinar las ciudades donde hay divisiones de la Compañía
para la cual se desarrolla el proyecto “ tiempo real en la
industria azucarera”.

2) H-Tree

 Basado en los árboles B+ (árboles equilibrados)

Un árbol B+ de orden d cumple las siguientes condiciones:

119
  Cada nodo tiene como máximo 2d entradas y , excepto la raíz, por lo menos d
entradas.
 La raíz o no tiene hijos o tiene por lo menos dos.
 Todas las hojas aparecen al mismo nivel.
 Es una estructura de datos para almacenar varias organizaciones de índices
existentes.

Llave del elemento

D=2 50
20 30 70 100

3 15 34 37 57 61 66 101 102

21 25 28 74 78 87 96

 Combinando con la técnica de los caminos, además de la llave se tendrá el número

de caminos asociados con la llave y la lista de caminos.
3) Indices heredables
 Se mantiene el índice para el atributo común a todas las clases del grafo de la jerarquía.

El atributo común es el
Publicación ISSN

Revista Libro

 Puede combinarse con Arbol B+ de manera que el nodo hoja además de la llave,
contiene una entrada para cada clase que tiene las instancias con el valor de la llave del
atributo índice.
4) Definir índices sobre la base del comportamiento de los objetos.

120
 Una idea: Almacenan el resultado de la ejecución de los métodos en un índice en otra
estructura, lo que garantiza que una consulta que requiera invocar a un
método, cuyo resultado ya haya sido obtenido, puede ser evaluada
eficientemente.

5.7.2 – Almacenamiento.

Tiene que soportar eficientemente:

 Objetos con atributos atómicos y complejos.
 Objetos que pueden ser en un momento atómicos y en otros complejos.
 Objetos con atributos variables.
 Objetos con atributos que necesitan manipulación de multimedia.
 Hay que almacenar el código asociado a los métodos teniendo en cuenta la herencia.

Formas para almacenar los procedimientos definidos:

1. Usando la programación convencional, en ficheros.

2. Almacenados dentro de la BD. Es usada por Orion, GemStone y O2.

Formas de almacenamiento dentro de la BD:

1. Directamente: Los objetos son almacenados de la misma forma que se definen en el

esquema conceptual, es decir, los objetos de una misma clase son almacenados en un
mismo fichero por lo que un registro se corresponde con la instancia de la clase.
2. Normalizado: Los objetos son descompuestos en componentes atómicos y son
almacenados en diferentes ficheros. La relación entre varios componentes es a través de
OID.
3. Combinación: Es una solución intermedia. Los objetos complejos son descompuestos,
pero los documentos son agrupados juntos de acuerdo a la forma de acceso y los
componentes que son accesados juntos son almacenados en el mismo fichero.

5.7.3 Optimización de consultas.

En los SGBDR el sistema de gestión se encarga de optimizar las consultas que se realizan
buscando otra forma de expresarla que sea más óptima basándose en el álgebra relacional.
Esencia de la optimización de consultas: encontrar un plan de ejecución que minimice la
función de costo.

121
Involucra a los niveles físicos y lógicos
Nivel lógico: usa las propiedades semánticas del lenguaje para encontrar una expresión
equivalente.
Nivel físico: busca el mejor algoritmo para evaluar la expresión.
 Necesidad de porque
 Los objetos son tuplas.
nuevas técnicas
 Un objeto puede referenciar
recursivamente a otros objetos.
 Las consultas pueden incluir
llamadas a métodos

Ejemplo: ORION
Se crea un grafo en el que se representa la consulta y después se optimiza utilizando las
operaciones del álgebra en la que se puede dividir la consulta en varias consultas que se van
agrupando de acuerdo a los cluster definidos. Al final se evalúa en cada cluster lo que se
debe cumplir.

Fijarse que todo lo hecho está fundamentado en

operaciones del álgebra.

5.7.4 Agrupamiento.

Es el proceso de agrupar los objetos de forma tal que el acceso sea rápido.
Un segmento es la unidad de almacenamiento para el agrupamiento. Es uno grupo de
páginas físicas de tamaño variable que contiene un grupo de objetos relacionados.
 Opciones:
 1ra idea: los objetos frecuentemente usados estén físicamente en una misma página.
 Un objeto por segmento: apropiado para objetos grandes.
 Almacenar un objeto con todas sus subclases: es apropiado para un grupo de objetos
interrelacionados que son casi siempre accesados juntos.
 Almacenar todas las instancias de un mismo tipo juntas: es apropiado cuando las
consultas requieren investigar todos los objetos de un mismo tipo.

 Agrupar teniendo en cuenta el valor de cierta propiedad: en dependencia del valor

de una propiedad que se define se agrupan los objetos, por ejemplo, con propiedad
igual a rojo o todos los objetos donde la propiedad está en el rango de 1 a 10.

122
5.8 Recuperación.

Un SGBD debe proporcionar herramientas de software para implementar la recuperación

en caso de que se produzcan estados inconsistentes en la Bases de Datos.
Fuentes que provocan estas inconsistencias:
1. Fallo de una transacción de actualización antes de que se completaran los cambios,
pero después de que se hicieron algunos.
2. Fallo del sistema operativo o del SGBD que interrumpa todas o algunas de las
transacciones.
3. Fallo de alimentación eléctrica.
4. Defectuosa corrección de la BD por transacciones defectuosas.

Soluciones:
1. Copias de seguridad.
2. Diario: fichero con la historia de todas las transacciones que hayan actualizado la BD
desde que se hizo la última copia de seguridad.
3. Recuperación en esquemas optimistas:
 En un control de concurrencia optimista OO, cada transacción toma una copia
sombra de la tabla de objetos compartida.
 Todas las actualizaciones se realizan sobre la copia sombra y sus cambios no son
visibles a otras transacciones.
4. Paginación con sombra (shadow paging):
Método
 Se tiene una tabla de páginas, que se pueden copiar en la memoria principal, donde la
entrada i apunta a la página i de la BD.
 Cuando una transacción comienza su ejecución una copia de la tabla de páginas actual
se copia en una tabla de páginas sombra.
 Tabla de páginas sombra: representa el estado (consistente) de la BD antes de la
ejecución de la transacción y, por lo tanto, define un estado al cual la BD representa si
la transacción falla.
 La tabla de páginas sombra se salva en disco y la transacción no lo modifica, todas las
actualizaciones de la transacción se hacen vía la tabla de páginas actual.
Extensión en BDOO: Se reemplazan las tablas de página por tablas de objeto. Cada entrada
relaciona al identificador del objeto con su posición en el disco.

123
5.9 Evolución del esquema.

Taxonomía de cambios en el esquema:

1- Cambiar los componentes de un tipo
1.1- Cambio a los atributos.
1.1.1- Adicionar un nuevo atributo.
1.1.2- Baja a un atributo
1.1.3- Cambiar el nombre de un atributo
1.1.4- Cambiar el tipo de un atributo
1.1.5- Heredar un atributo diferente definido por 2.
1.2- Cambio de los métodos.
1.2.1- Adicionar un nuevo método.
1.2.2- Baja a un método.
1.2.3- Cambiar el nombre de un método.
1.2.4- Cambiar la implementación de un método.
1.2.5- Heredar un método diferente definido por 2.
2- Cambiar el grafo/árbol de jerarquía.
2.1- Adicionar una nueva relación supertipo-subtipo.
2.2- Eliminar una relación supertipo-subtipo.
2.3- Cambiar el orden en la jerarquía (sólo válido para sistemas que soporten herencia
múltiple).
3- Cambiar los tipos.
3.1 Adicionar un nuevo tipo.
3.2 Eliminar un tipo existente.
3.3 Cambia el nombre de un tipo.
Una de las implicaciones principales del cambio en los esquemas es que pueden afectar a
los programas por eso es importante el encapsulamiento.
ORION tiene un sofisticado tratamiento de la evolución del esquema permitiendo todos los
cambios que se incluyen en la taxonomía.

Conclusiones.

La tecnología de las BD ha evolucionado hasta brindar una modelo mucho más rico
semánticamente tal como se aprecia en la tabla de la figura 4.8, pero todavía queda un largo
camino en el campo de la investigación en la búsqueda de nuevos algoritmos que exploten
las potencialidades de éste modelo.

124
 FICHERO JERARQUICO/ RELACIONAL OO
RED
MODELO Ninguno Árbol/ gráfico Tablas de dos Tipo abstracto de
DE dimensiones datos.
DATOS
MODELO - Búsqueda Algebra relacional Activación de
BÁSICO navegacional objetos por
DE servicios.
ACCESO
CONTRI- - Capacidad. Modelo Abstracción
BUCIÓN Básica de acceso, simplificado de los natural de los
DML, DDL, datos. datos.
DQL, integridad Interdependencia Operaciones
de datos. Mayor capacidad complejas.
semántica Datos y código en
(relaciones m:n, BD.
agregaciones)
Figura 4.8 Evolución de la tecnología de BD.
Las respuestas a la preguntas formuladas en la introducción serían:
 Qué ventajas ofrece el uso del OID sobre la llave?.

 No siempre es posible encontrar un conjunto de atributos

que identifiquen unívocamente a un objeto.
 El gestor tiene que implementar mecanismos de protección
a una llave que garantice su unicidad y la no
modificabilidad. Lamentablemente no todos los gestores lo
garantizan lo que implica un esfuerzo adicional del
programador si quiere que su BD esté consistente y
correcta.
 La llave depende del valor de los atributos en cambio el
OID tienen una existencia independiente que controla el
gestor

125
 ¿Qué complejidad introduce para el control de concurrencia que se almacenen objetos?

Los algoritmos tradicionales de control de concurrencia

necesitan adaptarse porque un objeto puede tener referencia a
otros objetos, lo que complejiza la protección que cualquiera de
los algorimos pueda dar cuando se intente acceder a un objeto
con estas características.

 ¿Qué cambios presenta OQL respecto a SQL estándar?.

Una consulta puede enviar un mensaje a un objeto.

 ¿Cómo se ha adaptado la definición de índices a las características del modelo?.

 Tomando en cuenta la composición de los objetos al

establecer caminos de acuerdo a los objetos que contiene un
objeto agregado.
 Usando como base los árboles B+, que es la técnica por
excelencia que usan los gestores relacionales, se asocia a
cada entrada los caminos que de ella se derivan de acuerdo al
grafo de agregación.
 Indexando por el atributo común de una jerarquía.
 Indizar resultados de la ejecución de un método para
minimizar el tiempo de una consulta que requiere la
ejecución de un método.

Referencias bibliográficas.

[Barry, 1996] Barry, D.K. “Terms of endearment”. Database Programming & Design Nov
1996 V9 n11 p50(7).
[Bertino, 1993] Bertino, E. and Martino, L. “Object-oriented Database Systems”. Addison-
Wesley Publishing, Co. 1993.
[Cattel, 1994] Cattel, R.G.G. “Object Data Management”. Addison- Wesley Publishing,
Co. 1994.
[Cauvet, 1992] Cauvet, C. and Rolland, C. “Object-oriented conceptual modelling”.
CISMOD 92, p1(34). India. 1992.

126
[Frank, 1995] Frank, M. “Object-relational hybrids: a look at technology and products that
blend object and relational”. DBMS July 1995 v8 n8 p46(7).
[GemStone] “GemStone Product Reference”.
[Hughes , 1991] Hughes, J.G. “Object-oriented databases”. Prentice Hall International
Group. 1991.
[Knoshafian, 1990] Knoshafian, S. and Abnous, R. “Object orientation: concepts,
languages, databases, user interfaces”. Jhon Wiley & Sons, Inc. 1990.
[Kim, 1990] Kim, W. “Object-oriented datbase: definition and research directions”. IEEE
transaction on knowledghe and data Engineering. 1990.
[Loomis,Loomis, M.E.S. “More on transactions”. JOOP January, p63(5). 1991.
[UPM, 1995] Universidad Politécnica de Madrid. Tesis para optar por el título de
Licenciado en Informática: “Control de concurrencia, recuperación y versiones en
SGBDOO”. 1995.
[Wilkinson , 1990] Wilkinson, K.; Tsur, S.; Naqui, S. and Zaniolo, C. “The story of O2”.
IEEE Transaction on knowledge and data engineering. Vol. 2, No. 1 March. p63 (13).
1990.

127
 Capítulo 6
Estado del arte en
el diseño de la BD.

128
 Capítulo 6 Introducción.
Las herramientas de especificación de requerimientos se componen de un conjunto de
conceptos (los del enfoque), actividades (lo que hay que hacer), técnicas (que son
aplicadas) y formas de representación (herramientas para plasmar el conocimiento). El ciclo
de vida clásico en este análisis sigue un desarrollo secuencial (Figura 6.1), en cambio un
análisis orientado a objetos se puede decir que es un proceso iterativo e incremental. Esta
forma de estudiar un problema se corresponde con la realidad pues el conocimiento de un
sistema aumenta conforme se progresa en el proyecto.

Figura 6.1 Desarrollo secuencial.

Además los paradigmas clásicos estructurados usan una abstracción funcional
(procedimental) por un lado, u una de datos por otro.

 Diseñar la BD a partir de un modelo OO no puede hacerse aplicando las

metodologías tradicionales porque:
 No se trabaja con los mismos conceptos, por lo tanto, se requieren de
nuevos métodos y herramientas de desarrollo.
 Para construir sistemas complejos, el desarrollador debe abstraer distintas
vistas del sistema, construir modelos utilizando notaciones precisas,
verificar que los modelos satisfagan requerimientos del sistema y añadir,
gradualmente, detalles para transformar los modelos en una
implementación. Los métodos y herramientas clásicos presentan
limitaciones para lograr esto.
En éste capítulo se describe el estado del arete en el campo de la obtención de un modelo de
la base de datos a partir de especificaciones orientadas a objeto, teniendo en cuenta la
característica de los gestores presentes en el mercado. Al finalizar debe ser capaz de
responder a las siguientes preguntas:
 ¿Qué es el proceso de serialización?.

129
 ¿Cómo se ven los objetos desde una perspectiva estática?.
 ¿Cuáles son las fórmulas dinámicas que se definen en la modelación dinámica?

6.1 – Modelo de referencia OO.

Un sistema construido con métodos orientados a objetos es uno cuyos componentes son
“paquetes” que encapsulan estática (datos) y dinámica (funciones), que pueden heredar
atributos y comportamiento de otros componentes y cuyos componentes se comunican a
través de mensajes. Un modelo de referencia orientado a objetos para especificar métodos
de análisis y diseño tiene como objetivos:
 Obtener un modelo básico que recoja las características comunes en los métodos OO.
 Disponer de criterios para componer métodos de análisis y diseño OO.
El desarrollo OO es un proceso conceptual independiente de todo lenguaje de programación
hasta las etapas finales. Es, fundamentalmente, una nueva forma de pensar y no una técnica
de programación.

6.1.1 – Comparación entre metodologías funcionales y OO.

OO
Se centra en especificar objetos
procedentes del dominio de la
aplicación con las responsabilidades
que tienen dada su funcionalidad.
Soporta mejor las evoluciones de los
requerimientos porque está basado en
el entorno subyacente del dominio de
la aplicación es si más que en lo
requisitos funcionales de un único
problema.
Se trabaja con una jerarquía de clases.
Pone énfasis en la estructura de
objetos y hace menor hincapié en la
estructura de procedimientos.
Impulsa a compartir a distintos niveles
proporcionando herramientas como la
abstracción, el encapsulamiento y la
herencia que permiten construir
bibliotecas de componentes
reutilizables.
Funcional
Se hace mayor hincapié en especificar y
descomponer la funcionalidad del sistema.
Este enfoque puede ser la forma más
directa de implementar, pero resulta frágil
pues si cambian los requerimientos del
sistema, puede provocarse una importante
reestructuración.
Se trabaja con una jerarquía de estructuras
de datos y otra de procedimientos.
Se trata en el diseño de obtener módulos
reutilizables, pero brinda pocas
herramientas para lograrlo.

130
6.1.2 – Modelación de objetos.

En la modelación se abordan tres perspectivas: estática (clase, atributos y relaciones),

dinámica (operación o mensaje, métodos, evento, estado , transacción y petición o envío de
mensajes) y estática/dinámica (restricciones de integridad).
Evento.
 Son los responsables del cambio de estado de un objeto.
 Es un hecho que genera un mensaje hacía uno o varios objetos de los que espera una
respuesta.
 Es una transmisión de información de dirección única entre un objeto y otro. No es
como una llamada a subrutina que proporciona un valor.
 Puede ser:
 Privado: aparece solo en una clase y participa en la traza de objetos de solo esa
clase, por ejemplo, aceptar propuesta.
 Compartidos: aparece en varias clases, puede formar parte de las trazas de todas las
clases en las cuales es declarado, por ejemplo, prestar un libro.
 Puede estar asociado a precondiciones (condiciones que deben cumplirse en el
momento que ocurre) y postcondiciones (condiciones que deben cumplirse una vez
ocurra).
Estado.
 Es una colección de características que definen el estatus de un objeto, los estados
representan los nodos de la red.
 Es una abstracción de los valores de los atributos y de los enlaces de un objeto. Los
conjuntos de valores se agrupan dentro de un estado de acuerdo con aquellas
propiedades que afectan al comportamiento microscópico del objeto.
 Corresponde al intervalo entre dos sucesos recibidos por un objeto de forma
consecutiva.
 Suelen estar asociados con que el valor de un objeto satisfaga alguna condición. En el
caso más sencillo, todo valor enumerado de un atributo, define un estado distinto.
 Al definir estados, se ignoran aquellos atributos que no afectan al comportamiento del
objeto, y se agrupan en un único estado todas las combinaciones de valores de atributos
y de enlaces que tienen una misma respuesta a los eventos.
Transición.
 Cambio de estado inducido por la ocurrencia de un evento.

131
 Una transición con protección se dispara cuando se produce el evento, pero solo si la
condición de protección (Precondición- es una función booleana lógica que tienen a
objetos como valores) es verdadera.
 Puede ser:
 Simple: está asociada a un único evento y se dispara cuando éste ocurra.
 Compleja: están asociadas a un conjunto de eventos y estos eventos pueden unirse
usando and, or o not.
Envío de mensajes.
 Cuando un mensaje es enviado , el método asociado debe ser ejecutado.
 El método correspondiente a un mensaje puede ser conocido en tiempo de
compilación o en tiempo de ejecución (enlace tardío).
Restricciones de integridad.
 Representan condiciones que deben ser satisfechas.
 Reglas que especifican restricciones y requerimientos que afectan tanto a la
estructura como al comportamiento de los objetos de una clase.

6.1.3 – Modelación por fases.

Fase Objetivo Características

Análisis Definición detallada del  Desprovista de
problema del mundo real a consideraciones de diseño.
desarrollar.  Desarrollo incremental bajo
una noción común de objetos.
 Proximidad a los mecanismos
cognitivos humanos.
Diseño Refinar, extender y  Relativa a la solución del
reorganizar las clases sistema de información.
resultantes de la fases de  Genera especificación
análisis. rigurosa de todos los aspectos
de las clases.
 Como resultado, todas las
operaciones y métodos y
estados disponibles, deben ser
completamente especificadas.
Construcción e Implementar  La implementación está en
implementación correctamente los objetos. función del tipo de servidor de
base de datos y en función del
entorno de desarrollo.


Definido por el Dr. Oscar Pastor, profesor titular de la Universidad Politécnica de Madrid

132
 El diseño de la base de datos cae en la fase de diseño. El problema cuando se trabaja con
el modelo orientado a objetos es decidir el tipo de servidor de base de datos a usar.

6.2 - Modelo de persistencia.

La persistencia es la capacidad de almacenar un objeto y sus estado previo de manera que

trascienda al espacio y el tiempo. Para garantizarla los SGBDR disponen de cuatro
operaciones: creación, recuperación, actualización y eliminación (CRAE).
Según Jesse Liberty, todo modelo o mecanismo de persistencia (término usada por éste
autor) debe cumplir las siguientes reglas:
 Cada elemento de un objeto (atributo, asociación, jerarquía) tiene que ser proyectado
en un elemento de almacenamiento persistente.
 El código fuente de una aplicación incluye las operaciones CRAE. Este código tiene
que ser escrito y probado para un mecanismo persistente en particular.
 El formato de almacenamiento persistente tiene que ser mantenido en “synch” con la
definición de los objetos que son necesarios almacenar. Durante el desarrollo de un
proceso, los objetos pueden cambiar (sus atributos, relaciones, etc.) y la definición
persistente tiene que corresponderse con estos cambios.
Los SGBDR por si solos no pueden determinar cuáles elementos son salvados y cuáles
recuperados, esto es tarea de las aplicaciones. Se dice que un SGBDOO debe lograr la
transparencia en cuanto a salva y restaura, y cuando un objeto está en memoria o solo
almacenado. Los gestores híbridos no han logrado éste encapsulamiento por lo que
requieren de un mecanismo para tratar la persistencia.
Un diseño de la BD a partir de un análisis OO implicará tomar la decisión de la forma en
que se almacenarán los datos, lo que implica en estos momentos decidir por la persistencia
a un fichero, aún SGBDOO o en BDR con o sin capacidades de la orientación a objetos. La
transformación de los objetos tiene que tomar en cuenta que un objeto no solo engloba
propiedades sino que también incluye comportamiento.

6.2.1 - Proceso de serialización

En el término de serialización Liberty se refiere al proceso de tomar un objeto y convertir

su información en una forma que pueda ser almacenada y transportada. Esta es la idea que
siguen las aproximaciones para sistemas híbridos que se describen en el apartado 6.3.5.
Para estos casos la idea es convertir un objeto en una o varias entradas a una o varias tablas.
Este autor propone encapsular éste proceso definiendo una clase “serialización” que en la
interfaz tenga los métodos ReadFrom y WriteTo con parámetros de lo que se lee o salva.

“Begining Object-Oriented Analysis and Design with C++”. Wrox Pres, 1998, Canadá.

133
Estos parámetros son de tipos de clases Writer y Reader con métodos particulares para leer
diferentes tipos de datos.
El algoritmo de serialización en un objeto, de forma general, podría ser:
1. Preguntar si sus padres en la jerarquía ya han sido serializados. En caso negativo,
serializarlos.
2. Serializar los datos miembros primitivos.
3. Serializar las referencias a otros objetos.
4. Preguntar si los que lo componen están serializados. En caso negativo, serializarlos.
Los pasos 2 y 3 dependen de las capacidades como gestor relacional que tenga el sistema y
las potencialidades OO que incluya. Tomando como base una metodología propia OO
desarrollada en nuestro país, en el epígrafe 7.3 se explica cómo se realiza éste proceso.
Para algunos autores éste proceso de serialización se identifica como el modelo
normalizado para la persistencia, pero en esencia son ideas similares porque el modelo
plantea que los objetos se descomponen en componentes atómicos que se almacenan en
archivos diferentes donde la relación entre varios componentes se mantiene por medio de
los identificadores de objeto.
Cuando los objetos se almacenan en la misma forma en que se definen en el esquema
conceptual, esto es, la unidad de almacenamiento es la misma que la unidad semántica, se
dice que el modelo de persistencia es directo.

6.2.2 - Vistas estáticas y dinámicas.

El análisis de cualquier problema requiere de un estudio global en el que se identifique no

solo la información a manipular, sino también restricciones sobre esa información,
relaciones que se establecen y procedimientos a ejecutarse que actúan sobre ella.
Ya en 1976 Peter Chen, cuando propuso el modelo entidad/relación, definía dos
perspectivas en la definición del modelo de datos Desde el punto de vista estático se refería
a los conceptos de entidad, relación, dominio, atributos, y restricciones sobre los valores
que se pueden tomar y el número de ocurrencias que delimitan el número de objetos que
pueden intervenir en un tipo de interrelación. Desde el punto de vista dinámico se refería a
lenguajes que operan en un nivel conceptual permitiendo formular consultas a la BD con
sentencias que se parecen al lenguaje natural y son sencillas de formular.
Las continuas extensiones al modelo relacional añadieron otros conceptos, como los de
agregación y generalización/especialización, que aportaban nuevos elementos a la vista
estática.
Los métodos de diseño existentes utilizan estas características y, usando la teoría de la
normalización, permiten obtener una BD que garantiza la consistencia, completitud e
integridad de la información. La parte dinámica de un problema se queda fuera de estos
procesos pues en éste modelo lo principal son los datos. Ni aún cuando en 1993 reapareció

134
el concepto de disparadores, se hicieron muchos aportes para diseñar correctamente los
mecanismos de disparo.
En el MOO cuando se habla de perspectiva estática se refiere a los conceptos de clase,
atributo, relaciones, restricciones de integridad estática, herencia y agregación; y como
perspectiva dinámica se incluyen las definiciones de operación o mensaje, evento, estado,
transición, petición o envío de mensaje y restricciones de integridad.
Los objetos vistos desde una perspectiva estática muestran al conjunto de propiedades
(atributos) que describen estructuralmente al objeto, de manera que los valores asociados a
cada propiedad estructural del objeto caracterizan el estado en un instante.
Las restricciones estáticas buscan hacer imposible la inserción inapropiada de elementos.
Por ejemplo, especifican que una determinada propiedad no admite el valor nulo o que solo
puede tomar determinados valores ya sea porque esté categorizado (sexo solo puede ser
femenino o masculino), en el caso de que sea numérico exista un rango de valores válidos o
tenga una regla de negocio asociada (el presupuesto de una empresa no puede ser mayor
que la suma del presupuesto de las áreas y sólo puede tomar valores en el intervalo
[0,1000000]). Es decir, estas restricciones están fuertemente relacionadas con el dominio de
los atributos de los objetos.
Cooling plantea que los objetos en la modelación dinámica responden a cuatro preguntas:
¿qué interacciones tienen lugar entre los objetos?, ¿por qué ocurren?, ¿cuándo ocurren? y
¿qué efectos generan en los objetos?.
A cada clase se le pueden asociar fórmulas de la lógica dinámica. Estos conceptos están en
mayor o menor medida reflejados en algunas metodologías, pero de manera general,
aunque hay algunos diagramas que permiten obtener algunos de ellos, raramente en el
proceso de diseño se describe como llevarlos a implementación. Estas fórmulas son:
 Evaluaciones: Caracteriza explícitamente parte del estado de un objeto antes y después
de la ocurrencia de una determinada acción.
  [a]
Produce cambios de estado.
 Derivaciones: Son fórmulas de la forma ’ que permiten definir atributos
derivados () en términos de una condición de derivación declarada en .
[a] (’)
Expresa como se obtiene el valor de un atributo derivado. Se debe
satisfacer en cada estado del objeto. No produce cambio de estado.
 Precondiciones: Prohibiciones para la ocurrencia de acciones.
[a]false

 Letelier, P. y otros. “Oasis versión 3.0: un enfoque formal para el modelado conceptual orientado a objetos:.
Servicio de publicaciones UPV-DSIC. 1998. España.

135
 Si  se satisface, entonces la ocurrencia de a está prohibida, es decir,
 es una fórmula que tiene que ser válida para que pueda ejecutarse la
acción.
 Disparadores: Se disparan automáticamente no por acciones de los usuarios.
 []false
La acción se activa cuando la condición que plantea la fórmula  se
satisface.
 Restricciones de integridad: Son fórmulas que deben ser satisfechas por lo que se
evalúan en el modelo cuando se produce un evento que
provoca un cambio de estado. Se clasifican en estáticas y
dinámicas. Las estáticas siempre son aplicables, en cambio
las dinámicas dependen del estado actual por lo que
requieren de una lógica temporal con sus correspondientes
operadores.
Donde , ’ y  son fórmulas bien formadas de la lógica de predicado de 1er orden y aA,
A es el conjunto de acciones.
Cuando se dice restricciones dinámicas se puede referir a la exigencia de la unicidad en el
valor que toma el o los atributos que se definan como llave, en el caso de existir éste
concepto, o a las implicaciones que puede tener la inserción o eliminación de un elemento
cuando hay jerarquía de clases o se trabaja con objetos complejos.
Las restricciones dinámicas también se refieren a las condiciones que deben cumplirse para
disparar una operación o que deben asegurarse antes o después de una operación para que
ocurra correctamente (pre-postcondiciones).
Para captar está semántica, las metodologías OO incluyen varios diagramas. En el caso de
la perspectiva estática por lo general tiene nombres cercanos a los de “diagrama de clases”
o “modelo de objeto”. Para la perspectiva dinámica son usados los diagramas de transición
de estado y otros que recojen la interacción entre los objetos.
De los diagramas utilizados por algunos métodos OO se podrían obtener varios de estos
conceptos, pero lamentablemente por lo general, si se hace alguna referencia, se aborda
solo la perspectiva estática (OMT, Medea). OO-Method ha logrado implementar con
buenos resultados el modelo conceptual teniendo en cuenta las vistas estáticas y dinámicas
descritas anteriormente.
En las propuestas de metodologías que se han desarrollado tomando como base la notación
UML, también se ha visto un incremento de la atención hacía la vista dinámica. Esto se
debe fundamentalmente a la existencia de un CASE (Rational Rose) que une toda la
información de los diagramas para producir código fuente, por lo menos a nivel de
definición de clases.

136
6.3 – Tratamiento de la persistencia en las metodologías.

Desde el año 1989 en que apareció la metodología de Coad-Yourdon que incluía elementos
para especificar los requerimientos, siguiendo el enfoque orientado a objetos, muchas han
sido las que se han desarrollado en la presente década. Gran parte de ellas eluden el tema
del diseño de la base de datos. . Incluso hay algunas que reconocen que no abordan éste
problema (Fusion). Esta situación es lógica si tomamos en cuenta el estado del arte en
cuanto a los Sistemas de Gestión de Base de Datos Orientados a Objeto y que el desarrollo
de metodologías para un nuevo enfoque va precedido del desarrollo de lenguajes que lo
soporten.
Las pocas metodologías que hacen referencia a éste punto han optado por dar solución a
éste problema planteando un conjunto de reglas que permiten convertir los objetos,
definidos a partir del análisis del problema, en tablas tal como se plantea en el modelo
relacional. A continuación haremos referencia a cómo enfrentan el diseño de la base de
datos algunas metodologías que abordan el tema.
Las metodologías que abordaremos por lo general son específicas para aplicaciones de
gestión y han tomado en cuenta la situación del mercado en la cual hay gran cantidad de
Sistemas de Gestión de Base de Datos Relacionales (SGBDR) ampliamente difundidos y
pocos SGBDOO, y los que existen tienen poca madurez. Algunos autores recomiendan que
para sistemas comerciales y que requieran alta confiabilidad se utilicen los SGBDR y para
aplicaciones CASE, CAD y CAM se usen SGBDOO.
Aquellas metodologías que hacen referencia a este aspecto plantean que la definición de
ésta base se concreta en decidir cuáles clases se desea sean persistentes y utilizar lo que
brinda el lenguaje para salvar y recuperar valores o después de un análisis y diseño enseñan
a obtener las tablas que se requieren para el modelo relacional. Dentro de los trabajos con
estas características podrían citarse la metodologías Object Modeling Technique (OMT),
O-Method y Medea.

6.3.1 – OMT.

OMT (Object Modeling Technique) fue expuesta por 1ra vez en 1991 en un libro cuya
vigencia sigue en pie, el propio Rumbaugh en el prólogo a su segunda edición nos alerta
sobre las pocas diferencias que existen con respecto a la anterior. Durante años fue la más
usada, aunque ahora está cediendo paso a UML, al estar concebida para el desarrollo de
sistemas de gestión en los que se parte de un análisis del problema siguiendo un enfoque
OO, pero sin perder de vista que se va a implementar en un medio relacional. Esto
indiscutiblemente es un gancho para los usuarios que en los últimos años han estado a la
caza de todos los SGBD que salen al mercado, y estos productos cada vez más se acercan al
modelo propuesto por Codd hace más de 25 años.
Modeliza un sistema desde tres puntos de vista distintos, pero complementarios (Figura
6.2):

137
 Mundo real

Modelo Modelo Modelo

objeto dinámico funcional

Aspectos estáticos, Aspectos temporales, de Aspectos

estructurales, del comportamiento, del transformacionales, de
sistema sistema función, del sistema
Usa el diagrama de Diagrama de transición de Diagrama de flujo de
objetos en el que se estados que incluye datos (DFD).
representa clases, estados, eventos,
objetos, asociaciones transiciones,
entre objetos con su precondiciones/Postcondici
cardinalidad y nombre ones, acciones que se
que identifica ejecutan como
unívocamente un consecuencia de una
terminal de asociación. transición y acciones que se
ejecutan en el estado.

Figura 6.2 Modelos de la metodología OMT.

Todo lo obtiene del modelo de objetos excepto: la clave primaria, los candidatos a llave
para cada tabla, la especificación de si un atributo puedo o no ser nulo, el dominio de cada
atributo y el grupo de atributos que están sometidos a un acceso frecuente. Brinda dos
formas para diseñar:
 Todo en una sola tabla.
<Nombre de entidad, Clave, Nombre de atributo, Valor>
 Varias tablas relacionadas, definiendo reglas que permiten convertir el modelo objeto a
tablas:
 Transformación de clases a tablas.
 Transformación de las asociaciones a tablas.

138
  Transformación de la herencia en tablas.
 Transformación de la herencia múltiple en tablas.
Posee una herramienta automatizada que permite crear el diagrama de objetos y actúa con
un compilador que permite trabajar con cualquier SGBDR porque tiene un fichero de
configuración que el usuario modifica de acuerdo a las nuevas especificaciones (OMTool
Schemer) (Figura 6.3).

Figura 6.3 Arquitectura para la conversión automática del modelo objeto a SGBDR.
De manera general podríamos decir que:
 Pone mucha atención en aspectos de BDR.
 Modelo de objetos muy rico, adecuado para tratar aspectos de modelización de datos.
 El diagrama de transición de estado representa los conceptos dinámicos, pero no
modeliza claramente el intercambio de mensajes entre objetos.
 La utilización de DFDs rompe con la uniformidad del modelo porque representa una
vista diferente del sistema que dificulta la detección de clases y la especificación simple
y localmente de sus servicios.


Tomado de Blaha, M., Premarlini, W. And Shen, H. “Converting OO Models into RDBMS Schema”. IEEE
Software, May 1994.

139
 En el Schemer no hay interacción con la BD porque sería muy lento, decrementa la
portabilidad y hace el problema más complejo si hay que cargar.
 Es una metodología más usada puesto que un analista que conozca los diagramas
entidad-relación, de transición de estado y de flujo de datos, no tiene mucho que
aprender.
 No existe un modelo real de identificación de clases con sus estructura y
comportamiento, solo consideraciones de tipo muy general pues no se basan en el
modelo cliente-servidor.
 Las reglas de conversión limitan la capacidad de evolución del esquema.
 Es un método evolucionista, con numerosas técnicas y sugerencias de aplicación
inmediata en entorno de desarrollos habituales.

6.3.2 – UML.

En 1994 se unen Grady Booch y James Rumabugh con el objetivo de unir sus metodologías
OO y crear una metodología unificada que sale a la luz un año más tarde. Está primera
versión (0.8) era exactamente eso, una unión que arrastró consigo los problemas de las
metodologías que le sirvieron de base. En 1995 se une Jacobson con OOSE (Object-
Oriented Software Engineering) y se decide en vez de una metodología definir un lenguaje
de modelación que incluya a varios diagramas. En noviembre de 1997 UML (Unified
Modeling Language) es certificada por OMG.
A partir de la estandarización de ésta notación, un conjunto de investigadores han
desarrollado metodologías propias para el desarrollo de proyectos OO. Tomar como base
las herramientas que ofrece UML sin una guía, es una tarea difícil cuando se pretende
realizar un proyecto OO. Estos investigadores alegan: “no te metas a entender los
diagramas que yo te voy a brindar una forma de trabajo sin necesidad de conocer los
detalles internos”.
Dentro de un desarrollo caótico de metodologías OO sin una estandarización de conceptos,
es un paso importante la aparición de UML que además cuenta con una poderosa
herramienta CASE, pero su definición hace el proceso de análisis y diseño bastante
complejo (dado por la complejidad de los diagramas) en los que hay que tener cuidado
porque arrastran (en menor escala) los problemas de la metodología de Booch de
representar en más de una ocasión la misma información de manera distinta y se pierde la
vista global del problema al estar fragmentada en 8 diagramas la representación del mundo
real.

6.3.3 – Medea.

Constituyó el trabajo de doctorado del autor (Mario Piattini) y está definida para la
instrumentación de un diseño OO en un SGBD que soporte SQL3

140
Lo obtenido en la etapa de análisis posee la misma información que lo representado en un
diagrama entidad-relación, con algunos otros aspectos relativos a los servicios y contratos.
En la transformación del esquema del análisis al esquema del diseño (conversión de clases
en tablas con procedimientos almacenados) tratan de que se cumplan los siguientes
principios:
1. Conservar la semántica ya que la BD es un modelo del mundo real.
2. Capacidad de evolución.
3. Minimizar el número de valores nulos.
4. Eficiencia en cuanto a tiempo de respuesta, ocupación de memoria, etc.
5. Evitar redundancias.
6. Sencillez.
7. Uniformidad, es decir, si se toma una decisión de diseño, que ésta tenga carácter general
y se siga a lo largo de todo el diseño.

Reglas de transformación del esquema de análisis al diseño.

1. Completar la información de los dominios de los atributos en el caso de que no hayan
sido especificados.
2. En caso de que las colecciones no sean conjuntos, multiconjuntos, listas o matrices;
buscar si alguna biblioteca de clases tiene el tipo genérico y crearlo.
3. Transformación de tipos de objetos.
 Especificar cómo se identifican los objetos.
 Transformar atributos en columnas y en disparadores o servicios en caso de que
sea derivado.
 Especificar de los servicios el algoritmo y si es función o procedimiento.
4. Implementar las operaciones libres en procedimientos almacenados si el sistema lo
permite.
5. Transformación de las restricciones de integridad.
 Estáticas: en dependencia del alcance se definen para el atributo, la clase; como
aserciones o disparadores.
 Dinámicas: se recogen como disparadores.
6. Transformación de las interrelaciones entre objetos.
 Dependen de la cardinalidad.
 Se intenta reducir el número de clases instrumentando las interrelaciones
mediante atributos (con algunas excepciones) para aumentar la eficiencia y
hacer más sencillo el esquema de diseño.
7. Dar solución a las entidades débiles.

141
8. Transformar las generalizaciones tal como están definidas sin perder semántica.
La metodología da poca importancia al modelo dinámico porque considera como lo
principal a los datos (lo hacen conscientemente). Coexisten a la vez llaves e identificadores
de objetos aunque recomiendan que un objeto se identifique de alguna de las dos formas. Se
pierde capacidad de evolución en algunos lugares, por ejemplo, cuando sugiere representar
todas las interrelaciones usando atributos. En ocasiones dejan atributos que son del tipo de
una clase y en otras los transforman en tablas.

6.3.4 – OO-Method.

Es una metodología de producción automática de software que proporciona una estrategia

de traducción bien definida que permite implementar los modelos conceptuales en entornos
relacionales avanzados. Constituye el resultado de varios años de trabajo del departamento
de Sistemas Informáticos y Computación de la Universidad Politécnica de Valencia. La
propuesta tiene dos fases:
 Modelo conceptual: se recoge las propiedades esenciales que definen el sistema en:
 tres modelos de análisis: objeto, dinámico y funcional y
 una especificación formal OO en Oasis (lenguaje de especificación formal basado en
la lógica de predicado clausal dinámica de 1er orden) que es un diccionario de datos
generado automáticamente a partir de los modelos del análisis.
 Modelo de ejecución: especifica como trasladar cada una de las nociones recogidas en
los modelos de análisis a estructuras asociadas a un entorno relacional. En particular se
tienen resultados para Oracle7 y se está trabajando para Visual C++, Delphi y Java.
En el producto generado están implementadas tablas creadas con sus atributos y
restricciones de integridad, procedimientos, paquetes y disparadores de la BD, interfaz con
el usuario y modelo de protección.
¿Qué incluye cada modelo del análisis?
Modelo Características
Objetos Utiliza un Diagrama de Configuración de Clases (DCC) para definir y mostrar
las 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.
Dinámico Se relacionan aspectos relacionados con las secuencias posibles de eventos
(vidas posibles) en el diagrama de interacción entre estados (uno por clase) y
la interacción entre objetos en el Diagrama de Interacción entre objetos (uno
para la aplicación).
Funcional Captura la semántica a los cambios de estado especificando mediante un
diálogo interactivo el efecto de un evento sobre los atributos.

142
La definición de un clase incluye:
 Atributos constantes especificando cuales son llave.
 Atributos variables especificando dominio y valor por defecto.
 Eventos propios y compartidos y precondiciones.
 Restricciones de integridad estática y dinámica.
 Formulas de derivación que permiten obtener los atributos derivados en función de
otros que ya existen.
 Relaciones de disparo.
 Formulas de valuación que permiten determinar como una acción modifica el estado
de los atributos.
 Procesos.
La herramienta CASE (OO-Method CASE tool):
 Proporciona un medio operacional que soporta todos los aspectos de la metodología
OO-Method.
 Generación de la especificación formal OO (OASIS).
 Generación de código completo (incluyendo estática y dinámica) en Visual C++,
Delphi, Java,... (en esto se está trabajando).
 Generación del esquema de la BD en MSAccess, Interbase,... (en esto se está
trabajando).
Es una metodología completa que hace que el esfuerzo inicial en la fase de análisis pueda
usarse en el diseño e implementación de manera fácil y predecible. En cualquier momento
es posible obtener una aplicación ejecutable siempre que en los modelos de análisis esté
correctamente definida la información, pues usa un lenguaje de especificación formal OO
como almacén central de información.

6.3.5 – Aproximaciones para sistemas híbridos.

Una de las pocas metodologías que desde sus inicios tuvieron en cuenta el diseño de la BD
fue OMT de Rumbaugh. La idea expuesta en ésta metodología (uso del MR) ha sido
tomada por muchas otras en los últimos 5 años y no deja de ser acertada de acuerdo al
estado de la arte en el campo de las BD. En esencia proponen tomar como base las reglas
de transformación de entidades y relaciones a tablas tal como se definían en el MR
(apartada 3.4.3). Obviamente esto requiere tener definido con claridad las propiedades de
los objetos y la cardinalidad en su relación con otros objetos, para lo cual cada metodología
usa herramientas propias.
Desde el punto de vista dinámico algunos investigadores ha publicado trabajos relacionados
con la forma de obtener disparadores o incitadores a partir del uso de los Diagramas de
Transición de Estado (DTE). Aunque algunas metodologías definen diversas técnicas para
describir el comportamiento de los objetos, no se explica cómo transformar esto al lenguaje

143
de consultas que ofrecen los gestores de BD. Salen de ésta afirmación aquellas cuya
descripción se basa en la lógica de predicado de 1er orden, por la relación obvia de ésta con
los fundamentos teóricos del MR que hacen más “suave” está transición.
En los últimos años existe una tendencia de definir una capa intermedia, conocida como
capa de objetos, que sirva de interfaz entre el almacenamiento de la información (en la que
se puede usar una BDR o incluso jerárquica) y las aplicaciones que utilizan ésta. Esta idea
como se vio en el epígrafe 4.4.3, está siendo implementada por los gestores relacionales
que avanzan hacía la OO. Por ejemplo, la metodología que propone Liberty basada en
UML define las reglas para la transformación de objetos a tablas y propone la creación de
una capa con las clases con métodos, para que permitan las operaciones CRAE, por cada
clase persistente (Figura 6.4).

Figura 6.4 Modelo de persistencia propuesto por James Liberty.

Como se ve todo está claro desde el punto de vista estático, pero en los procesos de
serialización no se explica cómo lograr que el medio seleccionado permita modelar la
perspectiva dinámica, salvo el caso de los disparadores. Este es un problema general, claro
todos alegan que las conversiones no son lo natural, lo natural es usar un SGBDOO que no
necesite serializar, pero esto es estar alejado de los desarrolladores de aplicaciones, que no
se van a mover bruscamente hacía algo no maduro como los SGBDOO, y de los gestores
potentes en el mercado.

Conclusiones.

Por lo complejo que resulta diseñar la BD partiendo del MOO dado el estado del arte de los
SGBDOO, ésta no fue una actividad en la que se hicieron grandes esfuerzos en los inicios
del desarrollo de metodologías de análisis y diseño. Pero el número cada vez más creciente
de aplicaciones que manipulan grandes volúmenes de información y la necesidad de los
desarrolladores de estas aplicaciones de utilizar las potencialidades del enfoque OO,
propició las bases de los trabajos que se han desarrollado.

144
La tendencia más explotada ha sido la conversión al MR dada la madurez de los gestores
con estas características que se ofrecen en el mercado. Un área emergente y con gran futuro
como los gestores objeto/relacional, todavía es un campo, en cuanto al diseño de la BD,
poco abordado.
En el capítulo 7 se hace hincapié en una propuesta de diseño que tiene en cuenta esto, pero
antes es importante tener claras las respuestas a las preguntas formuladas en la introducción
pues son conceptos claves para su entendimiento.
 Qué es el proceso de serialización?.

Transformación de los objetos de manera que su información pueda

ser almacenada y transportada.

 ¿Cómo se ven los objetos desde una perspectiva estática?.

Con sus atributos, relaciones con otros objetos de herencia,

agregación y colaboración, y con las restricciones estáticas que
impiden la inserción inapropiada de elementos.

 ¿Cuáles son las fórmulas dinámicas que se definen en la modelación dinámica?

 Evaluación.
 Derivación.
 Precondiciones.
 Disparadores.
 Restricciones dinámicas.

Referencias bibliográficas.

[Bertini, 1994] Bertino, C, Ceri, S. and Navathe, S. “Diseño conceptual de base de datos,
un enfoque de entidades e interrelaciones”. Addison-Wesley Iberoamericana, S.A. USA.
1994.
[Bertino, 1993] Bertino, E. And Martini, L. “Object-oriented Database Systems: concepts
and architectures”. Addison- Wesley Publishing, Co. 1993.
[Blaha, 1994] Blaha, M., Premarlini, W. And Shen, H. “Converting OO Models into
RDBMS Schema”. IEEE Software, May 1994.
[Booch, 1994] Gardy, B. “Object-Oriented design and analysis with applications”.
Benjamin/Cummings Publishing Company. 1994, 2da edición.
[Chaudhri, 1998] Chaudhri,A. and Loomis, M. “Object Database in practice”. Prentice-
Hall, Inc. 1998. Hewlett-Packard Company. “Object-Oriented data Integration”, W.
Keller; C. Mitterbauer and K. Wagner. P3-20.

145
[Cooling, 1997] Cooling, J.E. “Real-time software systems: an introduction to structured
and object-oriented design”. International Jhonson Publishing Inc. EUA. 1997.
[Date, 1993] Date, C.J. “An introduction to Database”. Adisson –Wesley Iberoamericaba.
5ta edición. 1993.
[DeMiguel, 1993] De Miguel, A. y Piattini, M. “Concepción y diseño de Bases de datos del
modelo E/R al modelo relacional”. Adisson-Wesley Iberoamericana. 1993.
[Ladányi, 1997] Ladányi, H. “SQL unleasshed”. Sams Publishing 1997.
[Liberty, 1998] Liberty, J. “Begining Object-Oriented Analysis and Design with C++”.
Wrox Pres, 1998, Canadá.
[Medina, 1996] Medina , H. “Fusion: meodología orientada a objetos para desarrollo de
software”. Revista Soluciones Avanzadas. Año 5, No38, Octubre 1996.
[DeMiguel, 1993] De Miguel, A. y Piattini, M.” Concepción y diseño de base de datos, del
modelo entidad/relación al modelo relacional”. Addison-Wesley Iberoamericana, S.A.
USA. 1993.
[Letelier, 1998] Letelier, P. y otros. “Oasis versión 3.0: un enfoque formal para el
modelado conceptual orientado a objetos:. Servicio de publicaciones UPV-DSIC. 1998.
España.
[Martín, 1998] Martín, J. and Odell, J. “Object-oriented methods: a foundation”. Second
Edition. Prentice-Hall, Inc. 1998. EUA.
[Pastor, 1992] Pastor, O. Tesis de doctorado: “Diseño y desarrollo de un entorno de
ejecución automática de software en el modelo orientado a objetos”. Universidad
Politécnica de Valencia. 1992.
[Pastor, 1993] Pastor, O. y García, R. “Uso de Oracle como base de datos relacional para
implementar un diseño orientado a objetos”. Generalitat Valenciana, Conselerria de
Senitat i Consum. 3 de Mayo de 1993.
[Pastor, 1995] Pastor, O., García, R. y Cuevas, J. “Implementation of an OO design in an
Oracle 7 development enviroment”. Informe de investigación. Universidad Politécnica
de Valencia. 1995.
[Pastor, 1995] Pastor, O., Insfrán, E. y Pelechano, V. “Uso de Oracle como base de datos
relacional para la implentación de un diseño orientado a objetos”. ”. Informe de
investigación. Universidad Politécnica de Valencia. 1995.
[Piattini, 1994] Piatinni, M, Tesis de doctorado: “Desarrollo de una metodología de
desarrollo para bases de datos oreintadas a objeto fundamentadas en extensiones del
modelo relacional”. Universidad Politécnica de Madrid. 1994.
[Rational, 1997] Rational Software Corporation, “UML Documente Set Version 1.0”. 13 de
enero de 1997.
[Rumbaugh, 1996] Rumbaugh, J. Blaha, M. Premarlini, W. Eddy, F. y Lorense, W.
“Modelado y diseño orientado a objetos. Metodología OMT.” Prentice-Hall
Hispanoamericana. S.A. 1996.

146
 Capítulo 7
Soluciones al diseño
de la BD.

147
 Capítulo 7 Introducción.

Para el MOO el diseño de la BD no ha logrado una estandarización como ocurre con el

MR, pero es algo lógico si tenemos en cuenta que al MR le hicieron falta más de 20 años
para lograr su consolidación y el MOO es un recién nacido. El estado del arte en el campo
de las BDOO condicionaron las alternativas del diseño de la BD que se proponen a
continuación tomando como base los resultados del análisis de la metodología ADOOSI
Visual.
Se hace mayor hincapié en el caso de la utilización en la implementación de un gestor
relacional u objeto/relacional, por las transformaciones que implica pasar de un
pensamiento en término de objetos a uno de entidades. No obstante se hace un proceso
suave de conversión en el que no se desechan todos los conceptos de la OO.
Al finalizar el estudio de éste capítulo se debe ser capaz de diseñar la BD de acuerdo al
medio de implementación y se podrá dar respuesta a las siguientes preguntas:
 ¿Cómo se capturan las características que definen el comportamiento estático de las
clases?.
 ¿De qué forma se capturan los aspectos dinámicos de un problema?.
 ¿Cómo ésta propuesta de conversión del MOO no desecha por completo todas las
características de éste enfoque?.

7.1 ADOOSI Visual.

La metodología Análisis y Diseño Orientado a Objetos de Sistemas Informáticos para

medios ambientes visuales (ADOOSI Visual) es la utilizada en Cuba de forma generalizada
para enfrentar proyectos que sigan este enfoque y con ella se han desarrollado gran cantidad
de proyectos desde el año 1993. Se ha impartido en pregrado y postgrado en universidades
de Perú, México, Argentina, Paraguay y Bolivia.
En su ciclo de vida se introducen algunas herramientas propuestas por otras metodologías,
siendo sus principales novedades el grafo de control y el conjunto de reglas asociadas para
la valoración de la estructura de clases obtenidas en la etapa de análisis, la modificación del
grafo de colaboración de Wirfs-Brock para considerar la visibilidad de las clases y las
asociaciones de contenido, y la creación de una técnica para la definición de los
subsistemas mediante el uso de las clases controladoras. Se tienen en cuenta las nuevas
tendencias en los medios de programación que incluyen características visuales. En estos
medios se posibilita la confección de un prototipo del sistema e inclusive evolucionar ese
prototipo en el software final, por esta razón ADOOSI Visual se basa en la filosofía de
trabajo que hace uso de prototipos.
La metodología cubre todas las etapas del ciclo de vida de un proyecto informático,
garantizando el desarrollo de éste de forma:
 Iterativa: refinando los productos de etapas y fases antes hechas.
 Incremental: construyendo el proyecto por partes que se integran.
 En paralelo: realizando el proyecto por subgrupos de analistas.

148
Las etapas están perfectamente delimitas y se dividen en: Estudio Preliminar, Análisis,
Diseño, Desarrollo, Prueba e Implantación. Es una metodología puro OO por lo que se basa
en el principio cliente-servidor y dentro de éste en el principio manejado por
responsabilidades. Como resultado de la etapa de análisis, y fuente para el diseño de la BD,
se obtiene para cada clase:
Aspecto Contenido
Características Nombre
generales
Descripción
Especificación de Nombre
cada
Descripción en lenguaje natural
responsabilidad
Parámetros Nombre
Descripción
Tipo de dato
Especificación de Nombre
cada atributo Descripción
Tipo de dato
Especificación de Nombre de la clase colaboradora
cada colaboradora Nombre de cada colaboración (se
corresponde con alguna responsabilidad
de la clase colaboradora.
Además se definen diferentes tipos de asociaciones (llamadas relaciones por algunos
autores), ellas son:
 Es un tipo de o generalización/especialización.
 Es análoga a: se corresponde con el hecho de que una clase tiene comportamiento
similar a otras, ambas tienen responsabilidades y/o atributos comunes, pero no se
puede decir que una herede de otra.
 Agregación.
 Agrupamiento.
 Tiene conocimiento de: un objeto de una clase puede requerir algo de otro objeto, sin
que se modifique el estado del objeto servidor, aunque no éste compuesto de ese otro.
Es decir, el cliente “tiene conocimiento” del servidor.
 Depende de: un objeto de una clase al requerir algo de otro objeto provoca
modificaciones en su estado por lo que el servidor “depende “ del cliente.
 Composición paralela: La clase resultante de una composición paralela se corresponde
con una clase que coordina el trabajo entre varias clases, por lo que esas clases tienen
que ser visibles a ella. Esta clase se corresponde con la clase controladora de un
subsistema.
Este método en sus primeras propuestas tampoco hacía referencia al diseño de la BD, tal
como ocurría internacionalmente. En sus continuas versiones ha ido incluyendo algunas
especificaciones que se adaptan a las potencialidades de los productos presente en el

149
mercado. En su versión 4.0 incluye el modelo de persistencia que se describe en los
siguientes apartados.

7.2 - Alternativas.

La propuesta de diseño de base de datos que se incluye se divide en tres partes que
dependen del sistema que se utilice para implementar la solución al problema planteado.
Estas tres soluciones son:
 Si se tiene un SGBDOO, el trabajo se limita a determinar cuáles clases se desea sean
persistentes (esto es una propiedad de las clases). La calidad de la definición de estas
clases está subordinada al cumplimiento de las directivas que se establecen en la
metodología para lograr un buen diseño de las clases.
 Si lo que se tiene es un lenguaje de programación OO (LPOO) que permite
relacionarse con una base de datos relacional o un SGBD objeto/relacional, la solución
es llevar las clases definidas a tablas.
 Si lo que se tiene es un lenguaje de programación OO que no permite relacionarse con
base de datos relacional, pero que permite salvar registros, entonces se deben utilizar
las clases que brinda para almacenar los atributos de las clases persistentes en ficheros
estructurados. Puede que el lenguaje permita la relación con BDR, pero se escoja
como forma de almacenamiento la organización en ficheros.
Como se aprecia la primera y tercera variante en su implementación depende mucho del
producto que se utilice. En cambio, la segunda alternativa tiene un soporte común para
todos los productos que se puedan usar, ésta base es el modelo relacional. A pesar de ello
no todo será posible implementarlo porque los gestores no implementan el 100% del
modelo en que se basan.

7.2.1 - Implementación de la persistencia para el almacenamiento de la información en

ficheros.

Cuando se utiliza ésta forma de almacenamiento de la información, antes hay que

desarrollar un conjunto de tareas. Esto implica los siguientes pasos:
1. Completar las definiciones de clases en cuanto a nivel de protección (privado,
protegido y público) de atributos y métodos, y especificación de los métodos.
2. Refinar clases, responsabilidades y atributos.
3. Definir la jerarquía de clases a partir de las clases que se representan en el dominio del
sistema.
4. Definir la jerarquía de clases con respecto a las definiciones en el lenguaje OO a
utilizar y otras bibliotecas de clases externas que se posean. Este paso puede implicar
que clases del dominio del sistema se eliminen porque existan otras que automaticen el
comportamiento a ellas asociada.

150
Para las clases persistentes se debe garantizar:
 Cada una de ellas o un ancestro hereden de la clase que el lenguaje defina como
persistentes (en Borland Delphi es TPersistent).
 Existan métodos para salvar y cargar la información (ReadData y WriteData en
Borland Delphi).
 La definición del código de los métodos anteriores de acuerdo al tipo de los atributos
de la clase (el lenguaje brida para cada tipo de dato un métodos para salvar y otro para
restaurar, pro ejemplo, en Borland Delphi si el atributo es de tipo string los métodos
serían: ReadString y WriteString).
 La definición del código para registrar las clases.
Esta forma de almacenamiento implica que se crea un fichero, con extensión definida por el
programador, cuya estructura no es fija pues se almacenan objetos de diferentes clases. La
información almacenada es tratada como un fichero sin tipo en el que se leen y escriben
byte que cobran sentido cuando se trabaja con objetos en memoria externa.
Todas las clases, persistentes o no, debe ser organizadas en bibliotecas de clases.
Lógicamente todas no deben estar en una misma biblioteca por la magnitud y complejidad
que puede tener un sistema. En ADOOSI Visual se recomienda utilizar el concepto de
subsistemas.
Un subsistema es responsable de varias de las tareas del sistema, que son coordinadas por
una clase que se conoce como clase controladora (es el caso típico del tipo de asociación
composición paralela). La clase controladora o coordinadora es la cara visible del
subsistema, aunque por excepción alguna otra clase o subsistema puede ser visible para otra
clase o subsistema externo. Esto significa que fuera de lo visible, desde afuera NO se
conoce la definición interna. Desde el punto de vista de la implementación, en la interfaz se
pone la estructura de las clases visibles, y en la sección de implementación la
especificación de cada método de estas clases y la estructura y especificación de los
métodos del resto de las clases.
Los pasos que propone la metodología, para obtener subsistemas son:
1. Identificar las clases controladoras.
2. Asignar un subsistema por cada clase controladora y distribuir las responsabilidades
del sistema en los subsistemas obtenidos.
Dentro de cada subsistema se aglutinan un conjunto de clase que, a partir de las relaciones
cliente-servidor, necesita la controladora u otras clases para cumplir la responsabilidad
asignada.
Partiendo de estas definiciones, al definir cuáles bibliotecas se crean, se tiene en cuenta loi
siguiente:
 Un subsistema se transforma en una biblioteca.
 En la sección de interfaz se declaran:
 Las constantes y tipos particulares.

151
  Los subsistemas con los que se relacionan, las bibliotecas del lenguaje que
necesitan usar y las bibliotecas generales de constantes y tipos (se recomienda
definir una o varias bibliotecas con las constantes y tipos que se necesitan).
 La estructura de las clases visibles especificando su nombre, de quién heredan,
atributos con nivel de protección y tipo, y las responsabilidades indicando di es
procedimiento o función, parámetros de entrada y salida, tipo de valor que
devuelve si es función y nivel de protección.
 En la sección de implementación se declaran:
 La estructura de las clases no visibles.
 La implementación de todos los métodos.
 El código asociado al tratamiento de la persistencia usando organización clásica.
La forma en que los lenguajes de programación implementan la persistencia, recuerda las
características de los productos de la 1ra generación de SGBDOO. Estos gestores ofrecen
un biblioteca de clase, de cuyas clases deben heredar las clases persistentes del dominio si
quieren convertirse en persistentes. La diferencia principal es que los lenguajes solo
garantizan el almacenamiento de la información y los gestores guardan también el
comportamiento asociado a las clases.

7.2.2 - Garantía de la calidad de las clases para el trabajo con un SGBDOO.

Durante el proceso de análisis la metodología brinda una serie de recomendaciones que

permiten analizar el flujo de control entre las clases. Una definición de clases adecuada
tiene en cuenta lo siguiente:
1. No debe existir un excesivo centralismo del control por parte de ninguna clase: Una clase
no debe tener mas de 7±2 clases con las cuales interactuar. En los niveles superiores de la
jerarquía el límite es usualmente entre 4 y 8, pues en los niveles altos se supervisa el
trabajo de otras clases y en los niveles bajos se delega la realización de tareas específicas,
lo que es más simple.
2. Un subordinado no debe tener más de un jefe, por lo que una clase debe tener un sólo jefe
aunque se tiene las siguientes excepciones:
a. Una clase puede estar subordinada a varias clases para realizar responsabilidades de
distinto índole.
b. Una clase puede tener varios jefes para responsabilidades que impliquen entrega de
información o para tareas simples de uso general.
3. En principio debe realizarse una nueva distribución de responsabilidades cuando una
clase de menor jerarquía desde el punto de vista de control solicita servicios a una de
mayor jerarquía. Hay situaciones en que puede ser necesario (cuando se pide
información ), pero en general es un síntoma de control inadecuado.
En la evaluación de la calidad del proceso de análisis, se analizan 10 atributos de calidad de
acuerdo a la apreciación que se haga de un conjunto de factores y métricas de calidad. Los

152
atributos que se tienen en cuenta en la valoración del nivel de aceptación de la etapa de
análisis en ADOOSI Visual son:
1. Complejidad de las responsabilidades del sistema: Es el grado en que se ha logrado
definir de forma clara y concisa todo lo que realmente debe hacer el sistema de acuerdo
a los objetivos de éste.
2. Consistencia del guión: Es el grado en el que el guión representa de forma no
contradictoria las interacciones de las clases que son necesarias para cumplir la
responsabilidad planteada.
3. Consistencia del grafo de control: Es el grado de representación única y no
contradictoria alcanzada en el flujo de control entre las clases que interactúan para
cumplir una responsabilidad del sistema.
4. Completitud de las clases: Es el grado de especificación total (sin omisión) de los
requerimientos para la definición de la clase.
5. Consistencia de las clases.
Es el grado en la que la definición de la clase es única y no contradictoria respecto a los
requerimientos de una entidad capaz de cumplir las responsabilidades asignadas y tener
los atributos necesarios para ello y sin que exista ninguna contradicción en la forma de
lograrlo.
6. Complejidad de las clases: Nivel de dificultad para comprender la conducta de la
abstracción.
7. Cohesión: Es el grado de cohesión simple entre las clases y objetos, es decir, que los
atributos de una clase trabajan justamente a la vez para proveer un buen
comportamiento.
8. Encapsulamiento: Es el grado en que la información apropiada está adecuadamente
encapsulada dentro del tipo correcto de entidad, para disminuir acoplamiento y
aumentar la cohesión.
9. Visibilidad: Es el grado en que una clase puede invocar métodos de otra. Se dice que
una clase B es visible a una clase A, cuando A invoca métodos de la clase B.
10. Complejidad de las asociaciones: Es el grado de especificación total (sin omisión) de
las asociaciones entre las clases, es decir, si se han definido todas las formas posibles
en los que los objetos de dos o más clases se relacionan entre sí de acuerdo a los
requerimientos del problema.
Dentro del proceso de diseño, no importa la forma de almacenamiento que se siga para las
clases persistentes, lo primero que se hace (cuando se usa ADOOSI Visual) es refinar las
clases obtenidas como resultado del análisis. En el epígrafe 7.3.1 se describe cómo se hace
éste proceso, que implica: identificar superclases (que pueden o no ser abstractas),
completar la descripción de todos los componentes de una clase e identificar
comportamiento que ha sido omitido, pero es importante dentro del dominio del sistema,


García, L. y Alvarez S. “Evaluación de la calidad de la etapa de análisis de proyectos informáticos
orientados a objeto”. Revista Ingeniería Industrial

153
con la definición de nuevos atributos asociados a éste nuevo comportamiento. Los atributos
que se evalúan para evaluar la calidad se éste procesos son:
1. Consistencia de las clases abstractas y concretas: Es el grado en que la definición de
clase abstracta y concreta es única y no contradictoria respecto a los requerimientos de
una asociación de analogía o a las asociaciones de generalización/especialización.
2. Completitud de cada clase: Es el grado de especificación total (sin omisión) de los
requerimientos para la definición de una clase de acuerdo a la metodología.
3. Complejidad de cada clase: Es el grado de comprensión de la conducta de la
abstracción, en la que se tienen en cuenta métodos que invoca, cantidad de métodos y
atributos y profundidad y amplitud del árbol de herencia.
4. Consistencia de la clase: Es el grado en que la definición de la clase es única y no
contradictoria respecto a los requerimientos de una entidad capaz de cumplir las
responsabilidades asignadas y tener los atributos necesarios para ello sin que exista
ninguna contradicción en la forma de lograrlo.
5. Cohesión de la clase: Es el grado en que los métodos de una clase están relacionados
unos con otros y trabajan juntos para proveer un buen comportamiento.
6. Tamaño de la clase: Es la magnitud de la clase. El tamaño de la clase indica la cuantía
de la colaboración. Clase grandes son más complejas y difíciles de mantener. Clase
pequeñas tienden a ser más reusables ya que proporcionan un conjunto de servicios
cohesivos.
7. Completitud de las responsabilidades y atributos de una clase: Es el grado en que se
ha logrado definir de forma clara y concisa todo lo que realmente debe hacer una clase,
así como la especificación total (sin omisión) de los atributos necesarios para ello.
8. Tamaño de la responsabilidad de una clase: Es la cuantía de una responsabilidad dada
por el número de mensajes que envía, cantidad de líneas de código y cantidad de
sentencias.
9. Complejidad de la responsabilidad de una clase: Es el grado de comprensión de la
conducta de la abstracción.
La evaluación de estos atributos se realiza a través de métricas de calidad, pero no vamos a
adentrarnos más en éste campo. Lo importante es conocer cuáles aspectos son importantes
para verificar la calidad de las definiciones obtenidas, tomando en cuenta el universo del
discurso y las particularidades del enfoque OO.


García, L. y Alvarez S. “Atributos y factores de calidad para la etapa de diseño de un proyecto informático
orientado a objetos”. Revista Ingeniería Industrial

154
7.2.3 - Módulos para la conversión del MOO.

 Refinar la jerarquía de clases,

Especificaciones
especificando además atributo del padre y
del análisis
valor que provoca la especialización.
T
A  Definir llaves.
Módulo de R  Completar dominio de los atributos.
completamiento E  Definir fórmulas de derivación para los
A
atributos derivados.
S
 Especificar cardinalidades mínimas y
máximas de las relaciones y las
dimensiones Inclusiva/ Referencial y
Estática/ Dinámica de la agregada con
respecto a cada componente.

Teniendo en cuenta las características del modelo objeto/

Módulo de relacional se trata de mantener la capacidad semántica del
Transformación modelo orientado a objetos aplicando las reglas de
conversión del modelo relacional, basadas en la
cardinalidad de las relaciones, siempre que no sea posible
traducir fielmente una clase por las limitaciones del medio.

Se genera el código para un lenguaje determinado a partir

Módulo de
de las especificaciones anteriores. Esta conversión depende
utilización
de las posibilidades del lenguaje en particular.

Se define una capa de clases que sirven de interfaz entre la

aplicación y la base de datos, encapsulando el trabajo con
Módulo creador ella. En esas clases están definidos métodos que permiten
de métodos insertar, eliminar y actualizar elementos, y consultar la
para clases base de datos. El objetivo es que se siga trabajando desde
persistentes afuera con los objetos, tal como se definieron en etapas
previas, sin preocuparse de la forma en que se almacenan.

Generador de Para las clases no persistentes deben quedar claras las

prototipo de características de sus atributos y la especificación de los
clases no métodos utilizando un lenguaje de especificación.
persistentes

155
7.3 – Implementación de los módulos.

Los módulos definidos en el proceso de conversión se ejecutan secuencialmente, a partir de

las clases obtenidas en la etapa de análisis. No todas las clases sufren las transformaciones
que en ellos se plantean, solo aquellas que se clasifican como persistentes. Cuando una
clase se define como persistente, las clases que lo componen lo son automáticamente, lo
mismo ocurre con una clase hija y sus ancestros. Lo contrario en ambos casos no se cumple
necesariamente.
Si existe herencia múltiple, ésta debe ser resuelta antes. La solución más factible es que la
clase hija herede de la clase de la que redefine sus métodos y añada un atributo pasivo del
tipo de la otra clase de la que heredaba. De ésta forma estamos construyendo una nueva
clase agregada, en caso de que no lo fuera con anterioridad. Cuando redefine
comportamiento de más de una clase padre, hay que decidir de cuál hereda y cambiar,
además de adicionar atributos del tipo de los padres de los que no hereda, los métodos que
se redefinen con llamadas a otros métodos de las clases componentes.

7.3.1- Completamiento.

En el capítulo 4 se planteaba que una de las características principales de los objetos estaba
relacionada con su identificación. Como en esta variante de solución la implementación es
un SGBDR o un SGBDOR, hay que especificar cuál o cuáles atributos serían la llave. La
determinación de esto depende del tipo de clase:
 Las clases simples tienen un atributo llave que en principio, se obtiene de sus propios
atributos. Si ninguno de sus atributos responden a la propiedad de unicidad, se añade
un atributo que tome valores secuenciales que no se repitan.
 Las clases compuestas son definidas en el análisis como que tienen una asociación del
tipo de agregación, al igual que las clases complejas. Una clase compuesta es el
resultado de la unión de varias clases para formar una entidad conceptual con
significado en el universo del discurso. Por ejemplo, una reservación de un hotel es la
fusión del huésped que realiza la solicitud de habitación y la habitación que se le
asigna. En estos casos no se definen atributos llaves, pues la llave es la unión de las
llaves de las clases que la conforman.
 Las clase complejas son clases que tienen uno o varios atributos que referencian a otros
objetos de otras clases. En estos casos se tienen como llave, a atributos atómicos de la
clase compleja. En el análisis las clases complejas también se clasifican como
agregación.
La mayoría de las definiciones incluidas en el módulo de completamiento son capturadas
gráficamente en el diagrama de clases (DC) cuya notación toma como base las del
diagrama de estructura estática de UML y del modelo de objeto de OO-Method, aunque se
hacen algunas inclusiones (Figura 7.1).

156
Figura 7.1 Notación del Diagrama de clases.

Refinamiento de clases.
En la realización del DC, primero hay que redefinir las clases, obtenidas como resultado del
análisis, tomando como base las asociaciones de analogías y generalización/especialización
definidas. También hay que revisar si existe algún comportamiento omitido del dominio del
análisis que no haya sido tomado en cuenta, es importante analizar si es transcendental en la
solución del problema, para incluirlo.
Las clase análogas tienen comportamiento y atributos comunes, por lo que para cada grupo
de clases análogas se define una nueva clase que contendrá lo común. La nueva clase puede
ser o no abstracta. Este proceso recibe el nombre de generalización. Las clases
especializadas deben conservar aquellos métodos cuyo comportamiento sea necesario
redefinir. Con este procedimiento se crean nuevas asociaciones de
generalización/especialización.
Deben analizarse las asociaciones de generalización/especialización, definidas durante el
análisis, ya que si la clase especializada no hereda todo el comportamiento de la
generalizada, debe incluirse una nueva clase con lo común de la que hereden. Este tipo de
asociaciones se implementa mediante la herencia.
Aquellas clases que tienen como atributo a otras clases fueron clasificadas en el análisis
como que tenían una asociación del tipo de agregación o de composición paralela. Desde el
punto de vista del diseño de la BD, es importante tener clara ésta clasificación, pues
conceptualmente las clases con asociación del tipo composición paralela no son
persistentes. La clase resultante de una composición paralela se corresponde con una clase
que coordina el trabajo de varias clases, por lo que el comportamiento que de ella interesa
es el asociado a la función controladora. La clase agregada integra varias clases que son
consideradas como partes del todo que es la agregada.

157
Diagrama de clases.
Para las relaciones entre la clase compuesta y cada una de sus clases componentes, hay que
especificar la dimensiones Inclusiva/Referencial (I/R) y Estática/Dinámica (E/D). Estas
dimensiones se definen como:
Inclusiva La única clase que hace referencia a objetos del tipo componente es la
compuesta y solo un objeto del tipo de la agregada la referencia.
Referencial Un objeto del tipo de la clase componente puede ser referenciado por varios
objetos de otras clases e incluso de la misma clase a compuesta.
Estática Cuando se crea un objeto de la clase compuesta, el objeto de la clase
componente se mantiene sin cambiar su valor, independientemente de los
eventos que afecten la compuesta.
Dinámica Producto de eventos que afectan a la compuesta, puede cambiar el objeto
componente asociado a la compuesta.
Cuando dos clases se relacionan, ya sea por composición o por complejidad, hay que
especificar en ambos extremos de la relación las cardinalidades máximas y mínimas
(<máximas, mínimas>)
En dependencia de los valores de la cardinalidad se pueden definir otras 4 dimensiones
relativas a la relación entre componente-compuesta, componente-compleja y viceversa.
Estas dimensiones son:
componente-compuesta, componente-compleja
Flexible/Estática Cuando la cardinalidad mínima es exactamente 0 ó >=1,
respectivamente.
Disjunta/No Disjunta Cuando la cardinalidad máxima es 1 ó >1, respectivamente.

compuesta-componente, compleja-componente
Flexible/Estática Cuando la cardinalidad mínima es exactamente 0 ó >=1,
respectivamente.
Disjunta/No Disjunta Cuando la cardinalidad máxima es 1 ó >1, respectivamente.
En la realización del DC se siguen los siguientes pasos:
1. Una clase simple se representa directamente (Figura 1.2).

Habitación ocupada

Número Habitación ocupada

Piso
Fecha

Figura 7.2 Representación de clases simples

2. Revisar las asociaciones de Generalización/Especialización para representar la herencia.
Se debe indicar el atributo del padre y el valor que toma, cuando el padre se especializa
en cada hija. Si éste atributo no existe en la definición de la clase padre, se añade.
Además se especifica si las herencias que se derivan del padre son total/parcial y con o
sin solapamiento (Figura 7.3).

158
 Habitación Habitación ocupada

Número Fecha
Piso
Tipo
Estado

Habitación

{estado=ocupada} Total=Falso
Solapamiento=Falso
Habitación Ocupada

Figura 7.3 Representación de la herencia.

3. Identificar y representar clase compuestas, especificando la cardinalidad y las

dimensiones Inclusiva/Referencia y Estática/Dinámica (Figura 7.4). Para la
cardinalidad se deben tener en cuenta las siguientes recomendaciones:
 En el extremo de la clase compuesta como mínimo la cardinalidad es <1,1>.
 En el extremo de la clase componente la cardinalidad mínima por defecto es 1, la
máxima depende de:
 Si no es una agrupación es 1.
 Si es una agrupación es m.
 Si la clase compuesta tiene más de un atributo de igual tipo de clase, la
relación es con la clase y con la cardinalidad máxima igual a la cantidad de
atributos iguales.
Estos valores por defecto son lo mínimos que se pueden tomar a partir de las relaciones
reflejadas en la definición de las clases.

159
 Reservación

Habitacion: Habitación ocupada

Turista: Huésped
Fecha llegada: Fecha
Cantidad de días: Entero

Huésped Habitación ocupada

<1,1> <1.1>
{I,E} {R,D}
<1,1> <1,1>

Reservación

Figura 7.4 Representación de clases compuestas.

4. Identificar y representar las clases complejas, especificando la cardinalidad (Figura
7.5). Son válidas las recomendaciones anteriores en cuanto a la cardinalidad, excepto en
el extremo de la compleja que es <0,1>.

Un Accostumed es un huésped que estuvo con anterioridad en el hotel, por lo que

tiene las mismas características, pero aãnde la lista de todas la habitaciones en las
que estuvo con anterioridad.

Accostumed

Habitaciones: Lista de habitaciones

<0.m> <1,m>
Accostumed Habitación

Figura 7.5 Representación de clases complejas.

160
Uniendo todas las partes utilizadas en para ejemplificar los pasos en la obtención del DC, se
obtiene el DC de la figura 7.6.

<1.1>
Habitación <0,m> Huésped

{estado=
{estuvo=sí}
ocupada} <1,m>
Habitación ocupada Accostumed

<1.1> {R,D} {I,E}

<1,1> <1,1>

Reservación

Figura 7.6 DC resultante.

Diagrama de transición de estado (DTE).

Para mostrar la dinámica del comportamiento de un sistema, se ha hecho uso durante años
de los diagramas de transición de estado (DTE). En ADOOSI Visual se recomienda
realizarlos para aquellas clases que posean atributos dinámicos pues en función de estos es
que están los posibles estados por los que transita un objeto. Un DTE está compuesto por:
 Estado regulares.
 Estados agregados.
 Estados finales.
 Estados iniciales.
 Transiciones.
Un estado representa el período de tiempo durante el cual un objeto está esperando que
ocurra un evento que provoque su cambio. Los estados regulares contienen actividades a
desarrollar en el estado que requieren un tiempo de realización y restricciones de
integridad, que son reglas que especifican restricciones y requerimientos que debe afectar
tanto a la estructura como al comportamiento de los objetos de una clase y deben ser
tratados en métodos de la clase.
De los estados iniciales y finales salen o llegan transiciones, respectivamente, y tienen
como función indicar el inicio y fin del diagrama. Por lo tanto el estado inicial se

161
corresponde con la creación de la instancia de la clase correspondiente y el estado final con
la destrucción de ésta.
Las transiciones indican el paso de un estado a otro provocado por algún evento o de forma
instantánea. Tienen asociadas acciones (que son operaciones que se realizan
instantáneamente), eventos (es una lista de eventos que pueden provocar –o disparar- la
transición, relacionados entre sí por los operadores lógicos OR Y AND, y pueden estar
precedidos del operador lógico NOT) y condiciones (es una lista de condiciones
relacionadas entre sí de forma similar a los eventos, que serán evaluadas en el momento en
que se produzcan los eventos que dan lugar a la transición y ésta sólo será disparada si el
resultado de dicha evaluación es verdadera, de lo contrario se esperará a que ocurran
nuevamente los eventos). Para especificar una transición se sigue el siguiente formato:
[<clase que genera evento>]:<evento>[[condición]][/acción].
Los eventos pueden ser consecuencia de una operación que está dentro del dominio del
análisis (internos), resultado de una operación que es externa al dominio del análisis
(externos) o como resultado de una operación de reloj (temporal).
Los estados agregados contienen a otros estados y contribuyen a disminuir la complejidad
en el DTE. Están compuestos por restricciones que en este caso afectan a todos los
subestados que éste contiene. La descomposición en varios niveles es un tópico poco
definido en cuánto a cuáles criterios utilizar para agrupar, se recomiendan los estudios de
George Miller que indican la cantidad de 72 elementos por nivel y que lo general esté en
los niveles más altos y lo particular en los más bajos. Un criterio para agrupar podría estar
relacionado con los atributos, de manera que si existen varios eventos que afectan a un
mismo atributo ubicando al objeto en estados diferentes, con todos estos estados podría
definirse uno agregado. Otro criterio sería agrupar a estados que están fuertemente
acoplados, en el ejemplo de la figura 7.8 éste es el que se aplica.
Los diferentes niveles de diagramas, que surgen por el uso de los estados agregados, deben
estar balanceados en cuanto a las transiciones de entrada y salida cumpliéndose las
siguientes reglas:
 Para el caso de las transiciones de entrada es necesario que cada uno de los eventos en
Or de la lista de eventos de cada una de las transiciones entrada al estado agregado,
esté formando parte de la lista de eventos de al menos una de las transiciones que
parten del estado inicial.
Para el caso de las transiciones de salida debe cumplirse:
 Cada subestado tendrá una transición al subestado final.
 Cada transición hacia el subestado final, contendrá entre su lista de eventos las listas de
eventos de todas las transiciones de salida del estado agregado relacionadas entre sí por
el operador lógico OR.
Tanto las acciones como las actividades, son tareas a desarrollar en las que se puede usar el
lenguaje de especificación definido en UML.
La notación de DTE se muestra en la figura 7.7.

162
 Estado
Estado
Estado
inicial Transición Estado agregado
final
Figura 7.7 Notación del DTE.
Supongamos que en la automatización de un sistema de carpeta de un hotel se obtienen las
siguientes especificaciones. Un huésped puede solicitar con antelación una habitación
indicando el tipo de habitación que requiere, a partir de qué fecha y cuántos días. Por
diferentes motivos una habitación y el empleado que la atiende pueden cambiar, e incluso
antes de que el huésped comience a disfrutar de la reservación. Cuando lo que cambia es la
habitación, hay que verificar si la nueva habitación asignada pertenece a otro grupo
diferente al de la habitación precedente porque un empleado atiende a un solo grupo de
habitaciones. En caso de que pertenezca a otro grupo, hay que buscar al empleado que la
atiende.
Una vez que el huésped está en el hotel puede solicitar prórroga, pero sólo lo podrá hacer el
día que vence su reservación. Para un procesamiento estadístico posterior, se requiere
almacenar el hecho de que una reservación cambie (por cambio de habitación, empleado o
prórroga) o que se cancele. Si un huésped se va antes de que culmine su estancia, no es de
interés que el sistema se entere. La fecha de inicio de una reservación no puede cambiarse.
En la figura 7.8,7.9 y7.10 se muestra el DTE, y los diccionarios de datos que complementa
el diagrama; en el que se describen las transiciones y nodos, respectivamente
correspondientes a la clase reservación.

Figura 7.8 DTE.

163
Transición Descripción
T0 Carpetero:Cambia Habitación OR Cambia empleado/
New Modificación(‘cambia habitación o empleado’)
T1 Instántanea[Carpetero.Existehuespéd(Huésped dado)]
T2 (Carpetero:Huésped se va antes) OR (self:Vence reservación)
T3 Carpetero:Cambia Habitación OR Cambia empleado/
New Modificación(‘cambia habitación o empleado’)
T4 (Carpetero:Huésped cancela) OR (self.Vencefecha entrada)/
New Modificación(‘reservación cancelada’)
T5 Instantánea
T6 Carpetero:Llega huésped
T7 Carpetero:Huésped pide prórroga[Fecha actual=self:.Obtener día de salida]/
New Modificación(‘prórroga’)
T8 Instantánea
T9 Carpetero:Llega huésped
T10 Carpetero:Cambia habitación
T11 Carpetero:Cambia empleado
T12 Ama de llaves:Habitación pertenece a otro grupo
T13 Instantánea[not Carpetero.Existehuespéd(Huésped dado)]
T14 Instantánea
T15 Instantánea
T16 Instantánea
T17 Carpetero:Huésped cancela/New Modificación(‘reservación cancelada’)
T18 Carpetero:Cambia Habitación OR Cambia empleado/
New Modificación(‘cambia habitación o empleado’)
Figura 7.9 Diccionario de datos. Transiciones.
Nodo Actividades Restricciones
Cambiando Ama de llaves.Cambiar estado(Habitación ocupada) -
habitación Ama de llaves.Buscar habitación disponible (Tipo;Nueva habitación)
Habitación ocupada:=Nueva habitación
Ama de llaves.Cambiar estado(Habitación ocupada)
SI Ama de llaves.Devolver empleado (Habitación ocupada) <>
Empleado que lo atiende
SI J’Personal.Devolver estado(Empleado que lo
atiende)=ocupado
J’Personal.Cambia estado (Empleado que la atiende)
FINSI
J’Personal.Buscar empleado(Habitación ocupada;Nuevo
empleado)
Empleado que la atiende:=Nuevo empleado
SI J’Personal.Empleado a tope (Empleado que lo atiende)
J’Personal.Cambia estado (Empleado que la atiende)
FINSI
FINSI
Figura 7.10 Diccionario de datos. Nodos.

164
Nodo Actividades Restricciones
Cambiando SI J’Personal.Devolver estado (Empleado que lo atiende)=ocupado -
empleado J’Personal.Cambia estado(Empleado que la atiende)
FINSI
J’Personal.Buscar empleado(Habitación ocupada;Nuevo empleado)
Empleado que la atiende:=Nuevo empleado
SI J’Personal.Empleado a tope (Empleado que lo atiende)
J’Personal.Cambia estado(Empleado que la atiende)
FINSI
Esperando - -
huésped
Cancelando SI J’Personal.Devolver estado (Empleado que lo atiende)=ocupado -
reservación J’Personal.Cambia estado(Empleado que la atiende)
FIN SI
Ama de llaves.Cambiar estado(Habitación ocupada)
Disfrutando Carpetero.Registrar llamadas telefónicas not self.Vence
reservación Ama de llaves.Registrar servico de habitaciones reservación
Liquidando Ama de llaves.Cambiar estado(Habitación ocupada)
reservación SI J’Personal.Devolver estado (Empleado que lo atiende)=ocupado
J’Personal.Cambia estado(Empleado que la atiende)
FIN SI
Carpetero. Registrar estancia(Turista,Habitación ocupda)
Prorrogando Self.Modificar cantidad de días(Días)
reservación
Figura 7.10 Diccionario de datos. Nodos. (Continuación)

7.3.2- Transformación.

Dentro del proceso de normalización, el primer paso es eliminar atributos multivalores,

compuestos y sus combinaciones. Esta es precisamente una de las fortalezas del MOO. La
propuesta de conversión trata de no renunciar a esto y es por eso que lo definido en la 1FN
no se tiene en cuenta exactamente. En el epígrafe anterior se describió cómo se representan
estos atributos en el DC.
La 2FN se refería a que los atributos no llaves deben tener una dependencia funcionalmente
completa respecto a la llave. En la definición y refinamiento de las clases, desde la etapa de
análisis, los atributos de una clase se obtuvieron a partir del comportamiento a asociado a la
clase, por lo tanto los atributos de una clase no tienen dependencia incompleta. El tipo de
dato asociado a un atributo no atómico, tiene una definición de clase. Si hay problemas con
esto, el análisis no estuvo bien hecho.
En el caso de la 3FN, se exige que no existan atributos no llaves que dependan de otro no
llave. Este problema tampoco existe en la definición de las clases porque cuando una clase
requiere conocer atributos de otra clase, define una referencia (un atributo del tipo de esa
clase) y le envía mensajes a la clase solicitando la información que requiere.

165
Como se aprecia, no es necesario en éste módulo desarrollar los pasos incluidos dentro del
proceso de normalización aún cuando se implemente en un medio relacional porque el
proceso de obtención de las clases que modelen el problema a resolver permite obtener el
modelo conceptual. En las clases están incluidas consideraciones físicas, como, por
ejemplo, los atributos calculables.
Reglas para convertir el modelo objeto a tablas.
1. Cada clase con dominios simples se convierte en una tabla.
2. En el caso de la jerarquía de clase, se pueden aplicar tres posibilidades, aunque
recomendamos la última por estar más preparada para la evolución del esquema. Estas
posibilidades son:
a. Definir una única tabla con los atributos del padre y los atributos de cada hija. Esto
provoca que hay tuplas en las que existen campos cuyo valor no es de interés, pero
para otras tuplas sí lo es. Todos los campos de la tabla, que provienen de clase
hijas, tendrían que permitir el valor nulo, lo que afecta el chequeo de la restricción
de integridad por parte del gestor. En estos casos, el programador tendría que
definir los procedimientos necesarios para evaluar esto, en dependencia del valor
que tome el campo que especifica para esa tupla a cuál clase hija pertenece.
b. Definir una tabla para cada clase hija hoja que incluya los atributos de la clase
padre. Cuando la jerarquía es de más de dos niveles, ocurre lo mismo que en el
caso anterior. La ventaja de ésta forma está en la rapidez en la recuperación de
información.
c. Definir una tabla para cada clase hija y para cada clase padre. Para recuperar la
información de una clase hay que consultar la clase hija y sus ancestros.
3. Para clases complejas la conversión depende de las cardinalidades máximas en cada
extremo. Las cardinalidades mínimas introducen restricciones de integridad estática.
Las reglas que se aplican en estos casos son:
m:n Se convierte en una tabla que tiene como la llave las llaves de las clases
que conforman la relación.
1:m ó m:1 Se puede convertir en una nueva tabla o puede ser añadida una llave
extranjera al extremo m, que se corresponde con la llave de la clase del
extremo 1.
Ventajas de implementar como una tabla
 Está preparada para la evolución del esquema en caso de que se
transforme la relación a m:n.
 Menos complejidad en las búsquedas y actualizaciones de la relación.
 Se conserva la propiedad del encapsulamiento, clave en le enfoque
OO, ya que un objeto no debe conocer cosas de otro objeto si no es
necesario.
Ventajas de no implementar como una tabla

166
  Menos tablas.
 Más rápida la ejecución porque hay que navegar por menos tablas.
1:1 Se puede convertir en una nueva relación o se adiciona un nuevo campo a
alguna de las tablas que es la llave de la otra. Cada solución tiene las
mismas ventajas que en el caso de 1:m ó m:1.
c:m ó m:c En el caso de que en uno de los extremos exista en una cantidad mayor
que 1 de elementos con los que se relaciona la clase del extremo m, se
puede definir una nueva tabla que tenga como atributos llave, la llave del
extremo m y tantos atributos del tipo de la llave del extremo constante
como indique le valor de la constante. También se pueden adicionar a la
clase del extremo m, tantos campos del tipo de la llave del extremo
constante como indique el valor de la constante. Cada solución tiene las
mismas ventajas que en el caso de 1:m ó m:1.
c:c1 Se puede definir una nueva tabla que tendrá c+c1 llaves, en la que habrá
c campos del tipo de la llave del primer extremo, y c1 campos del tipo de
la llave del extremo. También se puede adicionar a la clase de uno de los
extremos, tantos campos del tipo de la llave del otro extremo como
indique el valor de la constante. Cada solución tiene las mismas ventajas
que en el caso de 1:m ó m:1.
En las relaciones de 1:1 y 1:m, sino hay ciclos, se puede tener en una sola tabla los
objetos que participan en la relación, pero esto viola la 2FN por lo que introduce
redundancia.
En el caso de las relaciones n-arias (n>2), se crea una tabla con las llaves de las clases
que intervienen y las cardinalidades se analizan como restricciones de integridad
estáticas.
A pesar de que no es necesario crear nuevas clases que reflejen la relación en casi
ningún caso, se recomienda hacerlo porque el esquema puede evolucionar y no sería en
estos casos necesario hacer cambios a la estructura de la BD, solo a las restricciones de
integridad estática asociadas a la cardinalidad.
4. Para las clases compuestas se crea una nueva tabla con el nombre de la clase
compuesta y que tiene como llave las llaves de las clases componentes. Las
cardinalidades se definen como restricciones de integridad estática.
Desde el punto de vista físico se puede particionar una tabla en más de una forma:
 Horizontal: Varias tablas iguales, pero cuyo nombre indica significados diferentes. Por
ejemplo. Enero, Febrero,..., Diciembre; serían tablas con igual estructura, pero que
reflejan los huéspedes que llegan al hotel cada mes.
 Vertical: Atributos con distintos niveles de acceso que provoca dividir una tabla en
varias con igual llave, pero atributos diferentes. Por ejemplo, Huésped General que
tiene DNI, Número de pasaporte y nombre, y Huésped Procedencia con DNI y País.

167
En el caso de que la implementación sea hacía un SGBDOR, que permita tener campos que
referencien a otro objeto, no es necesario que se cambie el tipo de éste campo para el tipo
de la llave de la clase a la que pertenece el objeto referenciado.

7.3.3- Utilización.

Cada gestor, ya sea relacional u objeto/relacional, implementa de diferentes formas las

características de los modelos relacional u objeto/relacional, respectivamente. Incluso
ninguno, en estos momentos, implementa completamente el modelo sobre el que se
construyó.
Es por ello que éste módulo lo que hace es estudiar las posibilidades del gestor que se va a
utilizar, para ver cuáles cosas permite implementar directamente y cuáles no. Aquellas
cosas que no es posible implementarlas directamente, habrá que definir los procedimientos
que garanticen que se tengan en cuenta. Por ejemplo, si no existe un predicado que permite
especificar un disparador, habrá que programarlo de acuerdo a las posibilidades del gestor e
invocarlo en todos aquellos momentos que se determine estén dadas las condiciones para
que se dispare.

7.3.4- Creador de métodos para clases persistentes.

Siempre que se posea un lenguaje OO asociado al gestor , es posible definir éste módulo.
Cuando se trabaja con un LPOO que permite relacionarse con un gestor de BD o con un
SGBDOR que incluye un lenguaje con características de la OO, podremos crear clases que
sirvan de interfaz entre la información almacenada y el resto de las clases no persistentes.
No se definen clases nuevas, sino que se parte de las mismas persistentes que se
transformaron en tablas, pero que tendrán métodos que permitan la relación con la
información almacenada, de manera que solo ellas tendrán acceso a las tablas. Esto
garantiza cumplir uno de los principios del enfoque OO que se refería a que un cambio
debe afectar al mínimo de clases posibles porque nadie conoce la implementación de una
clase.
A las clases persistentes hay que añadirle métodos que permitan:
 crear una tabla,
 destruir una tabla,
 incluir una tupla,
 eliminar una tupla,
 modificar una tupla y
 recuperar información de una tupla,
y que constituyen métodos privados implementados usando un lenguaje de consulta. El
resto de los métodos que tenían las clases, que se correspondían con servicios a ella
solicitados por objetos de otras clases, se especifican utilizando un lenguaje que se describe

168
en el epígrafe 7.4.2 en el que se invoca a los métodos anteriores cuando exista la necesidad
de trabajar con la información almacenada.

7.3.5- Creador de clases no persistentes.

Todas las clases definidas en la etapa de análisis no eran persistentes. Si se posee un

lenguaje OO, entonces estas clases se implementarían de acuerdo a la especificación a ellas
asociada y las características del lenguaje.
Las clases persistentes y no persistentes definidas se ubican en units o bibliotecas de clases,
de acuerdo a las consideraciones descritas en el epígrafe 7.2.1.

7.4- Implementación de los comportamientos estáticos y dinámicos.

En la implementación de estos comportamientos, sobre todo en el dinámico, es importante

clasificar los atributos de las clases teniendo en cuenta la forma y las causas por las que
toman valor en el tiempo. Por lo tanto se clasifican en atributos: estáticos (AE), dinámicos
(AD) y derivados (D).
Un atributo estático no cambia de valor en el tiempo por lo tanto no puede ser actualizado.
El único evento que lo afecta es el que provoca la creación de la clase que como
consecuencia le da valor.
A diferencia de los atributos estáticos, los dinámicos se reconocen porque son afectados por
otros eventos que son los que hacen que cambie de valor. Un mismo evento puede afecta a
varios atributos siendo para algunos singular y para otros recurrente. Por ejemplo, en el
evento publicación de un artículo, intervienen las clases artículo, autor y revista. Para la
clase artículo el evento es singular pues sólo una ocurrencia del evento la afecta pues un
artículo solo se publica una vez. Para las clases autor y revista es recurrente porque varios
eventos de éste tipo la afectan ya que un autor puede publicar varios artículo y en una
revista se publican varios artículos, respectivamente.
Los atributos derivados cambian cuando cambian otros atributos. Estos otros atributos
integran la fórmula de derivación y pueden pertenecer o no a la clase a la que pertenece el
atributo derivado. Los SGBD, cuando cambia alguno de los atributos que forman la
fórmula, deben automáticamente disparar el recálculo del valor derivado.

7.4.1- Vista estática.

En el DC que se realiza como parte del módulo de completamiento, se capturan varias de

las propiedades estáticas. En éste diagrama se representan:
 Todas las clases persistentes.
 Jerarquía de clases, con el atributo del padre y el valor que provocan la especialización
en una clase hija ({<atributo>=<valor>}).
 Relaciones entre las clases con sus cardinalidades mínimas y máximas
(<mínima,máxima>).

169
 Asociaciones de agregación, indicando las dimensiones Inclusiva/Referencial y
Estática/ ({I/R,E/D}).
Para que un objeto exista a un nivel dado de la jerarquía de clases, tiene que existir a todos
los niveles superiores. En el caso de las agregaciones ocurre algo similar, para que el objeto
agregado exista, tienen que existir todos los objetos que forman parte de la relación. En
ambos casos, lo inverso no tiene que ocurrir necesariamente.
Como se aprecia, el DC incluye la definición de restricciones de integridad estática a través
de las cardinalidades de las relaciones y las dimensiones {I/R,E/D}. El resto se capturan
textualmente especificando el dominio de los atributos indicando tipo de datos, si es llave o
no, si se puede tomar valor nulo, si es único, el rango, valor por defecto y fórmula de
derivación en caso de que la posea. Para cada clase padre en la jerarquía se debe aclarar si
la herencia es o no total y con o sin solapamiento. En la figura 7.11 Se aprecian las tablas
resultantes del ejemplo de la figura 7.6.
Campos Tipo Llave Único Nulo Llave Rango Valor Fórmula
Extranjera por de
defecto derivación
Número Entero Sí Sí No No 1..100 100 -
Piso Entero No No No No 3..40 40 -
Estado Enumerado No No No No Disp, 3000 -
Ocup
Tipo Enumerado No No No No S,D,SU S -
a)

Campos Tipo Llave Único Nulo Llave Rango Valor Fórmula

Extranjera por de
defecto derivación
DNI Cadena Sí Sí No No - 0 -
Nombre Cadena No No No No - X -
Estuvo Boolean No No No No V/F V -
Edad Entero No No Sí No 18..60 18 -
b)

Campos Tipo Llave Único Nulo Llave Rango Valor Fórmula

Extranjera por de
defecto derivación
DNI Cadena Sí Sí No No - 0 -
No. Cadena No No No No - 0 -
Pasaporte
Nombre Cadena No No No No - X -
País Cadena No No No No - X -
c)

Figura 1.11 Tablas resultantes. a) Habitación. b) Empleado. c) Huésped.

170
Campos Tipo Llave Único Nulo Llave Rango Valor Fórmula
Extranjera por de
defecto derivación
Habitación Entero Sí Sí No Sí 1..100 100 -
ocupada
Empleado Cadena Sí Sí No Sí 0 0 -
que la
atiende
Turista Cadena Sí Sí No Sí 0 0 -
Fecha de Fecha No No No No Fecha Fecha -
inicio actual.. actual
un año
despué
s
Cantidad de Entero No No No No 1..30 1 -
días
Monto a Real No No Sí No 1.. 3000 Habitación.
pagar 90000 Precio
noche*
Cantidad
de días
d)
Campos Tipo Llave Único Nulo Llave Rango Valor Fórmula
Extranjera por de
defecto derivación
DNI Cadena Sí Sí No No - 0 -
Habitación Entero Sí Sí No Sí 1..100 100 -
ocupada
e)
Campos Tipo Llave Único Nulo Llave Rango Valor Fórmula
Extranjera por de
defecto derivación
Número Entero Sí Sí No No 1..100 100 -
Fecha Fecha No No No No _ Fecha -
actual
f)
Figura 1.11 Tablas resultantes (Continuación). d) Reservación. e) Accostumed-Habitación.
f)Habitación ocupada
Producto de la descomposición, apareció una tabla Accostumed que solo se diferenciaba de
la clase padre en que no tenía el atributo “estuvo”, por lo que se decidió físicamente tener
dos tablas con igual estructura de nombres “Huésped” y “Accostumed”.
Las restricciones a columnas descritas anteriormente se corresponden con diferentes
categorías que han podido especificarse. Existen otras condiciones que deben satisfacerse y
que no es posible categorizarlas, por lo que se pueden definir como afirmaciones. Para
poder determinar la necesidad de estas restricciones al dominio, es necesario especificar

171
entonces, para todos aquellos atributos que lo requieran, reglas que indiquen qué valores
pueden tomar, o lo que es igual, qué condiciones deben cumplir los atributos. El formato
general para expresar estas restricciones sería:

<atributo>=<condición> En la condición hay que especificar las tablas

involucradas y se puede usar NOT, EXIST, funciones
de agregación, AND, OR, IN, BETWEEN.
Un ejemplo podría ser: se sabe que el No. de pasaporte de un huésped puede repetirse,
pero dentro de un mismo país es único. En SQL Server el predicado Check permite
especificarlas. Usando afirmaciones definidas en el SQL estándar, la condición especificada
como:
No. Pasaporte=NOT EXIST IN Huésped
Huéped.No pasaporte=Nuevo No pasaporte
, quedaría:
ASSERT Valida_pasaporte ON Huésped
NOT EXIST
(SELECT *
FROM Huésped
WHERE Huésped.No pasaporte=Nuevo No pasaporte)
Otra característica de un atributo que puede ser implementada de ésta forma, es cuando el
dominio restringe a un conjunto de valores predefinidos, que se pueden especificar usando
el tipo de dato enumerado. Este tipo de dato aparece en el estándar SQL3, por lo que aún
varios gestores no lo incluyen. Por ejemplo, para el atributo tipo de habitación quedaría:
ASSERT Válida_tipo ON Habitación
Tipo=’Suite’ OR Tipo=’Simple’ OR Tipo=’Doble’
, partiendo de la especificación Tipo=’Suite’ OR Tipo=’Simple’ OR Tipo=’Doble’.
Las afirmaciones se validan cada vez que se intente cambiar el valor de los atributos a los
que se asocia cada una. Su implementación dependen de los predicados que brinde el
lenguaje de definición de datos del gestor seleccionado.
Estas restricciones estáticas se pueden definir para cualquier atributo independientemente
de cómo se clasifiquen.

7.4.2- Vista dinámica.

Precondiciones

Del DTE se pueden obtener directamente las precondiciones que deben cumplirse para que
ocurra un cambio de estado. Esta precondiciones quedan reflejadas, en la descripción de las
transiciones, como la unión del evento que ocurre y las condiciones que deben evaluarse
para provocar el cambio. Las restricciones que tienen los estados se deben cumplir para que

172
el objeto se mantenga en ese estado, por lo tanto lo contrario de una restricción tiene que
ser una condición de alguna de las transiciones de salida que se deriven de ese estado.
Evaluación

En la descripción de las actividades que se ejecutan cuando se está en un estado, están

definidos los pasos que se efectúan para dar un nuevo valor a él o los atributos dinámicos
que se afectan (los estados “cambiando habitación” y “cambiando empleado” son ejemplos
puros de esto) y también se pueden incluir las acciones que se están haciendo mientras el
objeto está en ese estado (el estado “disfrutando reservación” es un ejemplo puro de esto).
En ésta descripción se puede identificar el o los atributos que se modifican pues,
directamente o como parte de un método de la clase, se utiliza una asignación en la que en
la parte izquierda está un atributo de la clase, y en la derecha el nuevo valor.
OO-Method propone, como definición del modelo funcional, la obtención de las fórmulas
de evaluación para los atributos variables (en éste caso dinámicos). Las fórmulas de
evaluación describen los posibles valores que puede tomar un atributo, a partir de un
estado dado, y cómo se determina ese nuevo valor.
El punto de partida es clasificar estos atributos en:
a. Cardinales: el efecto en el atributo es el incremento/decremento en 1 o una cantidad
dada.
Ej.: atributo – Cantidad de días
Acción Acción Acción Condición Efecto de
incrementadora decrementadora reinicializadora la acción
Carpetero: Huésped - - - +Días
pide Prórroga
Si en éste ejemplo se define que un huésped no puede solicita prórroga si lleva
hospedado más de 7 días, entonces en la columna condición se podría Cantidad de días
<= 7.
b. Característicos de un estado: el atributo adquiere un valor que es independiente del
valor que haya tenido con anterioridad.
Ej.: atributo – Habitación ocupada (refleja el número de habitación asignada a un
huésped).
Acción portadora Efecto de la acción
Carpetero: Cambia habitación Ama de llaves.Buscar habitación disponible
(Tipo; Nueva habitación)
:= Nueva habitación

c. Perteneciente a una situación: toman valor en un dominio limitado. El nuevo valor

dependen del valor anterior, es decir, estando en un
estado dado solo se pueden tomar determinados valores.

173
 En el caso de la reservación no hay ningún atributo con estas características. El
ejemplo clásico es el atributo estado civil.
Valor actual Acción portadora Nuevo valor
- Registro civil: Nacer Soltero
Casado Notario: Divorciar Divorciado
Casado Registro civil: Enviudar Viudo
Not casado Notario: Casar Casado
Las acciones se corresponden con los eventos definidos en el DTE. En los casos del tipo a y
b, el efecto de la acción está descrito dentro de las acciones a ejecutar en el estado. Para los
atributos clasificados como c, la especificación describe restricciones de integridad
dinámica de la clase que se obtiene cuando se sigue la traza de las transiciones de estado
que están asociadas con un mismo atributo.
Para facilitar la identificación de estas fórmulas, recomendamos que cuando se realice el
DTE se:
 Clasifique los atributos dinámicos en alguna de estas tres categorías antes de empezar.
 Si el atributo es del tipo a, se identifiquen los eventos que lo afectan teniendo en cuenta
cuáles aumenta su valor, cuáles lo decrementan y cuáles lo reinicializan. Se deben
agrupar todos los eventos que tengan el mismo efecto y el mismo tipo de acción
(incrementadora, decrementadora y reinicializadora), y definir un estado que refleje
esta situación. Si hay más de un evento en está unión, se relacionan usando el operador
OR.
 Si el atributo se clasifica del tipo b, una vez identificados los eventos y el efecto que
provocan, se agrupan usando OR los eventos que provocan una misma forma de
obtener el nuevo valor, y se define un estado para ellos.
 Si el atributo es del tipo c, se identifican todos los eventos, el nuevo valor que
provocan y el valor del atributo para el cual ese evento tiene sentido. Se definen tantos
estados, como posibles valores existan.
Si se tiene en cuenta la 1ra de las recomendaciones en cuanto a particionamiento que se
daba en el epígrafe 7.3.1, los atributos clasificados como a y c son fuente para definir
estados agregados.
Una vez procesados todos los atributos dinámicos de todas las clases, se tienen todas las
fórmulas de evaluación.

Disparadores

Una forma de mantener la integridad de los datos es definir disparadores. Es importante

tener claro a qué nos referimos cuando se dice “disparador’ pues en ocasiones se tiende a
usar la frase “se dispara” o “disparo” , y esto no tiene implícito un mecanismo de disparao.

174
Un disparador es una sentencia que el sistema ejecuta automáticamente como efecto
secundario de una modificación de la BD, tal como vimos en el epígrafe 1.4.3.
Es lógico que nos sea difícil obtener disparadores del DTE pues no siempre un cambio de
estado tiene como antecedente o evento que lo provoque, un valor especifico de uno o
varios atributos. El DTE no es la fuente natural. Un mecanismo de disparo entra a funcionar
cuando en una tabla se adicionan o elimina elementos o cuando un atributo dado toma un
valor determinado. Es por ello que en la especificación de estos mecanismos lo primero es
dejar claro el hecho qué lo provoca (Insert - adición, Delete - eliminación o Update -
modificación) y sobre quién se evalúa (nombre de la tabla, para las dos primeras
operaciones, y nombre de la tabla, atributo y valor, para el caso de la modificación). Lo
segundo es definir las acciones que se ejecutan como consecuencia, para lo cual se puede
usar también la notación UML.
La captación del mecanismo de disparo sería para estos casos textual. La especificación
tendría el siguiente formato:
<causa que lo provoca><tabla>:[condición]/<acción>
Algunos gestores, como Oracle, cuando se define un disparador se pregunta además si ese
disparador debe ejecutarse antes o después que se produzca el cambio que hace que se
cumpla la condición. Por lo que a esta especificación podría añadírsele al final
{antes/después}. Si se define antes, primero se ejecutan las acciones asociados al
disparador y después se produce el cambio. Si se especifica después, ocurre lo contrario.
En el DTE del ejemplo los cambios de estado de las transiciones T2 y T4 están
relacionados con el valor de un atributo, pero no se deben a una actualización de la BD por
lo que no se genera un disparador. Supongamos que se desea avisar a los huéspedes el día
antes que vence su reservación. Esto es un proceso automático que se verifica todos los días
y como consecuencia se envía una nota informándole de la situación por si desea solicitar
prórroga. El mecanismo no se activa por un cambio en la tabla reservación, sino en la fecha
actual. Para representar esto usando disparadores, se podría crear una tabla Fecha con un
atributo fecha actual que al actualizarse dispare el envío de esta notas. La especificación
sería:
UPDATE Fecha: IF UPDATE Fecha actual/Reservación.Envía nota
, el disparador que se genera tendría la siguiente definición en SQL Server:
CREATE TRIGGER Vencen
ON Fecha
FOR UPDATE
AS
IF UPDATE Fecha actual
ALL(Reservación.Envía nota)
El procedimiento “Envía nota” verifica cuáles reservaciones vencen al día siguiente, y
genera la comunicación hacía los huéspedes.
Algunas transiciones tienen asociadas acciones. Hay ocasiones en que estas acciones
podrían implementarse como las acciones definidas en el disparador. En estos casos la
causa sería la modificación (UPDATE) de el o los atributos que se afectan cuando se pasa

175
al nuevo estado. La propiedad antes/después tomaría el valor de antes. Esto es válido
cuando ocurre algo de lo siguiente:
 Solo hay un estado y una transición que llega a ese estado, para el o los atributos
afectados.
 Solo hay un estado relacionado con el cambio de el o los atributos y todas las
transiciones que llegan a él tienen asociadas las mismas acciones.
 Hay varios estados relacionados con el cambio de el o los atributos y todas las
transiciones que llegan a ellos tienen asociadas las mismas acciones.
Las acciones instantáneas que se producen como parte de las transiciones T0, T3, T7 y T18;
podrían haberse definido como reglas de disparo. Cada vez que se modifica alguna de los
siguientes atributos: habitación, empleado o cantidad de días; se inserta automáticamente
una tupla a la tabla Modificación. Es responsabilidad del diseñador, en caso de no poseer
una herramienta CASE que lo verifique, garantizar que no se duplique la especificación,
pues éste disparador se obtiene directamente del DTE. Fíjese que en el caso de T4, como el
evento no provocó un cambio de los valores de los atributos de ésta clase, no se genera el
mecanismo de disparo por lo que hay que definirlo.

Derivación

Las fórmulas de derivación, de los atributos clasificados como derivados, se definen

textualmente utilizando los operadores matemáticos necesarios, valores constantes (por
ejemplo, si es el doble de un atributo sería 2*<atributo>) y atributos (pueden ser de la clase
a la que pertenece el atributo derivado o de otra clase, en cuyo caso hay que especificar de
cuál <nombre de la clase>.<nombre del atributo>).

Especificación de métodos

Como se ha planteado anteriormente se propone utilizar en la especificación de acciones,

actividades y métodos de las clases, el lenguaje de especificación definido en UML (Figura
7.11).
Tipo Sintaxis
Asignación <destino>:=<expresión>
Llamada <nombre del método con la referencia a la clase>[(argumentos)]
Creación New <nombre de la clase> [(argumentos)]
Destrucción <objeto>.destroy()
Retorno Return <valor>
Envío Igual a sintaxis de llamada, pero crea un evento del tipo señal. En la

176
 llamada el evento espera por una respuesta.
Terminación Destruye el objeto
No Lenguaje de especificación propio para representar otras construcciones.
interpretado

Figura 7.11 Lenguaje de especificación de UML.

En el caso de que el método a ejecutar sea de la propia clase a la que se corresponda el
DTE, se sustituye el nombre de la clase por self. Cuando un mensaje se envía a todas las
clases, se sustituye el nombre por ALL.
Como se aprecia en la figura 7.11, hay que definir un lenguaje para especificar otras
construcciones como las decisiones, selección y repetición. En estos casos se podría utilizar
un subconjunto del lenguaje natural como el siguiente:
 Decisión
SI <condición>
<acciones>
[sino
<acciones>]
FIN SI
 Selección
SELECCIONAR CASO
<nombre del caso>[<condición>]:<acciones>
.
.
.
[otro caso:<acciones>]
FIN CASO
 Repetición
 PARA CADA [<condición>] DE <nombre de la clase>
<acciones>
FIN CADA
Si no se pone la condición, las acciones se ejecutan para todos los objetos de la
clase. La condición restringe el subconjunto de objetos sobre los cuales se ejecutan
las acciones indicadas.
 MIENTRAS <condición>
<acciones>
FIN MIENTRAS
 REPETIR
<acciones>
HASTA <condición>

177
En la descripción se pueden usar las funciones de agregación: contar, sum (sumar), avg
(promedio), máx (máximo) y mín (mínimo), indicando sobre qué elementos se hacen
efectivas. Contar actúa sobre una clase contando la cantidad de objetos definidos, el resto
actúa sobre un atributo numérico en particular. En todos los casos da como valor un
número. Se puede especificar una condición que restringe la cantidad de objetos que se
analizan. El formato de la especificación sería:
<función de agregación> (<clase o clase.atributo>) [[condición]]

7.5 – Ejemplo de implementación en un entorno relacional.

Registro de calificaciones para una liga infantil de gimnástica masculina.

Se desea crear un sistema automatizado de registro de calificaciones para una liga infantil
de gimnástica masculina. Los niños deben pasar por todas las áreas de competencia. Las
áreas establecidas son: caballo con arzones, paralelas, ejercicios a manos libres, barras fijas,
caballo de salto y anillas. Solo hay un área de competencia por ejercicio.
Durante el encuentro se llevan a cabo simultáneamente pruebas en todas las áreas de
competencia. Los concursantes se dividen en grupos y cada grupo comienza en un área,
pero rota por todas las áreas.
Se asignan 5,7 ó 9 jueces por área y una anotador por cada una que toma las calificaciones
dadas por cada juez, elimina la más alta y la más baja, y calcula el promedio de las restantes
para determinar la calificación del niño en esa área. Un juez solo puede serlo de un área,
pero por diversas razones dentro de la competencia se puede cambiar algún juez de un área.
Cuando estos cambios ocurren se debe almacenar el área en que ocurrió y el instante de
tiempo en que se produjo.
Al final de la competencia, se suma para cada concursante la calificación obtenida en cada
ejercicio y se ordenan de mayor a menor para obtener los máximos acumuladores.
Como resultado del análisis se obtuvo lo siguiente:

178
Definición de clases
Nombre Atributos Responsabilidades Colaboradoras Colaboraciones
Concursante  Nombre:cadena  Devolver acumulado total - -
 Acumulado (;Acumulado).
total:real  Crear concursante
 Pais:cadena (NombreConcursante,
 DNI:cadena PaísConcursante, DNIConcursante).
 Eliminar concursante.
 Averiguar si es uno dado
(DNIConcursante;V/F)
 Actualizar acumulado total
(Acumulado)
 Devolver nombre (;Nombre)
Lista de  Cantidad:entero  Incluir concursante Concursante  Devolver acumulado total
concursantes  Identificador del NombreConcursante, (;Acumulado).
primer PaísConcursante,DNIConcursante)  Crear concursante
concursante:  Ordenar concursante de acuerdo a (NombreConcursante,
Concursante acumulado total en orden descendente. PaísConcursante,
 Eliminar concursante. DNIConcursante).
 Actualizar Acumulado total  Eliminar concursante.
(DNIConcursante,Acumulado)  Averiguar si es uno dado
(DNIConcursante;V/F)
 Actualizar acumulado total
(Acumulado)

179
Nombre Atributos Responsabilidades Colaboradoras Colaboraciones
Calificación  EjercicioC:  Crear calificación Ejercicio  Devolver nombre
Ejercicio (EjercicioDato,ConcursanteDato, (;NombreEjercicio)
 Puntuación:Real PuntuaciónDato).
 ConcursanteC:  Devolver puntuación (;Puntuación, Concursante  Averiguar si es uno dado
Concursante DNIConcursante). (DNIConcursante;V/F)
 Eliminar calificación.  Devolver nombre (;Nombre)
 Averiguar si es una dada
(DNIConcursante,
NombreEjercicio;V/F).
Lista de  Cantidad  Incluir calificación Calificación  Crear calificación
calificaciones  Identificador (EjercicioDato,ConcursanteDato, (EjercicioDato,
de la primera PuntuaciónDato). ConcursanteDato,
calificación  Eliminar PuntuaciónDato)).
calificaciones(DNIConcursante,  Devolver puntuación
NombreEjercicio). (;Puntuación, DNIConcursante).
 Calcular acumulado total de todos los  Eliminar calificación.
concursantes.  Averiguar si es una dada
(DNIConcursante,
NombreEjercicio;V/F).
Lista de  Actualizar calificación total
concursantes (DNIConcursante, Acumulado).

180
Nombre Atributos Responsabilidades Colaboradoras Colaboraciones
Ejercicio  Nombre:cadena  Crear Ejercicio (NombreDato, - -
 Características: CaracterísticasDato).
cadena  Eliminar ejercicio.
 Devolver nombre (;Nombre).
Área  EjercicioA:  Actualizar calificación de un juez Lista de jueces  Incluir juez
Ejercicio (CalificaciónDato,DNIJuez). (NombreJuez,PaísJuez,
 Jueces Lista de  Calcular calificación total DNIJuez,CompetenciasDato).
jueces (;Calificación total).  Eliminar juez dado (DNIViejo)
 Cantidad de  Crear área (NonbreDato,  Eliminar jueces.
jueces: Entero CaracterísticasDato, Cantidad de  Calcular calificación Total
 Cantidad de jueces Dato,JuecesDato). (;Calificación total).
calificaciones  Eliminar área.  Limpiar calificaciones.
reportadas:  Limpiar calificaciones.  Actualizar calificación de un
Entero  Averiguar si es un área dada juez
 Ubicación: (NombreEjercicio). (CalificaciónDato,DNIJuez).
caracter  Cambiar juez  Listar curriculum de jueces.
(DNIVIejo,NombreJuez,PaísJuez,DNI Ejercicio  Devolver Nombre (;Nombre).
Juez).  Crear Ejercicio (NombreDato,
 Listar curriculum de jueces. CaracterísticasDato).
 Eliminar ejercicio.
Lista de  Cantidad:Entero  Listar curriculum. Competencia  Devolver datos (;Nombre,
competencias  Identificador de  Incluir competencias Categoría).
la 1ra (NombreDato,CategoríaDato).  Crear (NombreDato,
competencia: CategoríaDato).
Competencia

181
Nombre Atributos Responsabilidades Colaboradoras Colaboraciones
Competencia  Nombre:Cadena  Devolver datos (;Nombre, Categoría). - -
 Categoría:  Crear (NombreDato, CategoríaDato).
Cadena
Lista de áreas  Cantidad  Incluir área (NonbreDato, Área  Actualizar calificación de un
 Identificador de CaracterísticasDato, Cantidad de juez
la primera área jueces dato). (CalificaciónDato,DNIJuez).
 Eliminar área (NombreEjercicio).  Calcular calificación total
 Actualizar calificación de un juez en (;Calificación total).
un área (CalificaciónDato, DNIJuez,  Crear área
EjercicioDato). (EjercicioDato,Cantidad de
 Calcular calificación total en un área jueces Dato,JuecesDato).
(Área;Calificación total).  Eliminar área.
 Limpiar calificaciones en un área  Limpiar calificaciones.
(NombreEjercicio).  Averiguar si es un área dada
 Cambiar juez (NombreEjercicio, (NombreEjercicio).
DNIVIejo,NombreJuez,PaísJuez,  Cambiar juez
DNIJuez). (DNIVIejo,NombreJuez,PaísJue
 Listar curriculum. z,DNIJuez).
 Listar curriculum de jueces.
Comisión  AnotadorC:  Controlar resultados de la Anotador  Controlar resultados de la
organizadora Anotador competencia. competencia.
 Concursantes:  Obtener máximos acumuladores  Obtener máximos acumuladores
Lista de  Preparar condiciones para la Lista de  Incluir concursante
concursantes competencia. concursantes NombreConcursante,
 Áreas: Lista de  Inicio competencia PaísConcursante,
áreas DNIConcursante)
 Empezó:boolean  Eliminar concursante.

182
Nombre Atributos Responsabilidades Colaboradoras Colaboraciones
Comisión Lista de áreas  Incluir área (NonbreDato,
organizadora CaracterísticasDato, Cantidad de
jueces dato).
 Eliminar área (NombreEjercicio).
 Listar curriculum.
 Cambiar juez (NombreEjercicio,
DNIViejo,NombreJuez,PaísJuez,
DNIJuez).
Juez  Puntos:Real  Devolver calificación (;Puntos). Lista de  Listar curriculum.
 Nombre:Cadena  Crear juez competencias  Incluir competencias
 País:Cadena (NombreDato,PaísDato,DNIDato, (NombreDato,CategoríaDato).
 Competencia: CompetenciasDato).
Lista de  Eliminar juez.
competencia  Actualizar calificación (Puntos).
 DNI  Limpiar calificación.
 Listar curriculum
 Averiguar si es uno dado (DNIJuez;
V/F).
Lista de  Cantidad:Entero  Incluir juez Juez  Devolver calificación (;Puntos).
jueces  Identificador del (NombreDato,PaísDato,DNIDato,  Crear juez
primer juez:Juez CompetenciasDato). (NombreDato,PaísDato,DNIDato,
 Eliminar juez dado (DNIViejo) CompetenciasDato).
 Calcular calificación Total  Eliminar juez.
(;Calificación total).  Actualizar calificación (Puntos).
 Limpiar calificaciones.  Limpiar calificación.
 Actualizar calificación de un juez  Listar curriculum
(CalificaciónDato,DNIJuez).  Averiguar si es uno dado
 Listar curriculum de jueces. (DNIJuez; V/F)..

183
Nombre Atributos Responsabilidades Colaboradoras Colaboraciones
Anotador  ConcursantesA  Controlar resultados de la Lista de  Ordenar concursante de acuerdo a
: Lista de competencia. concursantes acumulado total en orden
concursante  Obtener máximos descendente.
 ÁreasA: Lista acumuladores. Lista de  Incluir calificación
de áreas calificaciones (EjercicioDato,ConcursanteDato,
 Calificaciones PuntuaciónDato).
A: Lista de  Eliminar calificaciones
calificaciones (DNIConcursante,
NombreEjercicio).
 Calcular acumulado total de todos
los concursantes.
Lista de áreas  Actualizar calificación de un
juez en un área
(Calificación,Ejercicio).
 Calcular calificación total en un
área (Área;Calificación total).
 Limpiar calificaciones en un
área (Ejercicio).

184
Asociaciones
Tipo Clase Clase asociada
Composición paralela Comisión organizadora Anotador
Lista de áreas
Lista de concursantes
Anotador Lista de áreas
Lista de concursantes
Lista de calificaciones
Agregación Calificación Ejercicio
Concursante
Juez Lista de competencias
Área Lista de jueces
Ejercicio
Agrupamiento Lista de calificaciones Calificación
Lista de jueces Juez
Lista de concursantes Concursante
Lista de áreas Área
Depende de Calificación Lista de calificaciones
Ejercicio Área
Juez Lista de jueces
Concursante Lista de concursantes
Área Lista de áreas
Lista de concursantes Comisión organizadora
Lista de áreas Comisión organizadora
Anotador Comisión organizadora
Lista de concursantes Anotador
Lista de áreas Anotador
Lista de calificaciones Anotador
Lista de jueces Área
Lista de concursantes Lista de calificaciones

185
Tipo Clase Clase asociada
Competencia Lista de competencias
Lista de competencias Juez
Tiene conocimiento de Lista de calificaciones Calificación
Lista de concursantes Concursante
Lista de áreas Área
Calificación Ejercicio
Calificación Concursante
Área Ejercicio
Lista de competencias Competencia
Juez Lista de competencias
Lista de jueces Juez
Analogía Concursante
Juez

186
Solución
Estática
Clases persistentes Clases no persistentes
Ejercicio Comisión organizadora
Concursante Anotador
Lista de concursantes
Área
Lista de áreas
Competencia
Lista de competencias
Calificación
Lista de calificaciones
Juez
Lista de jueces
De las clases persistentes se clasifican en simples: Ejercicio, Concursante y Competencia;
como compleja a la clase Juez y como compuesta a las clases Área y Calificación. Las
llaves de estas clases se muestran en la tabla de la figura 7.12.
Clase Llave Llave extranjera
Ejercicio Nombre No
Competencia Nombre No
Juez DNI No
Área NombreEjercicio Sí
DNIJuez Sí
Concursante DNI No
Calificación DNIConcursante Sí
NombreEjercicio Sí
Figura 7.12 Llaves
A partir de la definición de clases obtenida del análisis, se puede definir una nueva clase
que incluya el comportamiento y los atributos comunes de las clases análogas Concursante
y Juez. Esta nueva clase podría llamarse Persona. Las definiciones de las clases hijas se
modificarían, quedando estas tres clases de la siguiente forma:
Clase Atributos Responsabilidades
Persona  DNI  Crear (NombreDato,DNIDato,PaísDato).
 Nombre  Eliminar.
 País  Devolver nombre (;Nombre).
 Averiguar si es uno dado (DNIDato;V/F).

187
Clase Atributos Responsabilidades
Concursante  Acumulado  Crear (NombreDato,DNIDato,PaísDato).
total  Devolver acum,ulado total(;Acumulado).
 Actualizar acunulado total (Acumulado).
Juez  Puntos  Crear (NombreDato,DNIDato,PaísDato, Competencias
 Competencias Dato).
 Eliminar.
 Actualizar calificación (PuntosDatos).
 Limpiar calificación.
 Listar curriculum.
Como se aprecia en ésta definición, hay métodos que pasan a la clase padre, pero los
métodos crear y y eliminar requieren redefinirse en al menos uno de los hijos. Esta
definición, más el resto de las obtenidas en el análisis y que no sufrieron cambio, permiten
obtener el DC de la figura 7.13.

Persona
{ocupación=’concursante’} {ocupación=’juez’}

<1,m> <0,m>
Concursante Juez Competencia
<1,1> <5,9>
{I,E} <0,6>

Calificación
{R,E} <0,m>
{I,D} <1,1>
<1,1>
{R,E} Área
Ejercicio
<1,1><1,1>

Figura 7.13 Diagrama de clases.

Los atributos de las clases requieren una especificación más detallada de su dominio,
teniendo en cuenta en 1er lugar un conjunto de propiedades categorizadas que permiten las
siguientes especificaciones:
Clase: Persona
Atributo Tipo Único Nulo Rango Valor por Fórmula de
defecto derivación
DNI (AE) Cadena Sí No - 0 -
Nombre (AE) Cadena No No - X -
País (AE) Cadena No No - X -

188
Clase: Concursante
Atributo Tipo Único Nulo Rango Valor por Fórmula de
defecto derivación
Acumulado total Real No Sí [0,60] 0 Suma de todas
(D) las calificaciones
del concursante

Clase: Juez
Atributo Tipo Único Nulo Rango Valor por Fórmula de
defecto derivación
Puntos (AD) Real No Sí [0,10] 0 -
Competencias Lista de No Sí - Nil -
(AE) competencias

Clase: Ejercicio
Atributo Tipo Único Nulo Rango Valor por Fórmula de
defecto derivación
Nombre (AE) Cadena Sí No - X -
Descripción Cadena Sí No - X -
(AE)

Clase: Área
Atributo Tipo Único Nulo Rango Valor por Fórmula de
defecto derivación
EjercicioA (AE) Ejercicio Sí No - - -
JuecesA (AD) Lista de Sí No - - -
jueces
Cantidad de Entero No No [5,9] 5 -
jueces (AE)
Cantidad de Entero No Sí [0,9] 0 -
calificaciones
reportadas (AD)
Ubicación (AE) Carácter Sí No [I,VI] I -

Clase: Calificacion
Atributo Tipo Único Nulo Rango Valor por Fórmula de
defecto derivación
EjercicioC (AE) Ejercicio Noí No - - -
ConcursanteC Concursante No No - - -
(AE)
Puntos (AE) Real No No [0,10] 0 -

189
Clase: Competencia
Atributo Tipo Único Nulo Rango Valor por Fórmula de
defecto derivación
Nombre (AE) Cadena Sí No - X -
Categoría (AE) Enumerado No No [I,V] V -

Posteriormente hay que verificar si existen otras restricciones asociadas a los dominios que
no quedan reflejadas en las categorizadas anteriores. En éste ejemplo, no está
explícitamente descrito en la estructura estática que el valor máximo que puede tomar el
atributo Cantidad de calificaciones reportadas es el valor que tenga el atributo Cantidad de
jueces (ambos atributos de la clase Área). Como posteriormente se verá, en el DTE queda
más clara ésta restricción porque está relacionada con los cambios de estado. Es por ello
que no es necesario especificar ésta restricción de otra forma.
El atributo categoría de la clase Competencia, puede ser implementado como una
restricción si el gestor no permite éste tipo de dato. La especificación sería:
Categoría=’I’ OR Categoría=’II’ OR Categoría=’II’ OR Categoría=’IV’ OR
Categoría=’V’ ;
que usando las afirmaciones de SQL standard quedaría implementado como:
ASSERT Valida_categoría ON Competencia
Categoría=’I’ OR Categoría=’II’ OR Categoría=’II’ OR Categoría=’IV’ OR
Categoría=’V’
Supongamos que la ubicación de un área, dentro del área total de competencia, depende del
ejercicio puesto que en los alrededores del ‘área destinada a la competencia de manos
libres, no puede competirse en Caballo con arzones y Caballo de salto. La comisión
organizadora divide el área en 6 partes (I,II,...VI) y señala el área I como la destinada a
Ejercicios a manos libres. Para garantizar ésta restricción hay que validar que la ubicación
de los ejercicios caballo de salto y caballo con arzones no sean ni II ni III. La especificación
quedaría:
Ubicación = SI (Area.EjercicioA.DevolverNombre=’Caballo con arzones’) OR
(Area.EjercicioA.DevolverNombre=’Caballo de salto) IN Area
Area.Ubicación IN [IV,V,VI]
Fin si
La implementación de ésta restricción depende de las potencialidades del lenguaje del
gestor pues incluye una evaluación de una condición ya que la restricción no es válida para
todos los objetos de la clase.
Al aplicar las reglas de transformación descritas se obtienen las siguientes tablas:

190
Tabla: Persona
Atributo Tipo Llave Único Nulo Llave Rango Valor por Fórmula de
extranjera defecto derivación

DNI (AE) Cadena Sí Sí No No - 0 -

Nombre (AE) Cadena No No No No - X -
País (AE) Cadena No No No No - X -
Ocupación (AE) Enumerado No No No No Concursante
Juez
Tabla: Concursante
Atributo Tipo Llave Único Nulo Llave Rango Valor por Fórmula de
extranjera defecto derivación
Acumulado total Real No No Sí No [0,60] 0 

(D)
Tabla: Juez
Atributo Tipo Llave Único Nulo Llave Rango Valor por Fórmula de
extranjera defecto derivación
Puntos (AD) Real No No Sí No [0,10] 0 -
Tabla: Competencias_Juez
Atributo Tipo Llave Único Nulo Llave Rango Valor por Fórmula de
extranjera defecto derivación
DNI (AE) Cadena Sí Sí No Sí - 0 -
Nombre (AE) Cadena Sí Sí No Sí - X -

Tabla: Competencia

SUM (Calificación.puntos) [Si Calificación.DNIConcursante=DNI]

191
 Atributo Tipo Llave Único Nulo Llave Rango Valor por Fórmula de
extranjera defecto derivación
Nombre (AE) Cadena Sí Sí No No - X -
Categoría (AE) Enumerado No No No No [I,V] V -
Clase: Ejercicio
Atributo Tipo Llave Único Nulo Llave Rango Valor por Fórmula de
extranjera defecto derivación
Nombre (AE) Cadena Sí Sí No No - X -
Descripción (AE) Cadena No Sí No No - X -
Clase: Área
Atributo Tipo Llave Único Nulo Llave Rango Valor por Fórmula de
extranjera defecto derivación
NombreEjercicio (AE) Cadena Sí Sí No Sí - X -
DNIJuez (AD) Cadena Sí Sí No Sí - X -
Cantidad de jueces Entero No No No No [5,9] 5 -
(AE)
Cantidad de Entero No No Sí No [0,9] 0 -
calificaciones
reportadas (AD)
Ubicación (AE) Carácter No Sí No No [I,VI] I -
Clase: Calificación
Atributo Tipo Llave Único Nulo Llave Rango Valor por Fórmula de
extranjera defecto derivación
NombreEjercicio (AE) cadena Sí No No Sí - 0 -
DNIConcursante (AE) cadena Sí No No Sí - 0 -
Puntos (AE) Real No No No No [0,10] 0 -

192
Dinámica
Al revisar la clasificación de los atributos en estáticos, dinámicos y derivados; se aprecia
que solo dos clases poseen atributos dinámicos, lo que implica que solo para ellas se realiza
el DTE.
En el caso de la clase Juez, el atributo Puntos se puede clasificar como “característico de un
estado” pues la calificación que un juez da a la ejecución de un ejercicio a un concursante
no depende de la puntuación que dio con anterioridad ni de la que dará después. En éste
caso hay dos hechos que provocan que éste atributo tome dos tipos de valores diferentes.
Uno de ellos está asociado a que el juez califica a un concursante, y el otro a que todos los
jueces emitieron la calificación a un mismo concursante, por lo tanto se pone en 0 la
calificación individual de cada juez. Esto implica la definición de dos estados tal como se
aprecia en la figura 7.14. En la figura 7.15 se describe el diccionario de datos asociado a
éste diagrama.

T4

Actualizando
T0 puntuación T3
T1 T2

Limpiando
puntuación
Figura 7.14 DTE de la clase Juez.

Transición Descripción
To Area: Un juez emite puntuación
T1 Anotador: Todos los jueces emitieron su calificación
T2 Instantánea
T3 Area: Juez deja el área
T4 Area: Juez deja el área [Area.Cantidad calificaciones reportadas=0]
a) Transiciones.
b)
Nodo Actividades Restricciones
Actualizando puntuación Juez.Actualizar calificación (Puntos) -
Limpiando puntuación Juez.Limpiar calificación -
b)Nodos

Figura 7.15 Diccionario de datos de la clase Juez. a)Transición. b) Nodos.

Para la clase Area hay dos atributos dinámicos: Cantidad de calificaciones reportadas y
Jueces. El atributo Cantidad de calificaciones reportadas se puede clasificar como
cardinal. A éste atributo lo afectan eventos que provocan acciones incrementadoras y
reinicializadoras, que derivan los estados Actualizando calificación y Cerrando
concursante. En el caso del atributo Jueces, solo provoca su cambio el cambio de un juez

193
asignado a esa área. El atributo se clasifica por lo tanto en característico de un estado por lo
que se define el estado Cambiando juez. Los estados Esperando inicio de competencia y
Compitiendo, ayudan a completar la semántica de la descripción dinámica de ésta clase. En
la figura 7.16 se describe el DTE de la clase y en la figura 7.17 el diccionario de datos (DD)
a él asociado.

T1

Cambiando
T0 juez
T5
T4
T2 T3
T7
Esperando inico Compitiendo Actualizando
de competencia T6 calificación
T8
T9 T10
T11
Cerrando
concursante

Figura 7.16 DTE de la clase Area.

Transición Descripción
T0 Comisión organizadora: Cambio juez un área/New Modificación (Area
afectada)
T1 Anotador: Califica un juez a un concursante
T2 Instantánea [not Comisión organizadora.Inicio competencia]
T3 Comisión organizadora: Cambio juez un área [Area.Cantidad de calificaciones
reportadas=0]/New Modificación (Area afectada)
T4 Comisión organizadora: Cambio juez un área/New Modificación (Area
afectada)
T5 Instantánea [Comisión organizadora.Inicio competencia]
T6 Comisión organizadora: Comenzó competencia
T7 Anotador: Califica un juez a un concursante
T8 Instantánea
T9 Instantánea[Area.Cantidad de calificaciones reportadas=Area.Cantidad de
jueces]
T10 Instantánea
T11 Comisión organizadora: Competencia terminó
a) Transiciones.
Figura 7.17 Diccionario de datos de la clase área. a) Transiciones.

194
Nodo Actividades Restriciones
Cambiando juez Self.Cambiar juez (DNIViejo, NombreJuez, -
PaísJuez,DNIJuez)
Compitiendo - Cantidad de
calificaciones
reportadas  Cantidad
de jueces
Esperando inicio - -
de competencia
Actualizando Self.Actualizar calificación de un juez -
calificación (CalificaciónDato, DNIJuez)
Cantidad de calificaciones reportadas:=
Cantidad calicaciones reportadas+1
Cerrando Self.Calcular calificación total -
concursante (;Calificación total)
Cantidad de calificaciones reportadas:=0
Lista de calificaciones.Incluir calificación
(EjercicioDato,
ConcursanteDato,Calificación total)

b) Nodos.
Figura 7.17 Diccionario de datos de la clase área (continuación). B)Nodos.

Precondiciones.
En ambos DTE, en las transiciones están especificadas las precondiciones que deben
cumplirse para que ocurran cambios de estado. En el caso de la clase Area, algunas
transiciones también tienen asociadas condiciones a cumplir para que pueda efectuarse ese
cambio. Un ejemplo es la transición T3, que refleja que no basta con que se produzca el
evento “Cambio juez de un área”, la condición obliga a que éste cambio solo se haga
efectivo cuando no se esté evaluando a un concursante, lo que se refleja con la
comprobación de que el atributo Cantidad de calificaciones reportadas sea igual a cero.

Evaluación.
Clase: Juez
Atributo: Puntos
Clasificación: Características de un estado
Acción portadora Efecto de la acción
Area: Un juez emite una puntuación Juez.Actualizar calificación (Puntos)
Anotador: Todos los jueces emitieron su Juez.Limpiar calificación
calificación

195
Clase: Area
Atributo: Jueces
Clasificación: Características de un estado
Acción portadora Efecto de la acción
Comisión organizadora:Cambio juez un área Area.Cambiar juez (DNIViejo,NombreJuez,
PaísJuez,DNIJuez)

Clase: Area
Atributo: Cantidad de calificaciones reportadas
Clasificación: Cardinal
Acción Acción Acción Condición Efecto de la acción
incrementadora decrementadora reinicializadora
Anotador: - - - +1
Califica un juez
a un concursante
Cantidad de 0
calificaciones
reportadas =
Cantidad de
jueces

Disparadores.
En el caso de la clase Area, el cambio del valor del atributo jueces provoca la creación de
un nuevo objeto del tipo de clase Modificación. Este tipo de disparadores no requieren de la
especificación del mecanismo de disparo asociado puesto que se puede generar
automáticamente del DTE. El mecanismo generado sería:
UPDATE Area: IF UPDATE Jueces/New Modificación (Area afectada);
Que implementado usando SQL Server quedaría:
CREATE TRIGGER Crea_modificación
ON Area
FOR UPDATE
AS
IF UPDATE Jueces
New Modificación (Area afectada)
Supongamos que el sistema debe permitir a la comisión organizadora determinar qué países
tienen equipo completo. Para ello, cada vez que se incluye un nuevo concursante, se debe
actualizar un contador por países. Después de analizar éste nuevo requerimiento, se obtuvo
la siguiente definición de clases:

196
Clase Atributo Responsabilidades
Lista de Cantidad: Entero Incluir un nuevo país (DatoPaís)
países Identificador del 1er país: País Averiguar si un país existe (DatoPaís)
Incrementar concursante de un país (DatoPaís)
País Nombre: Cadena Crear (DatoPaís)
Cantidad: Entero Incrementar cantidad
Averiguar si es uno dado (;V/F)

No es necesario que sean persistentes estas clases pues lo único que se desea es que cuando
se conforme la lista de concursantes, se obtenga un reporte de la cantidad de concursantes
por países. La actualización de la lista de participantes (ya sea incluyendo un nuevo país
porque es el 1er concursante de ese país que se inscribe, o el incremento del número de
concursantes para un país en el que ya hubo otras inscripciones) se dispara como
consecuencia de la creación de un objeto de tipo concursante. Una forma de implementar
esto es usando un disparador, que se especifica como:
INSERT Concursante:/Concursante.Incrementar contador
El método “Incrementar contador”, habría que incluirlo en la clase concursante. Como
consecuencia de su implementación, ésta clase tendría como colaboradora a la clase Lista
de países, que a su vez dependería de ella. Para poder implementarlo como disparador
tendríamos que estar seguros que el lenguaje permite definir un procedimiento almacenado
en el que se pueda crear una lista o al menos un arreglo de elementos.
CREARE TRIGGER Incrementa_país
ON Concursante
FOR INSERT
AS
Incrementar contador
El procedimiento almacenado “Incrementar contador” sustituye al método de la clase
Concursante. De no poderse implementar con el lenguaje del gestor éste procedimiento,
habría que ver si se permite la relación con un lenguaje de alto nivel en el que sí es posible
definir estas especificaciones.

Derivación.
Solo hay un atributo derivado, que tiene una fórmula de derivación bastante compleja dado
el hecho de que su valor es la suma de varios valores de un subconjunto de tuplas. Si el
gestor no permite éste tipo de fórmulas, se puede implementar como un disparador que se
asocia a la clase Calificación, de manera que cada vez que se inserte una nueva calificación,
se actualice el acumulado total del concursante asociado. Este disparador quedaría
especificado como:
INSERT Calificación:/Calificación.Actualizar acumulado (PuntosDato)
El procedimiento “Actualizar acumulado” generaría una secuencia de envió de mensajes tal
como se presenta en la figura 7.18.

197
 Calificación Lista de concursantes Concursante
Actualizar acumulado
(DNIConcursante,PuntosDato)
Averiguar si es un concursante
dado (DNIConcursante;V/F)
Sí

Actualizar acumulado (PuntosDato)

Figura 7..18 Secuencia de mensajes generado por la clase calificación.

Especificación de métodos.
Todos lo métodos de las clases hay que especificarlos puesto que posiblemente el
programador no sea la misma persona que realizó el análisis y diseño, y es muy difícil que
con una descripción en lenguaje natural se pueda dejar clara la implementación que tiene
asociada.
Veamos un ejemplo:

Clase: Concursante
Responsabilidad: Incrementar contador
Especificación:
SI Lista de países.Averiguar si un país existe (País) = Falso
Lista de países.Incluir un nuevo país (País)
SINO
Lista de países.Incrementar concursante de un país (País)
FIN SI

Conclusiones.

Estática y dinámica son dos perspectivas importantes ha tener en cuenta cuando se diseña la
BD. Una busca definir estructura y otras cambios permitidos sobre esa estructura. Obviar
alguna de estas vistas en el proceso de diseño nos puede llevar a una BD inconsistente.
Lamentablemente no siempre las especificaciones que se dan a los programadores incluyen
todos los aspectos dinámicos y restricciones de integridad estática que aquí se describen.
Esto provoca, en el mejor de los casos, que se inserten parches en la programación cuando
se detecta algún problema (lo que introduce errores) y no aprovecha al máximo las
potencialidades del MR y las emergentes del objeto/relacional.

198
En ésta propuesta de tareas a desarrollar dentro del diseño de la BD, se ha descrito la forma
de obtener todo lo que Cooling y Pastor describe que se define dentro de los
comportamientos estático y dinámico. Se usó como referencia a estos autores porque
recogen en sus criterios tópicos abordados por otros también de reconocimiento en éste
campo.
La idea de acercar ADOOSI Visual a UML no es casual. UML es desde finales de 1997 la
notación estándar para la OO aprobada por el OMG (Object Management Group), por lo
que su utilización en la metodología es lógica.
Partir, como premisa para el diseño de la BD, de la clasificación de sus atributos, permite
minimizar éste proceso al centrarse el diseñador en lo que puede afectar al atributo y lo que
debe saber de cada uno.
Estamos listos para comprobar, a través de la repuesta a las preguntas iniciales, si se ha
captado la esencia de ésta propuesta de diseño.

 ¿Cómo se capturan las características que definen el comportamiento estático de las

clases?.

 Especificando textualmente características del dominio de los

atributos y otras restricciones del dominio que no es posible
categorizar.
 Capturando gráficamente la cardinalidad y dimensiones {I/R,E/D}
de las relaciones entre las clases, a través del; DC.
 Analizando la similitud entre las clases para obtener la jerarquía de
clases, así como las propiedades de totalidad y solapamiento.

 ¿De qué forma se capturan los aspectos dinámicos de un problema?.

 Definiendo un DTE para todas las clases con atributos dinámicos.

 Analizando el DTE para obtener precondiciones, formulas de
evaluación para cada atributo dinámico y disparadores.
 Especificando textualmente los mecanismos de disparo que no es
posible obtener del DTE, las fórmulas de los atributos derivados y
la especificación de acciones, actividades y métodos

199
 ¿Cómo ésta propuesta de conversión del MOO no desecha por completo todas las
características de éste enfoque?.

 Encapsulando el trabajo con las tablas con la creación de clases

persistentes que actúan de interfaz en su relación con otras clases
que requieren de la información almacenada.
 Recomendando la creación de nuevas clases con vistas a futuros
cambios en el esquema.
 Representación de la agregación como una clase,
independientemente de la cardinalidad, para conservar el objeto del
mundo real con su significado.

Referencias bibliográficas.

[Acosta, 1999]Acosta, K. y Jimenez, K. Trabajo para optar por el título de Ingeniería en

Informática: Generación de la base de datos (Gebase) ISPJAE. Junio.1999. Cuba.
[Aho, 1990] Aho, A.; Slethi, R. y Ullman,J. “Compiladores. Principios, técnicas y
herramientas”. Addison-Wesley Iberoamericana, S.A. 1990.
[Alvarez, 1999] Alvarez, S.; Anache, I. y Hdez, A. “ADOOSI Visual: metodología de
análisis y diseño orientado a objetos para medios ambientes visuales”. Revista Ingeniería
Industrial No. 2, 1999.
[Barrera, 1998] Barrera, J. y Reyes, D. Trabajo para optar por el título de Ingeniería en
Sistemas: Generación de código para Borland Delphi a partir de especificaciones del
diseño orientado a objetos (Gecodel). ISPJAE. Marzo, 1998. Cuba.
[Booch, 1995] Booch, G. and Rumbaugh, J. “Unified Method for Object-oriented
Development version 8.0”. Rational Software Corporation. 1995.
[Cooling, 1997] Cooling, J.E. “Real-time software systems: an introduction to structured
and object-oriented design”. International Jhonson Publishing Inc. EUA. 1997.
[Dalton, 1997] Dalton, P. “Microsoft SQL Server black book “. The Corilis group, Inc.
International Thomson Publishing Company. 1997.
[Delgado, 1997] Delgado, M. Tesis para optar por el título de master en Informática:
Automatización del Diagrama de transición de estado para la metodología ADOOSI”.
CEIS_CREPIAI, ISPJAE. Noviembre 1997.
[Dey, 1995] Dey, D.; Barron, T. And Stoney, V. “A conceptual model for the logical
design of temporal databases”. Decision Support Systems 15 P305(17). 1995.
[Fertuck, 1992] Fertuck, L. “Systems Analysis and Design with CASE tools”. Chapter 10
Implementation and installation. P460(45). Wm. Brown publishers. 1992.

200
[Hdez, 1996] Hdez, A. Anache, I. Y Alvarez, S. “Diseño orientado a objetos y bases de
datos relacionales”. Memorias del evento internacional Compac’96, Noviembre 1996.
Cuba. ISBN-959237-024-9.
[Hdez, 1998a] Hdez, A. y otros. “Soluciones al diseño de la base de datos a partir de un
desarrollo orientado a objetos”. Publicación electrónica del evento internacional
Informática’98, Febrero 1998. Cuba.
[Hdez, 1998b] Hdez, A.; Alvarez, S. y Pastor, O. “Generación de código para implementar
la persistencia a partir de especificación de diseño orientado a objetos”. Proceddings de
la XXV Convención de la UPADI. 1er Congreso de Informática. Perú. 1998.
[Martín, 1998] Martín, J. and Odell, J. “Object-oriented methods: a foundation”. Second
edition. Prentice-Hall, Inc. 1998. EUA.
[Rumbaugh, 1996] Rumbaugh, J. Blaha, M. Premarlini, W. Eddy, F. y Lorense, W.
“Modelado y diseño orientado a objetos. Metodología OMT.” Prentice-Hall
Hispanoamericana. S.A. 1996.
[Rumbaugh, 1999]Rumbaugh, J.; Jacobson, I. and Booch, G. “The unified modeling
language: reference manual”. Adison-Wesley Longman, Inc. 1999 Canadá.

201