Base de Datos II

1

Unidad V

BASE DE DATOS ORIENTADA AL OBJETO (OODBMS)

IntroducciónA los nuevos servicios de las empresas, le corresponden nuevas funciones de aplicación. Esasmodificaciones de aplicación deben poder hacerse rápido, sin tener que reescribir todo.Corría la segunda mitad de la década de los 80’, cuando comienzan a generalizarse en múltiplesaplicaciones los sistemas de gestión de bases de datos orientadas al objeto (OODBMS), los cuales tomanlas ventajas del enfoque orientado al objeto, ya probados y los sistemas de gestión de bases de datos,siendo su principal virtud el ofrecer un muy buen desempeño en la gestión de datos complejos ymultimediales.Desde el punto de vista del desarrollador las ventajas están dadas en ganancias de productividad, dado sumodelamiento más simple que facilita el desarrollo de aplicaciones. El modelamiento de aplicaciones esmucho más sencillo gracias al concepto de objetos complejos y el modelo obtenido es fácilmentecomprensible para el usuario. Este modelo puede ser validado directamente por el cliente de la aplicación.El enfoque Orientado al Objeto favorece la reutilización, porque gracias a la encapsulación y la herencia,es fácil especializar un componente existente para responder a las necesidades particulares de laaplicación.Desde el punto de vista del usuario final de los OODBMS, el mayor aporte es la calidad en términos deergonomía, fiabilidad, evolución y desempeño. La mayor parte de los productos disponibles en elmercado, son productos cerrados, difícilmente adaptables a las especificaciones de la empresa: laergonomía de la aplicación es fija, las reglas de cálculo son difícilmente modificables, etc. la tecnologíaobjeto, gracias en particular a la encapsulación y la herencia, da productos desarrollos con un OODBMSmás abierto y fácilmente adaptables. El usuario puede obtener un costo menor de las modificaciones desus procedimientos, que van a integrar más fácilmente su medio ambiente (entorno).Un poco de historiaLa primera aparición del concepto data de 1984 con la proposición de David Maier y George Copeland deconstruir un DBMS desde Smalltalk, Copeland et al. (1984).Se pueden citar dos grandes proyectos desde 1985, el proyecto ORION de MCC en Austín, Texas y en1986 el proyecto Altair, en Rocquencowt, Francia. En 1988, la primera generación apareció, seguida poruna segunda generación en 1990.Después de esta intensa actividad, pareciera necesario definir de una manera precisa el concepto deOODBMS (Sistemas de Gestión de Bases de Datos Orientadas al Objeto). En efecto, contrariamente alcaso de los sistemas relacionales que primero fueron definidos formalmente en el artículo original deCodd, después se generaron prototipos y finalmente transformados en producto, no hubo un principio deespecificación precisa de lo que debía ser un OODBMS.En 1989, el paper "The Object-Oriented Database System Manifesto" aunque con un enfoque demasiadolimitado en temas de administración, Stonebraker et al. (1990), propone una definición compuesta de trestipos de reglas que deben respetar un OODBMS:

• Reglas Obligatorias: Las cuales el sistema debe imperativamente seguir para merecer la calidadde OODBMS.

• Reglas Facultativas: Lineamientos suplementarios del sistema, pero que no son indispensables.• Reglas Abiertas: Propiedades alternativas del sistema que puede ejercer.

El conjunto de reglas es rápidamente admitido por la comunidad científica y comercial como un consensomínimo.

Base de Datos II

2

A principios de la década de los 90’, la comercialización efectiva de sistemas progresó rápidamente yfueron desarrolladas varias aplicaciones.En 1992, los principales distribuidores se juntan para definir un estándar que asegure la portabilidad de lasaplicaciones de un sistema a otro, y en Octubre de 1993 es publicado el estándar del ODMG (Grupo deAdministración de Bases de Datos Orientadas al Objeto), Catell et al. (1993). Se cuenta con unatecnología madura y adaptada al mercado, una oferta rica y diversificada, una demanda para este tipo deproducto y un estándar realista (ODMG-93 es un estándar para bases de datos al objeto puras, en contrastecon el estándar SQL3 nacido para bases de datos relaciones extendidas basadas en objetos, siendo éstacompatible con el modelo relacional clásico).

EL ESTÁNDAR ODMG-93: UN ESTÁNDAR PARA BASES DE DATOS ORIENTADAS ALOBJETO PURAS

Es el resultado de trabajos que duraron 18 meses por los 5 principales distribuidores de OODBMS. Suobjetivo fue asegurar la portabilidad de las aplicaciones de un sistema a otro. En este objetivo sondefinidas tres interfaz:1) ODL (Lenguaje de Definición de Objetos)El lenguaje de definición del objeto permite definir el modelo de datos. Es compatible con IDL, ellenguaje del OMG (Grupo de Administración de Objetos). Permite la definición de objetos complejos, derelación entre esos objetos y de métodos asociados a dichos objetos.2) OQL (Lenguaje de Consulta al Objeto)El lenguaje de requerimientos permite consultar los objetos de estructuras complejas, de enviar mensajes aobjetos, efectuar join y otras operaciones de tipo asociativo. Su sintaxis es del tipo SQL.3) Conexión vía C++ y Smalltalk.Esta interfaz ("bindings", enlazamientos), especifica como se debe hacer la programación en C++ oSmalltalk de una aplicación sobre una base de datos que ha sido declarada en ODL. La conexión es basadasobre la noción de "puntero inteligente" que permite manejar los objetos persistentes como objetosordinarios vía punteros persistentes.

DEFINIENDO LAS OODBMS

Un OODBMS ofrece todas la funcionalidad de un sistema de gestión de bases de datos, al igual que todaslas de un sistema objeto.Conceptos DBMSLa tecnología de gestión de bases de datos (DBMS), nació a fines de los años 60. Las tecnologías deimplementación de esos sistemas han evolucionado, su arquitectura ha emigrado hacia una arquitecturaCliente/Servidor, pero los servicios ofrecidos (En particular a su nivel físico) son los mismos. La figura 1muestra un DBMS tradicional considerando sus aspectos más característicos.Un DBMS ofrece facilidades de almacenamiento, de acceso, manipulación y de compartimento de grandesvolúmenes de datos. Esos datos pueden ser muy abultados, ellos no están ni en memoria principal ni enmemoria virtual. Es el DBMS quien asegura la gestión de diferentes niveles de jerarquía de memoria, elprogramador no hace la diferencia entre un dato en memoria y un dato en disco. La gestión del discoasegurada por el DBMS debe ser transparente y ofrece buenos desempeños. Ella debe ofrecer mecanismostales como gestión oculta de indexación, reagrupamiento de objetos sobre los discos (debe proveer unaforma adecuada de reagrupar los objetos de un nivel físico, a un nivel superior ), etc.

Base de Datos II

3

Figura 2: Composición de un Objeto.La parte estática del objeto puede reagrupar informaciones alfanuméricas, gráficas, textuales, sonoras, etc.Ella puede ser atómica (los objetos atómicos son del tipo de base del sistema: enteros, reales, caracteres,strings, booleanos) o compleja (constituida a partir de otros objetos, atómicos o complejos).La parte dinámica del objeto puede estar constituida de funciones de archivos, cálculos, de búsqueda deinformación, etc. Contrariamente a lo que existe en la programación clásica, las operaciones sonsubordinadas a los objetos; el objeto no es solamente caracterizado por lo que es, sino también por lo quehace, ocultando la estructura interna de un objeto y la implementación de las operaciones.Cada objeto tiene una identidad propia (ver figura 3), independiente de su valor. Podemos actualizar elvalor de un objeto sin alterar su identidad. El sistema maneja su identidad, atribuyendo a cada objeto unidentificador que asegura unicidad.

Figura 3: La identidad objeto.

La noción de identidad de objeto guarda relación con la composición del objeto, diferenciándose de otrosobjetos.Conceptos como la herencia permiten definir una clase (la clase define una estructura y uncomportamiento común, a varios objetos) de objetos a partir de una clase ya existente (herencia simple) ode varias otras clases (herencia múltiple). La clase creada recupera no solamente su estructura sino ademássus métodos de su(s) clase(s) padre(s). La herencia trae una descripción compacta bien estructurada delesquema de aplicación. Es una técnica de clasificación de objetos que evita la duplicación de códigofacilitando la reutilización de propiedades de estructuras y comportamientos ya definidas.

Base de Datos II

4

Los objetos se comunican entre ellos por envío de mensajes, lo que se quiere decir, es que transmitenórdenes a otros objetos. Cuando se recibe un mensaje por un objeto, éste lo ejecuta. Él puede crear nuevosobjetos y enviar nuevos mensajes.Los métodos asociados a clases diferentes, pueden tener el mismo nombre: la elección del método que seaefectivamente llamado es aplazada hasta el momento de la ejecución (enlazamiento dinámico),dependiendo de la persistencia de la clase del objeto del cual el método es llamado en tiempo deejecución. Ese mecanismo de enlace dinámico aumenta la independencia entre los métodos y los objetos ypermite sumar nuevas clases sin modificar ni recompilar los programas existentes, Por ejemplo, laaplicación de gestión de pago maneja diferentes tipos de contratos, cada uno con su método de cálculo desueldo, basta con crear una nueva subclase de la clase "contrato" con un método de cálculo de sueldocorrespondiente a ese algoritmo. Esos nuevos contratos son entonces inmediatamente tomados en cuentapor los programas existentes, sin modificación particular del código.La herencia y el enlazamiento dinámico permiten alivianar los programas y el trabajo del programador(por efecto de la reutilización) cuando se activan los módulos de la aplicación.Se hace notar que el modelamiento de objetos se puede realizar bajo una forma gráfica, pudiendo tenerciclos.

CONCEPTOS ESPECIFICOS DE OODBMSLa noción de objetos complejos optimiza la representación de las estructuras complejas y acortando ladistancia que separa el modelamiento de un escenario del mundo real y su implementación. Los objetoscomplejos permiten así, un modelamiento más intuitivo de datos de una aplicación, su presentación en labase de datos está mas cerca de la realidad. La estructura compleja de los objetos es manejada porpunteros lógicos. Esos punteros reemplazan la utilización de uniones relacionales, e inducen así unaganancia de desempeño, particularmente cuando la cantidad de datos es importante. La siguiente figuramuestra un esquema típico de una OODBMS:

Figura 4: Una OODBMS tradicional, Manola (1994).

Base de Datos II

5

El concepto de identidad de objeto, tiene repercusiones particularmente interesantes en el contexto de unDBMS. La distribución de objetos permite limitar la tabla de la base de datos. Permite una mejor gestiónde actualización, y es más rápida, ya que tiene menos objetos que modificar. Ofrece igualmente unagestión automática de integridad referencial (desaparición de referencias a objetos destruidos), problemacrucial de las bases de datos.Con las generaciones previas de DBMS, los desarrolladores tuvieron un nivel bajo de productividad. Estoes en particular dado por un problema de funcionalidad entre aquellas DBMS y los lenguajes deprogramación utilizados. En efecto, los tipos de datos de esas categorías de herramientas sonincompatibles, el programador debe asegurarse por si mismo de la conversión de datos entre la base dedatos y el lenguaje: Esto impone el desarrollo suplementario que hay que realizar para mantener laconsistencia de la aplicación en su ejecución.La falta de coincidencia entre lenguajes orientados a tablas, tales como SQL, y los lenguajes comunes,significa que se necesita un lenguaje separador para la manipulación de datos (DML), existiendoimpedimentos de acoplar estilos declarativos y basados en procedimientos entre los tipos de sistemas dellenguaje de aplicación y de bases de datos, dando lugar a una perdida de información en la interfaz, yobstaculizando la comprobación automática de tipos.Para solucionar este problema los OODBMS ofrecen el concepto de completitud; que es la percepción deescribir completamente una aplicación utilizando el DBMS como un único lenguaje (tal como loslenguajes estándar según la norma ODMG; C++, Smalltalk o Java), sin tener que recurrir a los recursos delos lenguajes externos. Este concepto suprime el problema de funcionalidad, ya que los datos sonmanipulados de la misma manera en la base de datos que por el lenguaje de programación. En efecto, es elmismo modelo de datos, que es soportado por el lenguaje objeto de desarrollo de la aplicación y por elOODBMS. Los OODBMS ofrecen todo un lenguaje de programación completo integrando los accesos alas bases de datos.

CARACTERÍSTICAS DE LAS ODBMSUn completo modelo de bases de datos, con rasgos tales como; la manipulación fija y el acceso deasociación.Un modelo orientado al objeto que respalda objetos complejos, identidad del objeto, encapsulamiento,clases, caracteres, extensibilidad e integridad computacional.Un DDL (Data Definition languaje, define tipos de objetos, y además el usuario puede declararprocedimientos y variables asociadas con los tipos de objetos) real con rasgos de manipulación deesquemas.La capacidad de almacenar y manipular tanto los datos (objetos) como los metadatos (clases y métodos)en el propio sistemas.Un DML (Data Manipulation Languaje, por lo general contiene un lenguaje de consultas y un componentede lenguaje de programación ), a través de un lenguaje de consulta completo, declarativo.Independencia de datos lógica y física (esto es, un DDL físico y uno lógico y la capacidad para modificarel esquema físico sin cambiar la aplicación).La capacidad de manipular cantidades de datos enormes.La capacidad de desarrollar aplicaciones completas en un medio único.

LOS DESEMPEÑOSEl problema de los desempeños es esencial para los DBMS. El mercado de sistemas orientados al objetose desarrolla porque esos sistemas ofrecen desempeños mejorados con respecto a los sistemasrelacionales. Existen tres tipos de benchmarking ("pruebas de rendimiento") que permiten medir estossistemas.

• Bechmarking 001, Rubenstein et al. (1987), Catell et al. (1992), está orientado a aplicaciones quetienen por objetivo describir la aplicación en cuanto a su tipo de concepción (refiriéndose a suforma de generación, formación). Manipula los objetos complejos entre el servidor y una estaciónde trabajo.

Base de Datos II

6

• Bechmarking de Hypermodel, fue hecho por un grupo de navegadores de conceptos en sistemas.Se basa sobre la aplicación del tipo hipertexto y mide el tiempo de acceso a los objetos.

• Bechmarking 007, Carey et al. (1993), hecho en 1992 para las limitaciones del Bechmarking 001,abarcando un gran número de operaciones, transacciones, requerimientos y el control deversiones. El 007 denota tres diferentes tamaños:

• Pequeño: La base de datos en memoria principal.• Mediano: La base de datos está contenida en memoria virtual y una parte en la memoria principal.• Grande: La base de datos está en memoria virtual.

¡Error!Nombre de archivo no especificado.Figura 5: Comparación Arquitectura OODBMS vs RDBMS, Manola (1994, pág. 3,19).

Los OODBMS dominan en desempeño con respecto a los sistemas relacionales sobre las aplicacionesmanipulando objetos complejos. Esto es por una sencilla razón; que los sistemas relacionales fueronhechos y diseñados para efectuar algunas operaciones simples (selección, proyección, etc.), y losOODBMS tienen por finalidad manipular objetos estructurados y complejos. En cuanto a unacomparación arquitectónica entre el modelo relacional y el modelo objeto aplicado a DBMS, la figura 5muestra su correspondiente composición habitual.

LOS APORTES A LA TECNOLOGIALos OODBMS permiten llegar a nuevos dominios para los cuales las bases de datos tradicionales sonrenuentes a ser aceptadas.

Su fuerte es en ambientes donde hay una necesidad de datos no estándar, es decir, de aquellos que unomanipula textos estructurados o no estructurados, imágenes, gráficos, sonidos, videos, documentos oprogramas. Se trata entonces de ambientes donde la estructura de los datos es tan compleja querepresentarla en un modelo tradicional es ineficaz.

Se trata de dominios o tipos de datos que al usarlos no permanecen fijos desde el inicio y son variables enel tiempo.Son dominios comunes, por ejemplo:

• CAD• Gestión de datos técnicos• Cartografía• Multimedia.• Sistemas distribuidos y cliente/servidor.• Bases de datos multimedia.• Correo por voz.• GIS

En todos estos dominios, la tecnología de OODBMS aporta los desempeños mejores y un desarrollo máseficaz de aplicaciones.Los OODBMS disminuyen los costos lógicos de desarrollo.Esta baja de costos es obtenida en opinión de connotadas figuras ligadas a DBMS (Por citar algunos:Atkinson et al., Bancilhon, Graham), por un acortamiento del ciclo de análisis, concepción, codificación,depuración, testeo, mantención y evolución. Mejoramiento obtenido por:

• La reutilización del componente lógico.• La disminución de código.• La capacidad de modelamiento directo de información compleja.• La mejor integración a los lenguajes de programación.• Desarrollo rápido de prototipos de aplicaciones.• Utilización de medio ambiente gráfico de desarrollo.

Base de Datos II

7

• Utilización de herramientas de generación de interfaz gráfica de realización.Los OODBMS permiten producir aplicaciones gráficas de mejor calidad.Las aplicaciones son mejoradas en dos puntos esenciales:

• Los desempeños en el caso de la manipulación de datos complejos.• La calidad "industrial" de aplicaciones para la facilidad de mantención, su capacidad de

crecimiento y posibilidad de ser personalizadas en dominios específicos.Los OODBMS permiten recuperar y mejorar las aplicaciones existentes.Para los sistemas que disponen de una interfaz C++ estándar, el mecanismo consiste en tomar unaaplicación existente en la cual la persistencia es asegurada por un sistema de archivos que al migrarlos alOODBMS se reemplaza el acceso a los archivos por el almacenamiento en el OODBMS. Así, el costo demigración es mínimo y la aplicación es bastante mejorada. En efecto, resultando en:

• Una simplificación de código (el acceso a los objetos de la base de datos es inmediata y sintraducción).

• La capacidad de fiabilidad y compatibilidad de los datos.Los Mercados1. Aplicación en Sistemas de información geográficos.Para los sistemas de información geográficos o para toda aplicación en la cual hay una dimensión espacialo geográfica (la cartografía de una región, la topología de una zona o el plano de un edificio), losdesarrolladores de estas aplicaciones necesitan la tecnología de objetos; ella ofrece un mayor desarrollo ymejores desempeños.2. Gestión de datos técnicos.Porque permiten almacenar los datos de naturaleza variada y de tipo extensible, los OODBMS sonelegibles como sistemas de almacenamiento para este tipo de aplicaciones, que incluyen la gestión dedatos científicos experimentales, la gestión de datos asistidos por computador (CAD) y la documentacióntécnica.3. Aplicaciones Multimedia.Para toda aplicación que manipula gráficos, imágenes, animación y voz, los OODBMS son los primerosen la elección de los desarrolladores.

Orientado a objetos.Una idea superficial del concepto Orientado a Objetos consiste en una organización del software como unconjunto de objetos que contienen tanto información en estructuras de datos como su comportamiento. Lainformación que tienen se organiza en atributos y el comportamiento en operaciones.

Para comprender mejor el concepto se van a examinar las cuatro principales características:

Identidad, Clasificación, Polimorfismo y Herencia.

Identidad.Identidad quiere decir que los datos están organizados en entidades discretas y distinguibles llamadasobjetos. Cada objeto ha de poder distinguirse por un puntero, un índice en un array, un valor de unatributo,...

• Dos objetos que tengan la misma información no son indistinguibles, la identidad los distingue.C++: La implementación de la identidad se realiza a través del puntero al objeto (this). Ejemplo:

int * p; p=new int;...{int a=*p; delete p; p=new int; *p=a;} // Código vacío...El código que aparece en el ejemplo, ¿puede tener alguna influencia en la funcionalidad del programa?

Base de Datos II

8

Clasificación.Los objetos con la misma estructura de datos (atributos) y el mismo comportamiento (Operaciones) seaglutinan para formar una clase. Una clase es una abstracción que describe las propiedades de los objetos.

Una clase define un conjunto de objetos individuales. Se dice que cada objeto es una instancia de una

clase. Los objetos de la misma clase, aparte de la identidad, solo se diferencian en el valor de los atributos,

comparten los nombres de los atributos, así como las operaciones.

Nada impide que un objeto pertenezca a más de una clase. Ejemplo:Clase Circulo Atributos Centro Radio Operaciones Superficie Mover CambiarTamaño

Clase Gráfico Atributos Posición Color Operaciones Dibujar Mover

• Como sería un objeto de ambas clases?• Qué pasa con la operación mover?Polimorfismo.Significa que una misma operación puede comportarse manera diferente en diferentes clases. Con estoestamos diciendo que es el propio objeto el que sabe como tiene que comportarte ante una determinadaoperación.Podemos tener la clase fichero y la clase PiezaAjedrez, ambas pueden tener la operación mover pero cadauna hará tarea diferente, según lo que se espera de ella.La implementación concreta de una operación para una clase se llama método.Gracias al polimorfismo se puede invocar a un método sin conocer exactamente el objeto sobre el que seinvoca. Si suponemos que tenemos un conjunto de objetos y de entre ellos se selecciona uno, pero nosabemos cual, si todos esos objetos tienen el método mover, puedo invocar dicha operación y ,según elobjeto que sea, invocará al método adecuado.Herencia.Herencia es compartir atributos y operaciones entre clases utilizando una estrategia jerárquica. Tanto losatributos como las operaciones que se toman de otra clase se pueden redefinir. En términos generales sepuede definir una clase que después se puede ir refinando en sucesivas subclases.Cuando se dice que una clase A hereda de otra clase B, A tendrá todos los atributos y operaciones de B,además podrá tener otros atributos y operaciones propias. Puede ocurrir que la clase A tenga operaciones oatributos que se llamen igual que la clase B, este tipo de refinamiento de las clases consiste en redefinir lasacciones o atributos de la clase padre. Realmente no se puede decir que en este caso se sustituyan, losatributos y operaciones de B están en A, pero dependiendo del gestor de objetos, éstos pueden quedarocultos o inaccesibles.Una clase puede heredar de varias clases, cuando esto ocurre tendrá todos los atributos y operaciones detodas las clases que hereda.Puede ocurrir que dos clases tengan atributos u operaciones con el mismo nombre, si una clase heredarade ambas habría ambigüedad, cuando me refiera a una operación, cada gestor de objetos particular puededeshacer la ambigüedad de diferente manera.Cuando un objeto es de una clase, y ésta hereda de otras clases, ese objeto es de todas las clases quehereda su clase.Otras características.Las características que se tratan en este punto no específicas de la orientación a objetos, pero si son muyimportantes.

Base de Datos II

9

Abstracción.La abstracción consiste en centrarse en los aspectos esenciales de una entidad e ignorar sus propiedadesaccidentales. La abstracción en la orientación a objetos se produce a través de dos maneras:• Clasificación: Permite englobar a muchas entidades particulares dando una idea general y abstracta de

todas ellas.• Herencia + Polimorfismo: Permite crear una clase original muy general para que en sucesivos

refinamientos se creen otras subclases más concretas. Con la primera clase nos hemos abstraído de locomún e importante de todas las subclases y con el polimorfismo podemos mantener o refinar lasoperaciones iniciales.

Encapsulamiento.La encapsulación consiste en separar los aspectos externos del objeto, a los cuales pueden acceder otrosobjetos, de los detalles internos de la implementación del mismo, que quedan ocultos para los demás.Esto permite modificar la implementación de un objeto, sabiendo seguro que no influye en el resto de laaplicación, lo que hay que hacer es modificar solo la parte oculta, respetando la externa.Combinación datos y comportamiento.Con un enfoque convencional por procedimientos, cuando tenemos un conjunto de estructuras de datos,éstos vienen asociados con otro conjunto similar pero de procedimientos que permiten su manejo. Coneste enfoque se están duplicando los elementos por que hay dos conjuntos. Se más adecuado crear un soloconjunto donde los elementos del mismo sean pares de estructura de datos / procedimiento.Ejemplo:Gestor de bases de datos de información geográfica (GIS):

• Tratamiento convencional:Se definen propiedades para zonas geográficas.Se definen como varían esas propiedades en el tiempo.

• Combinando datos y comportamiento.Se definen un elemento propiedad junto con la forma en que varía en el tiempo.Se aplica ese elemento sobre zonas geográficas.

Compartir.Una de las principales características de las técnicas orientadas a objetos es la capacidad que tienen parapoder compartir, esto se realiza en dos niveles:

• A través de la herencia se utiliza código de manera natural y con el polimorfismo se puedeparticularizar para cada clase.

• La reutilización de código se realiza de manera inmediata. Gracias al encapsulamiento se puedeutilizar código sin tener en cuenta su implementación.

Objetos / Procedimientos.Un diseño basado en objetos es más estable que un diseño basado en procedimientos, a lo largo de unproyecto pueden cambiar algunos procedimientos o acciones, sin embargo los objetos que forman partendel mismo rara vez cambian.Ejemplo: Se quiere diseñar un software para analizar la vuelta a España.Habrá objetos ciclistas, etapas, equipos,...Si se quiere realizar el diseño del Tour de Francia, puede que haya que cambiar valores de atributos eimplementación de métodos, pero seguirán los mismos objetos.Sinergia.Cuando los resultados de combinar una serie de elementos son mayores de lo que se espera de esoselementos vistos individualmente, se dice que se produce sinergia entre ellos. Esto ocurre con laidentidad, clasificación, polimorfismo y herencia, al utilizarlas en conjunto forman un estilo diferente deprogramación (orientado a objetos).

Base de Datos II

10

Orientación por objetosLa orientación por objetos es un nuevo enfoque para el desarrollo de sistemas programados, que permite larepresentación del dominio de una aplicación en forma natural y directa, en términos de los objetos queintervienen en dicha aplicación. Este enfoque atañe también a las BD. La figura 1 muestra unadescomposición de los objetos vs. la descomposición funcional y jerárquica. La representación de talesobjetos se hace en forma abstracta definiendo su estructura y su comportamiento.

Figura 1. Descomposición funcional y de objetos.Los conceptos de la orientación por objetos se remontan a los años 60 con la aparición del lenguaje desimulación llamado Simula’67, donde los objetos existen por sí mismos conteniendo sus datos y susoperaciones, y además se comunican entre sí por medio de mensajes. También fue en este lenguaje dondese introdujo la noción de clase de objetos, que describen la estructura y el comportamiento de todos losobjetos que pertenecen a la clase, la noción de herencia entre las clases siguiendo una jerarquía de lasmismas, y por último, la noción de dos tipos de igualdad: la igualdad en valores (shallow equality) y laidentidad (deep equality).Los lenguajes de programación que aparecieron después y que siguieron estas premisas, fueron Smalltalk,Eiffel, Trellis/Owl, Java, etc. La extensión de lenguajes existentes arrojaron nuevas versiones de: C enC++, Objective C y Borland C, LISP en Flavors, Object LISP y CLOS, y Pascal en TurboPascal6 yCLASCAL, entre otros.Los tópicos tratados en esta sección son los siguientes:

Un lenguaje de modelado unificado UMLLos métodos estructurados y funcionales aparecieron primero, inspirados directamente de la arquitecturade los computadores. Los métodos OO comienzan a emerger a inicios de los años 80, ellos se articulanalrededor de las nociones de clases y asociaciones (James Rumbaugh), de divisiones en subsistemas(Grady Booch) y de la expresión de los requerimientos a partir del estudio de la interacción entre usuariosy sistemas (los casos de uso de Ivar Jacobson).A finales de 1994, Rumbaugh y Booch deciden unificar sus trabajos en un método único, el métodounificado. El año siguiente se une al grupo Jacobson y fijan cuatro objetivos de trabajo:

1. Representar sistemas enteros siguiendo la OO2. Establecer una conexión explícita entre los conceptos y los elementos ejecutables3. Tomar en cuenta los factores inherentes a los sistemas complejos y críticos

Base de Datos II

11

4. Crear un lenguaje de modelado que pueda ser usado por humanos y por máquinasAsí, en octubre de 1995 aparece el método unificado V0.8, luego en junio 1996, la versión 0.9 y porúltimo, este método se transforma el 17 de enero de 1997 en un lenguaje universal para el modelado deobjetos denominado UML 1.0 (The Unified Modeling Language for Object-Oriented Development).

Conceptos básicos de la OO y su representación en UML

Los conceptos de la orientación por objetos se basan en la manipulación de representaciones abstractas delos objetos plasmadas en su definición y su comportamiento. Un objeto se define entonces como larepresentación de algo que se describe mediante una estructura y un comportamiento. La estructura deun objeto describe aquellas características de interés presentes en el objeto y que sirven para plasmar elestado de ese objeto, siendo el estado de un objeto el conjunto de valores actuales almacenados en suestructura, que está escondida. El comportamiento del objeto está representado por una serie deoperaciones, funciones o métodos que modifican ó no el estado del objeto, haciendo que ocurra un cambiode estado en el mismo, el cual representa el comportamiento visible del objeto en la realidad. Así, elcomportamiento del objeto está dado por sus cambios de estado. La figura 2 presenta la notación UMLpara los objetos (un rectángulo con el nombre del objeto subrayado), los enlaces que pueden existir entreellos (una línea continua que conecta dos objetos) y la invocación de sus operaciones por medio del pasede mensajes (una flecha indicando la dirección y el nombre del mensaje), en base al contenido de algunosde sus atributos. Un objeto puede ser conocido y descrito por medio de sus propiedades o atributos queson ilimitados. Un mensaje es el soporte de una relación de comunicación que relaciona en formadinámica los objetos separados por el proceso de descomposición. Los atributos se representan en UMLcon sub-rectángulos conteniendo un valor subrayado, dentro del rectángulo del objeto. Una nota,representada con un rectángulo con la esquina doblada, indica una clarificación o descripción, en formatolibre, para facilitar la comprensión del diagrama. Una nota está ligada a los objetos por medio de una líneadiscontinua para indicar a que objeto pertenece la nota.Un objeto puede componerse de dos o más objetos, conformando así un objeto compuesto. Cada objetotiene un único identificador que es asignado por el sistema, para aquellos sistemas que soportan laidentidad del objeto.

Los atributos son las propiedades relevantes de un objeto que representa su estructura. Ellos pueden sersimples o monovaluados, en el caso que ellos contengan un único valor a la vez, y multivaluados cuandopueden contener varios valores a la vez.La existencia de un objeto es independiente de los valores de sus atributos, así dos objetos son idénticos siellos son el mismo objeto, es decir sus identificadores son iguales (deep equality), o ellos son iguales sitienen los mismos valores en sus atributos (shallow equality). En un sistema o lenguaje que no soportaidentidad del objeto, la representación gráfica de los objetos es un árbol. En los sistemas que si la soportanes un grafo, ya que los objetos compuestos pueden compartir componentes.Una operación es una función asociada al objeto que efectua una acción atómica sobre el mismo. Talacción puede ó no modificar el estado del objeto.

Base de Datos II

12

Figura 2. Objetos con enlaces, operaciones y pase de mensajes.

Tipos abstractos de datos y su especificaciónUn tipo abstracto de dato (TAD) se basa en la separación clara entre su implantación y el uso del TAD através de su interfase, que es la cara visible del TAD. Ello implica que un TAD tiene una interfaz y puedetener varias implantaciones. La definición de un TAD se hace en dos partes: la especificación y laimplementación.Una especificación formal es la acción de determinar o explicar en términos formales o matemáticos lacosa deseada, en este caso un tipo de dato que es necesario para la resolución del problema. Este tipo dedato T se define "como una clase de valores y una colección de operaciones sobre esos valores. Si laspropiedades de esas operaciones son especificadas solamente con axiomas, entonces T es un tipo abstractode dato o una abstracción de dato" [Gutt-78,p.1049]. Una implantación correcta del TAD cumple contodos los axiomas especificados para él.La especificación por axiomas algebraicos para el tipo T se compone de: una especificación sintácticadonde se definen los nombres, dominios y rangos de las operaciones sobre T; y una especificaciónsemántica que está compuesta del conjunto de axiomas en forma de ecuaciones, que dicen como operacada una de las operaciones especificadas sobre las otras.La implementación se compone de: una representación que especifica como los valores del TAD seránalmacenados en la memoria, es decir su estructura de datos, y los algoritmos que especifican como seráusada y manipulada la estructura de datos, es decir las operaciones del TAD.

Base de Datos II

13

El acceso al TAD es hecho a través de su interfaz que es visible para los usuarios de ella. Laimplementación del TAD es invisible para el usuario y es visible para el que desarrolla el TAD.Como un ejemplo de esto se presenta aquí la especificación del tipo abstracto de dato: Pila. Talespecificación será hecha para una pila no limitada.Tipo de dato: Pila[elemento:tipoEle]Especificación sintáctica:creaPila() -> Pila, Crea la pilameterElePila(Pila,tipoEle) -> Pila, Inserta un nuevo elemento en el topesacarElePila(Pila) -> Pila, Elimina el elemento que está en el topeconTopePila(Pila) -> tipoEle \/ {TipoEleNoDef}, Consulta el elemento que está en el topevacíaPila(Pila) -> Lógico, Verifica si la pila está vacíadestruyePila(Pila) -> . Destruye la pila

Especificación semántica: Declaración: P: Pila, el: tipoEle;sacarElePila(creaPila()) = creaPila()conTopePila(creaPila()) = {TipoEleNoDef}conTopePila(meterElePila(P,el)) = elvacíaPila(creaPila()) = VerdaderovacíaPila(meterElePila(P,el)) = Falso

Con la especificación sintáctica se pueden ver claramente cuáles son las operaciones primitivas válidassobre la estructura y cuáles son los tipos de datos que cada una regresa, luego que se ha efectuado laoperación. Para mayor claridad, véase la operación sacarElePila() que necesita para operar la Pila,devolviendo la misma Pila pero disminuida en tamaño por un elemento, ya que e lla suprime el elementoque está colocado en el tope de la Pila. En esta especificación se incluyen unicamente aquellasoperaciones que son básicas para el TAD, es decir las operaciones que sirven de base para construircualquier otra operación sobre el tipo. Por ejemplo, en la mayoría de las estructuras de datos es útil teneruna operación que vacíe o limpie la estructura, en el caso de la Pila, sería la operación vaciarPila(Pila)->Pila. Dicha operación no aparece en la especificación del TAD Pila, pues ella puede ser construidainvocando varias veces la operación sacarElePila(Pila) hasta que vacíaPila(Pila) sea verdadero. Por lotanto, las operaciones que aparecen en una implementación cualquiera de un TAD no tienen por que seriguales, en número, a las de la especificación del mismo.Con la especificación semántica se observa el efecto que tiene cada una de las operaciones especificadassobre las otras. Por ejemplo: ¿Qué sucede si se desea saber si la Pila está vacía, habiéndose reciencreado?, esto es vacíaPila(creaPila()), el resultado es Verdadero, ya que aunque la pila existe, ella ha sidorecientemente creada y por ello, está vacía. En el caso de conTopePila(creaPila()), el resultado es un valorespecial denominado TipoEleNoDef, esto es tipoElemento no definido, para expresar que no puederegresarse elemento alguno, pues la pila está vacía. Este valor especial para el debe estar definido en laimplementación del tipo abstracto de dato.Para llevar a la práctica esta especificación debe escogerse una representación física para el tipo Pila, ellapuede ser una de las siguientes: la secuencial, donde los elementos de la Pila están contigüos en memoria;o el enlazado, donde esos elementos están esparcidos en la memoria y encadenados mediante punteros alsiguiente. Ambas implantaciones, las hechas con las representaciones mencionadas, deben tomar encuenta que la memoria es finita, y por ello tal especificación es lo que es, una especificación para un tipoabstracto de dato. Ella diferirá en algunos detalles de la implementación realizada basándose en ella.

Mecanismos de la abstracción de datosLa clasificación es la agrupación de objetos con propiedades y comportamiento similares dentro de unaclase. Una clase es un objeto que define la estructura y el comportamiento de un conjunto de objetos quetienen el mismo patrón estructural y de comportamiento. Cada objeto que pertenece a una clase es una

Base de Datos II

14

instancia de ella. En UML, cada clase se representa con un rectángulo dividido en tres compartimentos.El primero indica el nombre de la clase, que debe permitir la comprensión de lo que es la clase y NO loque ella hace. El segundo contiene los atributos expresados con su nombre, su tipo y un valor inicial poromisión, en caso de ser necesario, y el tercero indica sus operaciones expresadas con el nombre de laoperación, sus argumentos entre paréntesis, expresados como nombre del argumento, su tipo y su valorpor omisión, si es necesario; y por último el tipo de resultado que devuelve la operación. Cada uno de losatributos y operaciones va antecedido por un caracter que indica el tipo de acceso o la visibilidad de dichoparámetro en la clase. Estos son: (+) para los públicos, (#) para los protegidos, (-) para los privados, (7)para los atributos calculados por alguna operación definida en la clase, y el parámetro subrayado para losde la clase, lo que hace que existan atributos y operaciones de la clase y no de las instancias de la clase. Lafigura 3 presenta la estructura de una clase y un ejemplo.

El conjunto de todas las instancias de una clase es la extensión de la clase. La instanciación es el procesode generación o creación de las instancias de una clase. La definición de una clase normalmente contiene:su nombre, el nombre de sus superclases (clases de las que se hereda), su interfaz, su estructura y suimplementación. En UML, la interfaz de una clase se representa con un círculo pequeño enlazado a laclase y sirve para describir el comportamiento visible de la clase. La interfaz también puede representarsecon una clase que lleve debajo de su nombre el estereotipo <<interfaz>>. Las clases parametrizables sonmodelos de clases que se corresponden con clases genéricas como los templates de C++. Ellas serepresentan en UML con la misma representación de una clase, pero lleva en la esquina superior derechadel rectángulo, otro rectángulo más pequeño en líneas entrecortadas. La instanciación de esta clase con eltipo deseado se materializa con una flecha de línea entrecortada orientada hacia la clase parametrizable. Lafigura 4 muestra ambas representaciones. Existen también en UML las clases utilitarias, ellas sirven paraindicar aquellas clases de librería o funciones agrupadas en librerías, por ejemplo las clases en C++ quecontienen solamente miembros estáticos. Se indican con <<utilitaria>>. Las clases abstractas no puedenser instanciadas, ya que ellas no crean objetos sino que sirven de especificación general. Ellas se indicancon la palabra abstracta en itálicas.

Figura 4. Clases parametrizables y utilitarias en UML.Las clases formarán una jerarquía denominada jerarquía de clases, donde las clases superiores a unaclase particular se denominan superclases y a la clase particular se le llama subclase. La relación entreuna superclase y una subclase se denomina ES-UN(A). La metaclase es la clase que define todas lasclases del sistema. La figura 5 presenta un ejemplo de una jerarquía de clases en notación gráfica UML.Cada rectángulo representa una clase de objetos. Sus divisiones indican: primero, el nombre de la clase; acontinuación, la estructura de las instancias de la clase; y por último, las operaciones o métodos quetabajan sobre las instancias de la misma. La metaclase se indica con <<metaclase>>.

Base de Datos II

15

Figura 5. Jerarquía de clases en UML.

La generalización es un proceso de abstracción en el cual un conjunto de clases existentes, que tienenatributos y operaciones comunes es referido por una clase genérica a un nivel mayor de abstracción. Lageneralización corresponde a la relación ES-UN(A) entre las clases. En la figura 5 pudo haber habido unageneralización, si las clases Empleado y Estudiante fueron realizadas antes y una vez que se tuvieron, sedecidió crear una nueva clase genérica denominada Persona, para contener los atributos y operacionescomunes a las clases ya implementadas, ya que tanto Estudiante como Empleado son Personas.La especialización o particularización es el proceso inverso de la generalización, ya que una subclase secrea a partir de una clase ya existente. Este es el proceso que soportan la mayoría de los sistemasorientados por objetos. La figura 5 muestra un ejemplo de ello, si se crea la clase Preparador comosubclase de Estudiante y de Empleado. Una clase puede tener varias superclases, denominándose unageneralización o especialización múltiple. La figura 6 muestra esta situación para una alfombra voladora.La generalización o la especialización pueden ser realizadas según uno o varios criterios, los cuales seindican en UML con una palabra discriminante en la línea de la abstracción y si es una restricción como:incompleta, exclusiva o inclusiva, ella puede indicarse entre paréntesis, como lo muestra la figura 6.

Las asociaciones representan relaciones estructurales entre las clases, ellas se representan en UML conuna línea. Las asociaciones pueden ser binarias, terciarias o de mayor aridad. Las asociaciones n-ariasgeneralmente se representan promoviendo la asociación al rango de clase y agregando una restricción queexpresa que las múltiples ramas se instancian todas simultáneamente, como se muestra en la figura 7. Lasasociaciones pueden llevar un nombre, en itálicas y que normalmente se expresa en forma activa, i.e.trabaja para, o en forma pasiva, i.e. es empleado por. En ambos casos se puede indicar el sentido delectura con < ó >. Así también, se pueden expresar los roles al extremo de las asociaciones y lamultiplicidad de las mismas expresadas como: 1: sólo uno; 0..1: cero o uno; 0..*: de cero a muchos; 1..*:de uno a muchos. Ellas también pueden llevar restricciones entre paréntesis: {ordenado}, {subconjunto},{exclusivo}, etc. como lo muestra la figura 8. También pueden existir subasociaciones o asociación

Base de Datos II

16

reflexiva, de una clase con ella misma; y puede calificarse las asociaciones para seleccionar unsubconjunto de objetos que participan en la asociación por medio de una clave, simple o compuesta, quepertenece a la asociación y no a la clase. Estas situaciones se muestran en la figura 9.

Figura 6. Generalización exclusiva, inclusiva e incompleta en UML.

Figura 7. Asociación ternaria en UML.

Figura 8. Roles de asociación en UML.

Base de Datos II

17

Figura 9. Restricciones y claves de asociación en UML.

La agregación permite definir clases según los criterios siguientes:• Una clase forma parte de otra• Los valores de los atributos de una clase se propagan en los valores de los atributos de otra• Una acción sobre una clase implica una acción sobre otra• Los objetos de una clase están subordinados a los objetos de otra

La figura 10 presenta un ejemplo de agregación. La composición es un caso particular de la agregación,ella se utiliza para indicar clases de objetos compuestos, ya que coloca atributos en la clase que pertenecena otra clase. Ella representa la relación ES-PARTE-DE entre una entidad compuesta y sus entidadescomponentes. Ambas representan una relación no simétrica en la que una de las extremidades juega un rolpredominante en relación a la otra, por lo cual sólo lleva un rol. La figura 10 muestra el diagrama UML deuna clase de objetos compuestos.

Figura 10. Agregación y composicón en UML.

El protocolo o interfaz es el conjunto de operaciones o métodos declarados como posibles de invocar oactivar por los otros objetos. Los mensajes son la especificación de un objeto junto con la invocación deuno de sus métodos. Por lo general, el pase de mensajes tiene la forma

objetoDestino.nombreDelMétodo(listaDeArgumentos)La encapsulación es la propiedad que permite que los objetos sean definidos en su estructura y sucomportamiento, obligando al uso del pase de mensajes o de la invocación de sus métodos, si se quiereacceder al objeto.La herencia es la propiedad que tienen las clases de heredar de sus superclases estructura y/ocomportamiento. La herencia estructural es aquella donde se hereda la estructura y la herencia decomportamiento cuando se heredan los métodos. La herencia se puede tipificar como: simple o múltiple.La herencia simple se da cuando la subclase hereda solamente de una superclase, y es múltiple cuandohereda de varias superclases. La herencia múltiple presenta problemas de ambigüedad cuando hay

Base de Datos II

18

atributos o métodos con el mismo nombre en varias de las superclases. La solución a dicho problema es ladeclaración explícita de cada uno de ellos junto con la superclase de la que se hereda.En la figura 5 se puede ver un ejemplo de herencia simple, la subclase Estudiante, y un ejemplo deherencia múltiple, la subclase Preparador. Esta última debe explicitar la herencia de los atributos ymétodos de Persona a través de una de sus dos superclases, para evitar ambigüedades en el pase demensajes.Polimorfismo significa que se puede usar el mismo nombre para la definición de un método en variasclases sin importar la relación entre las mismas. Ejemplo: el operador + para tipos numéricos y para tiposcaracter. Para que el polimorfismo sea posible se utilizan los conceptos de: reescritura y encadenamientotardío o dinámico. La reescritura o sobrecarga es la que permite nombrar código diferente con el mismonombre para más de una clase de objetos. El encadenamiento tardío permite seleccionar el códigoadecuado al objeto definido en la invocación del método. Un ejemplo de ello se puede observar en lafigura 5 donde el método desplegar() se define para cada una de las clases de dicha figura.Notación UMLEs una fusión de las notaciones de Booch, OMT, OOSE y otras. UML ha sido concebida para ser simple,intuitiva, homogénea, coherente, genérica y para ser extensible y configurable por el usuario.Elementos comunesLos elementos son la base de UML, que pueden ser: de modelado y de visualización, como lo muestra lafigura 11. Los elementos se agrupan en paquetes que contienen referencias a los elementos de modelado.Un modelo es una abstracción de un sistema representado por un árbol de paquetes.

Figura 11. Metamodelo de UML.Mecanismos comunesDefinen y aseguran la integridad conceptual de la notación UML y se componen de: los estereotipos, lasetiquetas, las notas, las restricciones, la relación de dependencia y las dicotomías (tipo, instancia) y(tipo, clase). Cada elemento de modelado posee una especificación que contiene la descripción única ydetallada de todas las características del elemento. Los estereotipos (clichés) especializan las clases delmetamodelo, las etiquetas extienden los atributos de las clases del metamodelo y las restriccionesextienden la semántica del metamodelo, todos ellos permiten la extensión de UML. La figura 12 muestralos mecanismos comunes.

Base de Datos II

19

Figura 12. Metamodelo de UML. Mecanismos comunes.Los estereotipos facilitan la unificación de conceptos cercanos como los subsistemas y las categorías,permiten la extensión controlada de las clases del metamodelo. Se representan con <<nombre delestereotipo>>.Etiqueta es un par (nombre, valor) que describe una propiedad de un elementos de modelado, ellamodifica la semántica del elemento que califica.Una nota es un comentario asignado a uno o varios elementos de modelado.Una restricción es una relación semántica cualquiera entre los elementos de modelado, que se puedenexpresar en lenguaje natural, en pseudocódigo, con expresiones de navegación o por expresionesmatemáticas.Una relación de dependencia define una relación de uso unidireccional entre dos elementos de modelado,denominados fuente y blanco de la relación, respectivamente. Las notas y las restricciones pueden serfuente de una relación de dependencia.Numerosos elementos de modelado representan una dicotomía (tipo, instancia) en la cual el tipo denotala esencia del elemento y la instancia con sus valores corresponde a una manifestación del tipo. Ladicotomía (tipo, clase) corresponde a la separación entre la especificación de un elemento que esdenotado por el tipo y la realización de esa especificación que está dada por la clase.Tipos primitivosSon los tipos elementales que no son elementos de modelado y no poseen ni estereotipos, ni etiquetas nirestricciones. Ellos son:

• Booleano: es un tipo enumerado con dos valores: Verdadero y falso.• Expresión: es una cadena de caracteres.• Lista: es un contenedor donde el contenido puede ser ordenado e indizado.• Multiplicidad: es un conjunto no vacío de enteros positivos extendido con *, que significa de

multiplicidad ilimitada.

Base de Datos II

20

• Nombre: es una cadena de caracteres que designa un elemento. Nombre compuesto = nombresimple {'.' nombre compuesto}. Nombre calificado con el paquete al que pertenece = paquete '::'nombre

• Punto: es una tupla (x, y, z) que indica la posición en el espacio, por omisión z = 0.• Cadena: es una cadena de caracteres que tiene un nombre.• Tiempo: es una cadena que representa un tiempo absoluto o relativo.• No interpretado: es un blob, cuyo significado depende del dominio.

PaquetesPermiten dividir un modelo y reagrupar y encapsular los elementos de modelado y se representa con unacarpeta con nombre, como lo muestra la figura 13. Poseen una interfaz y una realización. Cada uno de suselementos posee un parámetro que indica si es o no visible al exterior del paquete. Se recomienda que elgrafo de paquetes sea un grafo acíclico.

Los diagramas de UMLEllos permiten visualizar y manipular los elementos de modelado. Normalmente son grafos donde losnodos y los arcos tienen diferentes representaciones dependiendo del tipo de diagrama. Ellos muestrantodo o parte de las características de los elementos de modelado, según el nivel de detalle útil en elcontexto del diagrama. La lista de los diagramas es la siguiente:

• Diagrama de clases: representa la estructura estática en términos de clases y asociaciones. Serealizan con las clases y sus asociaciones, que pueden o no ir en paquetes. La figura 14 muestra unejemplo.

Figura 14. Diagrama de clases en UML.• Diagrama de casos de uso: representa las funciones del sistema desde el punto de vista del

usuario. Un caso de uso es una secuencia de acciones efectuadas por un actor del sistema, es decir,ellos permiten definir los límites del sistema y sus relaciones con el ambiente, haciendo concretoel futuro sistema en una formalización cercana al usuario, así no exista un sistema anterior. EnUML se representan con una elipse contenida por el sistema. La figura 15 presenta un ejemplo.Un actor representa el rol jugado por una persona o cosa que interactua con el sistema. La mismapersona puede jugar varios roles y varias personas pueden jugar el mismo rol. Hay cuatro grandescategorías de actores:

• Principales: las personas que utilizan las funciones principales.• Secundarios: las personas que efectuan tareas administrativas o de mantenimiento.• Externos: los dispositivos que forman parte del dominio de aplicación y que deben ser

utilizados.• Otros sistemas: los sistemas con los que debe interactuar.

Base de Datos II

21

Figura 15. Casos de uso en UML.

Los actores se describen de forma clara y concisa en tres o cuatro líneas. Los casos de uso sedeterminan observando y precisando, actor por actor, las secuencias de interacción (escenarios) desdeel punto de vista del usuario. Un escenario es un camino particular a través de la descripción abstractay general dada por el caso de uso. Un caso de uso agrupa una familia de escenarios de uso según uncriterio funcional. Los casos de uso se ven como clases cuyas instancias son los escenarios.

Las relaciones entre los casos de uso son: comunicación, donde el actor inicia la interacción indicadocon una flecha; utilización, donde una instancia del caso de uso fuente utiliza el comportamiento delcaso de uso destino; y extensión, donde un caso de uso extiende el caso de uso destino. En general,sólo hay un actor por cada caso de uso y para su realización es conveniente responder las preguntassiguientes: ¿Cuáles son las tareas del actor?, ¿Cuáles datos o información el actor debe crear, guardar,modificar, destruir o leer?, ¿Debe el actor informar al sistema de los cambios externos? y ¿Debe elsistema informar al actor las condiciones internas?. La descripción se debe concentrar en lo que DEBEHACERSE y NO en la manera de hacerlo. La descripción de un caso de uso contiene: su inicio (queevento lo dispara), su fin (que evento lo para), la interacción con los actores, el intercambio deinformación, la cronología y origen de las informaciones, las repeticiones de comportamiento y lassituaciones opcionales. Si un caso de uso es muy complejo (por ejemplo más de diez páginas) esposible dividirlo en casos más pequeños. El enfoque orientado por objetos materializa un caso de usopor medio de la colaboración entre los objetos. Los escenarios se representan con los diagramas deinteracción.

Diagrama de estado-transición: representa el comportamiento de una clase en término de susestados. La figura 16 muestra un ejemplo.

Diagrama de actividades: representa el comportamiento de una operación en términos de susacciones. La figura 17 presenta un ejemplo.

Base de Datos II

22

Figura 16. Diagrama de estado-transicion en UML.

Figura 17. Diagrama de actividades en UML.

Base de Datos II

23

Diagrama de secuencias: es una representación temporal de los objetos y sus interacciones. Lafigura 18 muestra un ejemplo.

Figura 18. Diagrama de secuencias en UML.

Diagrama de colaboración: es una representación espacial de los objetos, sus enlaces y susinteracciones. (junto con los de secuencias se denominan, diagramas de interacción). La figura 19presenta un ejemplo.

Base de Datos II

24

Figura 19. Diagrama de colaboracion en UML.

Diagrama de objetos: representan los objetos y sus relaciones, corresponden a diagramas decolaboración simplificados sin representación de los envios de mensajes. La figura 20 muestra unejemplo.

Figura 20. Diagrama de objetos en UML.

Diagrama de componentes: representa las componentes físicas de la aplicación.Diagrama de despliegue: representa el despliegue de las componentes sobre los dispositivosfísicos.

MetamodeloNumerosos elementos de modelado presentan la dicotomía (esencia, manifestación) por la cual untipo representa la esencia de una abstracción y la instancia es la manifestación concreta, asimismola dicotomía (especificación, realización) donde las clases y los tipos primitivos realizan los tipos.

Base de Datos II

25

Un tipo especifica un dominio de valores y un conjunto de operaciones aplicables a esos valores.Una clase realiza un tipo. La figura 23 ilustra tales dicotomías. La clase Tipo comprende lasclases: tipo primitivo (entero o enumerado), clase y caso de uso. La clase Clase comprende:clase activa que tiene un o varios flujos de ejecución; señal que es un evento con nombre;componente que es un elemento reutilizable de componentes físicas y nodo que es un dispositivofísico sobre el cual las componentes pueden ser desplegadas para su ejecución.

Figura 23. Metamodelo de las clases en UML.

UML define cinco relaciones, la más general, la relación de dependencia se aplica de formauniforme a todos los elementos de modelado. La asociación y la generalización conciernen atodos los tipos, en particular a las clases y a los casos de uso. Las transiciones y los enlaces seaplican a ciertos elementos de modelado del comportamiento. La figura 24 ilustra estas relaciones.La asociación representa una conexión semántica bidireccional entre tipos, posee al menos dosroles, cada rol tiene los atributos siguientes:

Figura 24. Metamodelo de las relaciones en UML.

• Multiplicidad: especifica el número de instancias que participan en la relación.

Base de Datos II

26

• Navegabilidad: precisa si los enlaces, instancias de asociación, son navegables en ladirección del rol considerado.

• Agregabilidad: especifica si las instancias del tipo asociado al rol son el todo en unarelación (todo, partes). Sólo uno de los roles puede tener este atributo en verdadero. Si lamultiplicidad del rol es 1, significa que el todo posee las partes y por ello la destruccióndel todo implica la destrucción de las partes. Si la multiplicidad es mayor que 1, variasinstancias juegan el rol de todo y comparten las partes, la destrucción de una de lasinstancias del todo no implica la destrucción de las partes, sólo la destrucción de todas lasinstancias del todo implica la destrucción de las partes.

• Cambiable: precisa si la semántica de la asociación se mantiene luego de que unainstancia del tipo que participa en el rol es reemplazada por otra.

• Ordenada: se aplica si la multiplicidad es mayor que 1 y significa que las instancias estánordenadas.

La generalización especifica una relación de clasificación por la que una instancia de un subtipopuede ser substituida por una instancia del supertipo. Un supertipo puede tener varios subtipos yun subtipo puede tener varios supertipos. Todo elemento generalizable posee los atributos lógicossiguientes:

• Abstracto: Si es verdadero indica que el elemento no puede ser instanciado directamente.• Hoja: Si es verdadero indica que el elemento no puede tener subtipos.• Raíz: Si es verdadero indica que el elemento no puede tener supertipos.

UML define tres elementos generalizables: stereotipo (no puede tener subtipos), paquete (nopuede tener supertipos) y tipo. La figura 25 muestra la relación de generalización y dedependencia. La dependencia es una relación de uso unidireccional entre los elementos.

Figura 25. Metamodelo de las generalizaciones y dependencias en UML.

Base de Datos II

27

Ventajas y desventajas de la orientación por objetos

Las ventajas de la programación orientada por los objetos son las siguientes:• La abstracción de datos y el ocultamiento de la información aumentan la confiabilidad y

ayudan a separar la especificación de la implantación.• El encadenamiento dinámico incrementa la flexibilidad.• La herencia junto con el encadenamiento tardío permite la reusabilidad aumentando así la

productividad.Entre sus desventajas se encuentran:

• El costo de tiempo de ejecución del encadenamiento tardío puede llegar a ser importantedependiendo de la aplicación.

• La implantación con lenguajes orientados por objetos es más compleja que con loslenguajes convencionales.

• El programador debe leer con frecuencia extensas librerías de clases.