cenidet jose... · sistema administrador de estruduras datos complejas persistentes contenido i 4...

SEP SEIT DGIT

CENTRO NACIONAL DE INVESTIGACION Y DESARROLLO TECNOL~GICO

cenidet DISENO E IMPLEMENTACIÓN DE UN SISTEMA

ADMINISTRADOR DE ESTRUCTURAS DE DATOS COMPLEJAS PERSISTENTES

TESIS

QUE PARA OBTENER EL GRADO DE MAESTRO EN CIENCIAS DE LA COMPUTACIÓN

PRESENTA CkN?RO DE !NFORMLIOb

C F N I D F ' F -.. JOSÉ GUILLERMO FIERRO MENDOZA

ASESOR: M.C. RENÉ SANTAOLAYA SALGADO

COASESOR: M.C. ANDRÉS F. RODRiGUEZ MARTINEZ

! CUERNAVACA, MORELOS MAYO DE 1998

9 8 - Q 5 i a;.'

SISTEMA NACIONAL DE INSTITUTOS TECNOL6GICOS

Centro Nacional de Investigación y Desarrollo Tecnológico

FORMA A3 REVISION DE TESIS

REV 1297 Cuemavaca, Morelos a 26 de mayo 1998

M.C. Máximo iópez Sánchez Presidente de la Academia de Ciencias Computacionales Presente

Nos es grato comunicarle, que conforme a los lineamientos para la obtención del grado de Maestro en Ciencias de este Centro, y después de haber sometido a revisión académica la tesis denominada: Diseño e Implementación de un Sistema Administrador de Estructuras de Oqtos Complejas Persistentes, realizada por el. C. José Guillenno Fierro Mendota, y habiendo cumplido con todas las correcciones que le fueron indicadas, acordamos no tener objeción para que se le conceda la autorización de impresión de la tesis.

Sin otro particular, quedamos de usted.

Atentamente

La comisión de revisión de tesis I i,

b\. G".It=fL. M.C. Mano Guillen Rodriguez M.C. H u g m d a Esquive1

M.C,AÚrn&íto Hemández Garcia (1. Asesor de tesis

Ccp Dr. Javier Oriiz HemandedJefe del Departamento de Ciencias Cornputacionales

Institutos Tecnológicos SO aiios de educación superior tecnológica en M6xico

I I

SISTEMA NACIONAL DE INSTITUTOS TECNOLdGlCOS

Centro Nacional de Investigación y Desarrollo Tecnológico FORMA A4

AUTORIZACION DE IMPRESIÓN DE TESIS REV 12/97

Cuernavaca, Morelos a 27 de mayo de 1998

C. José Guillermo Fierro Mendoza Candidato al grado de Maestro en Ciencias de la Computación. Presente

Después de haber atendido las indicaciones sugeridas por la Comici 1 Revisora de la Academia de Ciencias Cornputacionalec en relación a su trabajo de tesis: Diseño e Implementacián de un Sistema Administrador de Estructuras de Datos Complejas Persistentes, me es grato comunicarle, que conforme a los lineamientos establecidos para la obtención del grado de Maestro en Ciencias en este Centro, se le concede la autorización para que proceda con la impresión de su tesis.

Atentam te L Ortiz Hernández de Ciencias Computacionalec

institutos Tecnológicos 50 años de educación superior tecnológica en México

ki?W64tritlb

APARTADOWSTAL 5-164.CP62051,CUERN/\VACA.MOR.M~lCO-TELS.(73)12 2314.12 7613 ,FAX(73) 12 2434-WAIL: renidcrl @inforel.nci.mx

DEDICATORIA

Con todo mi amor, cariño y respeto a mis padres:

Manuel Fierro Pérez Y

María Mendoza de Fierro.

a mis hermanos, por su apoyo y confianza

Apolinar Vicente Jesús

Ernesto Victor

Luz Elvia

a mis hijos:

Paola Marian Y

José Alejandro

Y en forma muy especial, por su invaluable apoyo, su dedicación y motivación para la terminación de este trabajo,

con iodo mi amor para mi esposa,

Martha Elena

AGRADECIMIENTOS

Extemo mi agradecimiento a mi asesor, al M.C. René Santaolaya Salgado, por sus excelentes comentarios, su tiempo y motivación:

Agradezco a mi co-asesor, M.C. Andrés F. Rodriguez Martinez, por su confianza, su tiempo y apoyo en el inicio del trabajo.

Agradezco al jefe del departamento de Ciencias Computacionales. Dr. Javier Ortiz Hemández por su apoyo.

A mis revisores de tesis, M.C. Mario Guillén, M.C. Hugo Estrada, M.C. Humberto Hemándéz, por sus comentarios y su valiosa cooperación en la revisión de este trabajo.

A Olivia Graciela Fragoso, por su apoyo, su valioso tiempo y sus valiosos consejos

Agradezco a la comunidad del CENIDET por los gratos momentos que pasé en mi estancia y que siempre recordaré.

A Roberto González y Pili, por su amistad y por el tiempo que compartimos juntos en CENIDET.

A mis compadres Juan Carlos y Cristina y familia. Hidori, Ian, Ale, Doña Licha y Raúl. quienes con su ayuda y motivación permitieron la consecución de este logro.

A nuestros amigos Mario y Lolita y a Francisco G. y Claudia.

A mis compañeros de trabajo en el Instituto Tecnológico de Celaya, Juanita, Donato, Noel V., María de Jesús., Ana Bertha., el Dr. Monsivais. Ricardo G. Guillermo A,.

Agradezco al Ing. Rubén Valles y al Ing. José Luis Guerrero, por su apoyo.

A mis buenos amigos, Filemón y Laurita.

A mis comadres Naty y Micha, a mis cuñadas Hilda y Mary y a todos mis sobrinos.

A otros buenos amigos Alejandro y Gloria.

En general a todas las personas que me apoyaron y alentaron para terminar mi trabajo de tesis.

Sistema Administrador de Estruduras de Datos Complejas Persistentes

CONTENIDO

I 4

10

10

12 12 3.1

3.2 El Paradigma de La Programación Orientada a Objetos. 15 3.2.1 Los Objetos. 15 3.2.2 Conceptos del modelo orientado a objetos. 15 3.2.3 16 3.2.4, 17

3.2.4.1 17 3.2.4.2 18

3.2.4.4 Objetos y valores 19 3.2.4.5 19

. . 1. Introducción

2. Objetivos y Descripción del problema. 2.1 Objetivo General.

2.2 Alcance

3. Marco Teórico. Estructuras de Datos Complejas. Definición.

La programación Orientada a Objetos (siglas en inglés OOP). La Programación Orientada a Objetos y las Bases de Datos.

Conceptos Básicos del Modelo de Datos Orientado a Objetos. Los manejadores de Bases de Datos Orientados a Objetos.

3.2.4.3 Objetos y los identificadores de los objetos. 18

3.2.4.6 Objetos Complejos. 20 3.2.4.7 Encapsulación. 21

3.2.4.7.1 Métodos 22 3.2.4.7.2 Acceso y Manipulación de Atributos 22

3.2.4.8 Clases. 23 3.2.4.8.1 Clases y Tipos 23 3.2.4.8.2 Clases y Mecanismos de Instanciación. 24

3.2.4.8.4 Migración de instancias entre clases 25 3.2.4.8.5 Persistencia de las instancias de las clases 25 3.2.4.8.6 Metaclase 26

3.2.4.9 Herencia. 27 3.2.4.10 Sobrecarga, sobreescritura y ligado tardío. 30 3.2.4.1 I Un ejemplo. 32

Diferencias con el concepto de llave del modelo relaciona1

3.2.4.8.3 Jerarquías de Agregación 25

4. Arquitectura del SAEDCP. 35 4.1 Componentes del SAEDCP 35 4.2 Arquitectura del SAEDCP. 38

4.2.1 El Sistema Administrador de Estructuras de Datos Complejas. 38

5. Análisis y Diseño del SAEDCP 45

5.1 Identificación de las clases principales. 45

5.2 Identificación de las Relaciones entre clases. 41 5.3 49 5.4 Validación del Modelo. 62

5 4 I Diagramas de interacción entre objetos 62

Identificación de Atributos y Operaciones de las Clases del SAEDCP.

I

Sistema Adminislrador de Es1NciURS de Datos Complejas Persistentes

5.5 Diagramas de Implementacion. 70

6. Construcción de Aplicaciones Usando el SA EDCP 72 6.1 Ejemplo 1 72

6.2 Ejemplo 2. 77

6.3 Ejemplo 3. 80

Z CONCLUSZONES 86 7.1 Beneficios. 86

7.2 Alcances logrados. 87

7.3 complejas persistentes (SAEDCP). 88

Sugerencias para mejoras y ampliaciones del administrador de estructuras de datos

Anexo A 86

Anexo B 90

Anexo C 96

112 Glosario

116 Referencias Bibliográficas

~ d ~ i ~ i ~ ~ ~ ~ ~ ~ ~ de Estructuras de Datos Complejas Persistentes

LISTA DE FIGURAS

~i~~~ 2.1-1

~i~~~ 2.1-2 ~i~~~ 2.1-3

13 Figura 3.1-1 Figura 3.1-2 14 Figura 3.1-3 14 Figura 3.2.4.8-1 27 Figura 3.2.4.9-1 Un extracto de una base de datos 28 Figura 3.2.4.9-2 Un ejemplo de herencia 29

33 37

Figura 4.2-2 Sistema de Archivos del SAEDCP para lograr la persistencia- 40 Figura 4.2-3 Comunicación del DBA con el SAEDCP 42

Figura 5.2-1 Diagrama de Relaciones entre clases del SAEDCP 46

Figura 5.3-2 Atributos de la clase ARCHIVO 48 Figura 5.3-3 Atributos de la clase Header-Arbol 48

Esquema planteado para controlar la producción en una Planta 6 manufacturera

Solución del ejemplo de la figura 2.1-1 usando el modelo Elks- 7 Solución por medio del Sistema Administrador de Estructuras de

Diversas estructuras de datos básicas El estado de una estructura compleja en un determinado tiempo- El estado de la misma estructura en otro tiempo Ejemplo de una relación entre una Metaclase y su clase

Datos Complejas Persistentes 9

Figura 3.2.4.1 1-1 Ejemplo de un esquema de base de datos O 0 Figura 4.1-1 Componentes de un sistema de base de datos Figura 4.2-1 Arquitectura del SAEDCP 39

Figura 5.1-1 Conjunto de Clases del SAEDCP 45

Figura 5.3-1 Aiributos y Operaciones de la clase string 47

Figura 5.3-4 Atributos de la clase infoArbol 49 Figura 5.3-5 Atributos y Propiedades de la clase treeDisco 49 Figura 5.3-6 Atributos y métodos.de la clase DynArray 50 Figura 5.3-7 Atributos de clase IOBASE 53 Figura 5.3-8 Métodos Públicos de la clase IOBASE 54 Figura 5.3-9 Métodos Públicos de la clase IOBASE (continuación) 55

Figura 5.3-1 1 Figura 5.3-12 Métodos de la clase IOout 59 Figura 5.4.1

Figura 5.3-10 Métodos Privados de la clase IOBASE 56 58 Atributos y Métodos de la clase Btree

Diagrama de Interacción que muestra el Almacenamiento de 'm Objeto Persistente 62 Diagrama de Interacción Para la Recuperación de un Objeto Figura 5.4-2 Persistente 64 Diagrama de Interacción Para Desplegar los Objetos Contenidos Figura 5.4-3 . - en una Base de Datos 65

Figura 5.4-4 Diagrama de Interacción Para Borrar un Objeto 67 Figura 5.5-1 Diagrama de Componentes del SAEDCP 69

Figura 6.3-1 Diagrama de Clases del Ejemplo 3 78 Figura 6.2-1 Relación de Asociación Producto-Componente 75

http://mtodos.de

Sistema Adminislrador de Estructuras de Dalos Complejas Persistentes

Una de las características de las necesidades actuales dentro de cualquier organización es la búsqueda de alternativas de solución que permitan elevar la productividad y lograr un uso más eficiente de los recursos. En el desarrollo de software esto se ha convertido en un cambio permanente, buscando este tipo de soluciones para solucionar problemas cada vez más complejos. Para los desarrolladores de software el uso de Iss bases de datos no es nada nuevo. Casi cualquier aplicación requiere el uso de una forma de almacenamiento permanente. Las bases de datos se usan en cualquier plataforma de hardware o de software. En las últimas tres décadas se ha evolucionado desde la forma simple de manejo de archivos hasta el uso de sistemas de bases de datos relacionales, que a pesar de sus limitaciones se han consolidado dentro del medio de desarrollo. Sin embargo, los recientes avances tecnológicos han provocado el desarrollo de nuevos sistemas de hardware y software, los cuales permiten resolver problemas del mundo real cada vez más complejos. La tendencia actual de las aplicaciones de las bases de datos no se restringe a las aplicaciones tradicionales, como el control de inventarios, sino que la relación con aplicaciones que involucran grandes volúmenes de información y las conexiones entre esta información es más compleja. El tamaño y complejidad de los datos hace casi imposible agrupar los datos relacionados, ya que se requiere un mecanismo complejo para accesarlos y actualizarlos. Ejemplos de este tipo de problemas, se encuentran generalmente en aplicaciones de ingeniería, donde destacan principalmente:

Diseño Asistido por Computadora (CAD) Manufactura Asistida por Computadora (CAM). Sistemas Para Manejo de Información Geográfica. Simulación de Procesos y Sistemas en diversas áreas, como ingeniería Química, ingeniería Mecánica, ingeniería Industrial, etc. Sistemas de Mímicos para monitoreo de procesos que requieren adquisición y análisis de datos de planta. en la industria.

Para resolver los problemas de aplicaciones de Ingenieria de este tipo se debe contar con herramientas de software que permitan crear y manipular estructuras complejas que involucran no sólo texto, sino también información acerca de gráficas, imágenes, voz, información geométrica de objetos, etc.

Sistema Adminislrsdor de ~structuras de Datos Complejas Persistentes

La forma tradicional de resolver problemas que involucran el manejo de estructuras complejas, ha sido a través del desarrollo de ambientes que son creados mediante diversos lenguajes de programación (c, FORTRAN, PASCAL etc). Cuando estos desarrollos requieren la persistencia de sus estructuras es necesario implementar una interface a la medida de la aplicación que permita almacenar y recuperar la información, la cual generalmente se desmolla con Bases de Datos relacionales o archivos tradicionales, con el inconveniente de que cada vez que se desarrolla un nuevo sistema, es necesario diseñar una nueva forma de implementar cada acción, lo que cuesta mucho tiempo dinero y esfuerzo.

Una solución más eficiente a los problemas planteados anteriormente requiere la conjunción de las bases de datos y el medio para desarrollar la aplicación en un mismo ambiente, por lo que es necesario contar con herramientas para bases de datos que permitan definir y manipular los datos de una manera natural. Es decir, que en el mismo ambiente se defina la estructura de los datos y la aplicación misma. (Ref .2)

A manera de introducción se pudiera establecer que una structura de datos compleja es aquella que en un momento dado puede estar formada por otras estructuras de diferentes tipos y que éstas a su vez puedan estar constituidas por otras estructuras de datos y así sucesivamente, lo que hace muy difícil su manipulación en uno de los esquemas de bases de datos tradicionales.

Esta tesis contempla el diseño e implantación de un sistema que permita la manipulación de estructuras de datos complejas persistentes. La idea que dio origen a este trabajo de tesis fue el propósito de dar solución a problemas de manejo de administración de grandes cantidades de datos y sus relaciones complejas que se utilizan en sistemas de CAD y modelado geométrico. La solución que se plantea consiste en el desarrollo de un sistema administrador de datos que permita la persistencia, usando un lenguaje de programación orientado a objetos comercial, en este caso el lenguaje C++, y mediante el diseño de una interfaz apropiada, logre de una manera natural el almacenamiento de la información que el usuario requiera dentro del proceso de desarrollo de una aplicación. Esto conlleva al manejo de una metodología de análisis y diseño orientada a objetos. Como un punto importante se puede mencionar que dentro del análisis del sistema, se puede apreciar que la solución que se propone es aplicable en muchas áreas de interés, como es el caso de las bases de datos inteligentes, sistemas de simulación de procesos, sistemas de información geográfica, etc.

El material de la tesis está organizado de la siguiente manera:

En el capitulo 2, se especifica la problemática a resolver mediante el uso del Sistema Administrador de Estructuras de Datos Complejas Persistentes (SAEDCP), así como el análisis de requerimientos.

2

Sistema Administrador de Eslrunuras de Datos Compleias Persistentes

En el capítulo 3, se presenta el marco teórico donde se definen los conceptos básicos de estructuras de datos complejas. de la programación orientada a objetos. y sobre todo los conceptos y características de las bases de datos orientadas a objetos.

En el capítulo 4 se presenta la arquitectura del Sistemas Administrador de Estructuras de Datos Complejas Persistentes (SAEDCP). Se describe también la estructura de los archivos utilizados para el manejo de la información persistente de un conjunto de estructuras complejas.

En el capítulo 5 , se detalla el proceso de diseño haciendo uso de la metodología orientada a objetos el lenguaje unificado de modelado (en inglés UML), presentando los diagramas de clases y diagramas de objetos correspondientes, asi como los diagramas de interacción entre los diversos objetos que componen el sistema.

En el capítulo 6, se presenta el proceso de interacción de una aplicación con el SAEDCP, la forma de usar las clases persistentes definidas y la forma de driinir nuevas clases, para adaptarlas a nuevas aplicaciones. Esta aplicación servirá como modelo de evaluación y casos de prueba para obtener conclusiones respecto a la herramienta generada en este trabajo.

Finalmente, en el capítulo 7 se presentan las conclusiones de este trabajo

3

Sistema Adminislrador de Estructuras de Dalos Complejas Pemislenles

La Programación Orientada a Objetos tiene como meta primordial incrementar la productividad del programador mediante la extensibilidad y reusabilidad del software, controlindo también la complejidad y el costo del mantenimiento del software. En términos generales la orientación a objetos es un modelo de software que facilita la construcción de sistemas complejos partiendo de componentes individuales. construidos previamente.

Sin embargo, algunos lenguajes que soportan este paradigma, aun no integran, de manera natural, la aplicación con la persistencia de las estructuras de datos complejas. Un primer intento para aplicar el paradigma orientado a objetos para la manipulación de datos ha sido la creación de interfaces orientadas a objetos sobre DBMSs relacionales, sin embargo, esta solución no ha sido del todo satisfactoria,.por la razón de que el diseño es orientado a objetos y la implementación no lo es, (Ref. 1).

Como una solución o un soporte para la definición, manipulación y persistencia de estructuras complejas, surgen los manejadores de bases de datos orientados a objetos (siglas en inglés OODBMS) que nacen de la fusión de la Programación Orientada a Objetos (OOP) y los manejadores de Bases de Datos (DBMS), es decir, las funciones de persistencia están integradas dentro del lenguaje de programación. Los sistemas más avanzados, tales como Avance, Encore, Gemstone, Iris, O,, Orion y Vbase, han tomado el enfoque de diseñar una arquitectura para soportar directamente el paradigma orientado a objetos.

Lo anterior induce a pensar que los lenguajes de programación deben contar con facilidades para guardar; recuperar y manipular información de estructuras de datos complejas, que se adapten a los requerimientos propios de cada aplicación. Sin embargo, el lenguaje de programación más comúnmente utilizado en aplicaciones que implican desarrollos complejos, el lenguaje C, no está equipado con esta facilidad. El lenguaje C++, permite la orientación a objetos, pero no con las facilidades para manipular las estructuras de datos complejas en disco. En esta tesis se implementa un Administrador de Estructuras de datos Complejas Persistentes en el lenguaje C+ +, sobre la plataforma Windows.

En el diseño de aplicaciones de ingeniería se presentan generalmente problemas con el manejo y persistencia de datos, ya que en la mayoría de las veces, las aplicaciones requieren

4

sistema Administrador de Eslwciuras de Dalos Complejas Persistentes

de operaciones sobre estructuras de datos complejas. hi Cuales invohcran generalmente dentro de SU definición otras estructuras de datos para formar estructuras anidadas 0 cíclicas, lo cual, en el modelo de bases de datos relaciona1 no se puede implementar de una manera natural.

A continuación se describe un ejemplo de una aplicación que maneja este tipo de estructuras de datos, con el fin de mostrar cómo podría definirse una aplicación dentro del Sistema Administrador de Estructuras de Datos Complejas y su diferencia con los manejadores de bases de datos relacionales.

Se trata de implementar un sistema de base de datos para tener el control de la producción planeada en una planta- de manufactura, para sus diversos productos, con base en los componentes requeridos por producto, el numero de máquinas y el tiempo requerido para lograr el producto. La planta cuenta con dos sistemas de manufactura, uno para producción nacional y otro para producción de exporiación.

Un esquema con los diferentes elementos en forma de árbol que forman el sistema 51 muestra en la Fig. 2.1-1. Primero se detallan las estructuras simples como PRODUCTO, COMPONENTES Y LINEAS DE ENSAMBLE y después se agrupan en una estructura final, llamada PRODUCCION-PLANEADA, la cual contiene las dos clases de producción (nacional y exportación).

5

Sistema Admlnlstrador de EslNnuras de Dalos Complejas Persistentes

COMPONENTES LINEA-ENSAMBLE

:ODIC0 3

t ELEMENTO COMPONENTE MAQUINA SUPERVISOR TIEMPO ENSAMBLE

PRODUCTO

I I I I CODlGO PRODUCTO DESCRIPCION COMPONENTES

MANUFACTURA-PRODUCTO

I CANTIDAD

I LINEA-ENSAMBLE

I PRODUCTO

Figura 2.1-1 Esquema planteado para controlar la produccibn en una planla manufaclurera

6

Sistema Adminislrador de Esinicluras de Datos Complejas Pers!slenles

(lene)

I

~~~~

Una solución por medio del modelo ELKA para el diseño del sistema, podría ser el mostrado en la Fig. 2.1-2, donde se muestran entidades y las relaciones entre ellas.

~

Codigo-Producto Partidal

Pa rl I d a 2 - I

- (tiene)

Codigo-Componente Codigo-Producto Codigo-componente

Descripcion

COMPONENTE PRODUCTO

(está en)

r---- Partidal

Distribuidor

L - (tiene)

Linea-Ensamble Cantidad

PRODUCTO

(esla formada por)

Linea-Ensamble

Maquina Supervisor Tiempo-Ensamble

ENSAMBLES

Partida2

Embarque Pais

EXPORTACION I

11 PRODUCCION

(tiene) b-- SOLUCION POR MEDIO DE BASES DE DATOS RELACIONALES

(MODELO ELKA)

Figura 2.1-2 Solución del ejemplo de la figura 2.1-1 usando el Modelo Elka

7

Sistema AdminisIradoc de EstNcluras de Datos Complejas PerSiSlenteS

El uso del modelo relacional, implica el desarrollo de mecanismos para el control de las relaciones entre las entidades, ya que el establecimiento de la relación se basa en un atributo común a dos entidades. Y por lo tanto se presenta la desventaja de que cuando se modifica el esquema de la base de datos en una de sus llaves deben modificarse todas las entidades relacionadas a través de esta llave.

La solución por medio del sistema administrador de estructuras de datos complejas, desarrollado en esta tesis, se muestra en la Fig. 2.1-3, donde puede apreciarse claramente que la definición de tipos por el usuario, definidos por cada caja, y el soporte de las relaciones de asociación, agregación y generalización/especialización proporcionan una solución natural, es decir, se evita la repetición de la información para el establecimiento de las relaciones.

En la Fig. 2.1-3 los tipos de datos definidos por el usuario se representan con una caja, con el nombre del tipo de dato en la parte superior, los elementos o atributos que tienen el tipo de dato se enumeran dentro de la caja y su tipo se escribe a la derecha, si el tipo del elemento es otro tipo definido por el usuario, se apunta a ese otro tipo, si la relación es de asociación se apunta con una línea y se pone un rótulo de asociación, si la relación es de agregación se apunta con una flecha al tipo agregado. Las relaciones de generalización/especialización se representan con una flecha más gruesa, para indicar que el tipo de dato de donde sale la flecha hereda atributos del tipo de dato apuntado. Finalmente, para definir una instancia de otro tipo dentro del sistema que proporcione la solución al problema sólo se necesita declarar una instancia del tipo de dato PRODUCCION-

cuando se desee hacer la persistencia de la aplicación sólo se necesita guardar esta instancia para salvar toda la estructura correspondiente, por ejemplo:

PLANEADA-NACIONAL O PRODUCCION-PLANEADA-DE-EXPORTACION, y

Para definir la instancia

PRODUCCION-PLANEADA-NACIONAL variable1

Ypara salvar la instancia:

variablel. G UA R D A R

Como puede observarse, una herramienta que permita la definición de tipos por el usuario, y que soporte relaciones de asociación, agregación y especialización I generalización y sobre todo la persistencia de la información en cualquier instante dado de la aplicación, tiene un potencial muy alto y teniendo en cuenta que dentro de la misma aplicación, puede hacerse la definición de las operaciones sobre los elementos de cada estructura, lo que en un lenguaje orientado a objetos se conoce como la definición de sus métodos, este potencial se incrementa mucho más.

8

Sistema Administrador de Estructuras de Datos Complejas Persistentes

CODIGO S

I DESCRlPClON I C

DISTRIBUIDOR

COMPONENTE -b

CANTIDAD

S

MANUFACTURA J PRODUCTO

LINEA-ENSAMBLE

CANTIDAD

LINEA-ENSAMBLE - .

I s MAQUINA

SUPERVISOR

TIEMPO

PRODUCCION-PLANEADA

EXPDRTACION

EMBARQUE

RELACION DE AGREGACION

S CADENAS

RELACION DE N NUMERICOS ASOClAClON

D FECHA RELACION DE -b ESPEClALlZAClONI

GENERALIZACION

Figura 2.1-3 SoluciOn por medio del Sistema Administrador de Estructuras de Datos Complejas Persistentes (SAEDCP)

9

Sistema Adminislrador de Estructuras de Dalos Compleps Persistentes

21 ObjeavoGeneral.

El objetivo general de la tesis es proporcionar un Sistema Administrador que sirva de apoyo en aplicaciones de ingeniería donde se requiera el manejo de Estructuras de Datos Complejas y su manipulación en disco.

El sistema deberá soportar un amplio rango de aplicaciones, las cuales involucran estructuras de datos que pueden crecer dinámicamente durante la aplicación, y que por lo tanto no se pueden manipular fácilmente usando modelos de bases de datos tradicionales.

Un caso que será posible implenientar usando el Sistema Administrador de Estructuras de Datos Complejas Persistentes (SAEDCP) lo constituye un sistema para manejo de objetos gráficos, en el cual se requiere formar un objeto gráfico que está constituido por diferentes objetos más simples (conocidos como objetos base), es decir la creación de un objeto depende'de un conjunto de otros objetos, pero no se tiene definido este conjunto de objetos hasta que se crea en tiempo de ejecución. El conjunto de objetos base, puede ser representado por una lista de objetos gráficos, en la cual la información en cada uno de sus nodos no está definido sino hasta el momento de la creación del objeto gráfico, que puede ser de tipo círculo, línea, cuadro, doble cuadro, doble circulo, y tal vez figuras que resulten de la combinación de las ya definidas. La construcción del Administrador de Estructuras de Datos Complejas Persistentes debe permitir la implementación de esta aplicación para facilitar el almacenamiento y recuperación de grandes cantidades de objetos complejos.

Ejemplos típicos en los que podría utilizarse el SAEDCP son los sistemas de información geográfica, ya que en ellos el modelo contempla segmentos para definir una calle, la cual tiene un conjunto de nodos asociados para definir los sentidos de las calles, un bloque está definido por un conjunto de calles, una colonia está definida por varios bloques y las ciudades están definidas por varias colonias. La herramienta permitirá construir el modelo de una forma natural, directamente con la semántica del lenguaje, usando el mismo modelo para su almacenamiento y recuperación.

22 Alcance

Como producto de la tesis se contará con un Sistema Administrador de Estructuras de datos Complejas en el cual se podrán realizar diferentes aplicaciones. El sistema soportará:

Definición de tipos y subtipos por parte del usuario

Soporte de las relaciones de asociación, agregación y generalizaciÓn-especial¡zac¡Ón, entre los diferentes tipos declarados por el usuario en cada aplicación.


Adicionar funciones o métodos a las estructuras definidas por el usuario. En esta parte se tiene contemplado que los métodos sean definidos y ligados fuera de línea de la aplicación (compilar y ligar con el SAEDCP fuera de ambiente de ejecución de la aplicación).

Ejecución de las operaciones o métodos de los objetos complejos creados para lograr la manipulación de los elementos de una estructura de datos definida por el usuario.

Consulta de los objetos existentes en el sistema, por aplicación

Persistencia de los tipos de datos definidos y de sus instancias creadas.

Operaciones de altas, bajas y cambios sobre las estructuras de datos definidas

Con el propósito de verificar las operaciones definidas anteriormente se propone como prueba, implantar una aplicación del mundo real en la cual se utilicen estructuras de tipos de datos complejas.

La aplicación propuesta consiste en el desarrollo de un ejemplo escolar que permita mostrar el potencial de la herramienta de estructuras de datos complejas.

11

Sistema Administrador de Eslrucluras de Dalos Complejas Penislenles

%.-

En este capítulo se define el concepto de estructura de datos compleja y la necesidad de dar solución al problema de su administración para lograr su persistencia mediante el uso de lenguajes de programación orientados a objetos. Se definen los conceptos de los lenguajes que usan este nuevo paradigma de programación, así como los conceptos que conllevan a su almacenamiento en disco, como lo son, las bases de datos orientadas a objetos.

3.1 Esbuctums de Datos Complejas. Definición.

1

¡ Una estructura de datos compleja es aquella que se construye dinámicamente a partir de estructuras previamente definidas por el usuario (estructuras básicas), por lo que en cualquier instante de la ejecución del sistema existe incertidumbre acerca de la dimensión de las estructuras en cuanto a longitud y profundidad.' Por ejemplo, supongamos una aplicación contiene las siguientes estructuras básicas mostradasen laFig. 3.1-1.

I I1 'I

' l a Longtud est6 relauonada con el tamaño de la lista y Profunddad can la forma que una estnictura puede tomar, en un momento es de un. lip0 y en otro es de d i o lip0 difemle.

12 I

Sistema Administrador de Erlructuras de Dalos Complejas Persistentes

i

!

/i I

I

1 ! I

! ¡I

I

)I

!

!/

~I

l A B

B C o

I Figura 3.1-1 Diversas Estructuras de Datos Basicas

El uso de formas diversas significa que son estructuras de datos diferentes y que cada una de ellas internamente apunta a otras de ellas para crear una estructura compleja.

Por ejemplo, la estructura básica A puede definirse en el lenguaje de programación C, de la siguiente forma:

struct A I

A *ant; in1 info; char *descrip; B *sig;

1

Este conjunto de estructuras básicas puede fomiar una estructura compleja, de tal forma que dicha estructura compleja puede crecer indefinidamente. En un instante dado, si se analizara el estado de la estructura construida por la aplicación, podria representarse como se muestra en la Fig. 3.1-2.

En otro instante de la misma aplicación, la estructura compleja podria observarse como se muestra en la Fig. 3.1-3, donde se aprecia que debido a su mayor complejidad, existen mayores problemas para su manipulación y almacenamiento en disco.

13

Ststerna Adrninislrador de Estructuras de Dalos Complejas Persistentes

Figura 3.1-2 El estado de una estructura compleja en un deteminado tiempo.

LONGIND

P R O F U N D I D A D

I C

Figura 3.1-3 El estado de la misma estructura en otro tiempo

14

Sistema Adminislradar de Eslrmluras de Datos Compie1as Persistentes

3.2 El Paradigma de La Pmgtamación Orientada a Objetos

La evolución de la ingeniería de software en los años recientes ha influido de modo significativo en el desarrollo de paradigmas más expresivos, que nos permitan modelar el mundo real de la forma más fácil y por lo tanto lo más rápidamente posible. Uno de ellos es el paradigma de la orientación a objetos. Este paradigma hace posible modelar sistemas en términos relacionados con la forma de pensar del ser humano. El tema central en el enfoque orientado a objetos son los objetos y las acciones sobre los objetos.

32.1 Los Objetos.

Los objetos son representaciones de entidades del mundo real en el dominio de la aplicación del software, que pueden describirse en términos de sus atributos y de su comportámiento. Los Objetos pueden interactuar con otros objetos por medio del envio de mensajes, que es el medio de comunicación en los sistemas orientados a objetos (00). Cuando un objeto recibe un mensaje de algún otro objeto, ejecuta un método apropiado como respuesta. Los objetos que son similares a otros objetos en comportamiento y en otras características pueden agruparse en clases, proporcionando un nivel de abstracción que ayuda en la creación de una descripción y especificación genérica para un-grupo de objetos, El siguiente nivel de abstracción consiste en identificar aquellas cosas que son comunes en las c'lases para crear superclases, o clases padres y subclases, generando una jerarquía de clases.

Una definición formal de objeto, es la siguiente:

Un objeto es un tipo de datos abstracto encapsulado cuyas propiedades no son necesariamente valores simples, sino que pueden ser otras entidades de complejidad arbitraria.

32.2 Conceptos del modelo orientado a objetos.

La programación orientada a objetos es la combinación de varios conceptos de la ingeniería de software, tales como encapsulación, ocultamiento de la información, abstracción de datos y programación modular (Ref. t), incorporados a los conceptos de objetos, clases y jerarquías de clases.

La abstracción de datos es la parte central de la programación orientada a objetos (OOP). Un tipo de dato abstracto es un modelo que agrupa atributos del tipo de dato y un conjunto de operaciones, (llamadas métodos) que sirven para manipular los atributos y proporcionar el comportamiento al tipo de dato en cuestión.

Atributo. Es una propiedad de un tipo, identificada mediante un nombre. Identifica una característica de un objeto.

15

Sislema Administrador de Esinicturas de Datos Complejas Persistentes

I !

I I

Ocultamiento de la información. Técnica que hace posible ocultar la complejidad y los detalles de la implementación de un módulo de los módulos de un cliente. Un objeto se obtiene y se modifica solamente a través de interfaces externas definidas para el tipo de dato abstracto. Los detalles internos de la implementación y las estructuras de datos son transparentes a los clientes que manipulan y tienen acceso a los objetos. El concepto está relacionado con la encapsulación.

Encapsulación. Técnica que hace posible definir el alcance para el código de un módulo y sus datos con el fin de limitar el control de acceso por parte de los clientes de su módulo encapsulado. Un módulo está encapsulado si el acceso al módulo por los clientes del mismo puede ser resiringido por medio de la definición del lenguaje para accesar el módulo solamente a través de una interfaz externa.

Un objeto es una instancia declarada para ser del tipo de una clase definida. Un objeto mantiene una copia de todos los campos de datos de la clase, y la modificación de ellos se logra a través de los métodos de la clase. La invocación de un método de una clase se conoce como “enviar un mensaje a un objeto”.

Clase. Los objetos que comparten la misma funcionalidad y características pueden agruparse en clases. Una clase contiene la definición del comportamiento de un objeto y sus atributos.

Con la jerarquía de clases, se permite que una clase herede las características de otra clase, a la que se le da el nombre de clase padre, a la clase que hereda datos de otra pero que requiere características especiales que no son contempladas por el padre se le denomina subclase. De esta forma se implementa el concepto de herencia simple. En la programación orientada a objetos también pueden definirse herencias multiples, donde una clase puede heredar de dos o más padres.

3.23 La programación Orientada a Objetos (siglas en ingles OOP).

Algunos autores definen a la programación orientada a objetos (OOP), como una metodología de programación que está basada en las siguientes características claves:

Los diseñadores definen nuevas clases (o tipos de objetos). Los objetos tienen operaciones definidas sobre ellos mismos. Las invocaciones operan sobre múltiples tipos de objetos (por ejemplo, operaciones genéricas.)

La definición de clases permite compartir componentes comunes usando la herencia.

16

Sistema Administrador de ESINctUraS de Datos Complejas Persistentes

3.2.4 La Programación Orientada a Objetos y las Bases de Datos.

La Programación Orientada a Objetos (OOP), permite introducir mayor significado en la información almacenada en una Base de Datos, ya que garantiza la representación y la manipulación de objetos complejos, tanto en su estructura como en su comportamiento, (Ref. 14).

En esta sección se describen las características de los modelos orientados a objetos. No hay un modelo común para usar como un punto de referencia, tampoco bases formales para los conceptos que se describirán, y por lo tanto, no hay un modelo estándar orientado a objetos, como fue en el caso de los modelos relacionales, (Ref. I ) .

Muchas de las ideas de programación orientada a objetos derivan del lenguaje Simula (Ref. 24), sin embargo el modelo empezó a usarse ampliamente como resultado de la introducción de Smalltalk (Ref. 25). Se desarrollaron otros lenguajes, incluyeildo C + t (Ref, 26), CLOS (Ref. 27) y Eiffel (Ref. 28). La clave para la programación orientada a objetos está en considerar que un programa está compuesto de ciijetos independientes, agrupados en clases, las cuales se comunican con otras por medio de mensajes. Estos conceptos también fueron desarrollados en otras áreas, por ejemplo en lenguajes basados en conocimiento (Ref. 29), y fueron adoptadas diferentes interpretaciones. Las bases de datos requieren un modelo propio y, en ausencia de un modelo estándar, ciertos conceptos generalmente aceptados concernientes con el modelo, pueden ser agrupados juntos hacia un modelo básico, proporcionando una solución suficientemente poderosa para satisfacer muchos de los requerimientos de aplicaciones avanzadas, e identifica las principales diferencias comparadas con los modelos convencionales.

3.2.4.1 Conceptos Bhieos del Modelo de' Datos Orientado a Objetos

AI tratar de caracterizar la orientación a objetos es imprescindible tener en cuenta, entre otros, seis aspectos fundamentales de este paradigma (Ref. 1):

I

!

I I

= Objetos e identidad. Cada entidad del mundo real se modela por medio de un objeto. Cada objeto se asocia con un identificador único.

Objetos complejos. Cada objeto tiene un conjunto único de atributos (variables de hstancia) y métodos; 'el valor de un aüibuto puede ser un objeto O un conjunto de objetos. Esta característica permite definir objetos complejos como una agregación de otros objetos. El conjunto de atributos de un objeto y el conjunto de métodos representan la estructura del objeto y su comportamiento respectivamente.

Encapsulación. Cada objeto contiene y define los procedimientos (métodos) y la interfaz con la cual puede ser accesado y manipulado por la aplicación o por otros objetos. La interfaz de un objeto consiste del conjunto de operaciones que pueden ser invocadas para un objeto. El estado de un objeto (atributos) se manipula por medio de los métodos invocados.

17


Clases. Los objetos que comparten la misma estructura y el mismo comportamiento se agrupan en clases. Una clase representa un formato o plantilla (template) para cada conjunto de objetos similares. Cada objeto pertenece a (es una insfancia de) alguna clase.

Herencia. Una clase puede definirse como una especialización de una o más clases. Una clase definida como una especialización es denominada una subclase y hereda atributos y métodos de su o sus superclases.

Sobrecarga, sobreescntura y ligado tardio. Con estas funciones, se pueden asociar métodos diferentes con el mismo nombre de una operación, dejando al sistema la tarea de determinar cuál método debería ser usado para ejecutar una operación dada.

3.2.4.2 Los marejadores de Bases de Daíos Orientados a Objetos.

Las bases de datos orientadas a objetos (OODBs ), vienen a llenar el hueco existente entre el dominio de la aplicación y su representación en almacenamiento persistente. Como el modelo resultante de una OODB es lo más cercano posible al mundo real, las ligas y las relaciones entre las entidades complejas se representan y se manipulan directamente (de una manera natural), (Ref. 2).

Un Manejador de Bases de Datos Orientado a Objetos (OODMS) puede definirse como un manejador de bases de datos (DBMS) que soporta un modelo basado en el paradigma orientado a objetos. AI igual que cualquier DBMS, debe proporcionar almacenamiento persistente para los objetos y sus descriptores (el esquema de la base de datos). El sistema también debe tener un lenguaje para la definición y la manipulación de los objetos y su esquema. Además de estas características básicas, un OODBMS incluye generalmente un lenguaje de consultas (query languaje) y los mecanismos necesarios para optimizar el acceso a la base de datos, tales como la indexación y el agrupamiento, control de concurrencia, mecanismos de autorización para múltiples usuarios y recuperación.

A continuación se describirán en forma breve las características básicas del modelo de bases de datos orientado a objetos, aunque algunos de estos conceptos se definieron en secciones anteriores, en esta parte se describirán con mayor nivel de detalle y sobre todo con un enfoque hacia sistemas de bases de datos orientadas a objetos.

3.2.4.3 Objetas y los identificadores de los objetos.

En sistemas orientados a objetos, cada entidad del mundo real es representada por un objeto al cual se asocia un estado y un comportamiento. El estado es representado por los valores de los atributos. El comportamiento está definido por los métodos que pueden actuar sobre

Cistems Administrador de Estwduras de Datos Complejas Persistentes

el estado de los objetos como resultado de la invocación de las operaciones correspondientes (Ref. 30).

Cada objeto tiene un identificador único. La identidad de un objeto es independiente de su valor. El uso de identificadores de objetos (OIDs), permite compartir subobjetos y hace posible construir redes de objetos.

3.2.4.4 Objetos y valores

Sin embargo, algunos modelos permiten la identificación en objetos y en valores, ya que no todas las entidades modeladas son objetos, las entidades primitivas como enteros o caracteres, son valores, mientras que otros son objetos.

Otros modelos permiten la definición de valores complejos. Los valores complejos no pueden compartirse entre objetos. Ya que se construyen con los constructores de los objetos que los contendrán.

En general los valores complejos son útiles en situaciones donde se deben usar agregados (o conjuntos) como componentes de otros objetos, pero nunca se utilizarán solos. Si los valores complejos no se permiten, los agregados deben definirse usando una clase y deben tener un OID asociado con ellos (Ref. 30).

3.2.4.5 Difíerencias con el concepto de llave del modelo relacional

El concepto de llave en el modelo relacional es muy importante, un atributo o conjunto de atributos cuyos valores identifican unívocamente cada tupla en el conjunto de todas aquellas tuplas pertenecientes a la misma relación. Por ejemplo, si se considera una relación que contiene información tal como Registro Federal de Causantes (WC), nombre y apellidos, dirección, fecha de cumpleaños, para un conjunto de personas la llave podría ser representada por el RFC.

Con frecuencia una llave puede tener varias llaves alternativas, llamadas llaves candidato, y la llave que realmente se selecciona como llave de la relación se conoce como llave primaria.

Para mantener las correlaciones entre las tuplas de diferentes relaciones se usan las llaves exfernas, enfoque que involucra la adición de los atributos que son llaves de una relación en otra relación. Por ejemplo, para mantener la relación entre las entidades empleado y departamento, se debe adicionar un atributo a la relación empleado que contenga el código del departamento para cada tupla de empleado, para representar el departamento para el cual trabaja cada empleado (Ref. 30).

El concepto de un identificador es diferente al concepto llave en un modelo de datos relacional. Una llave se define por medio del valor de uno o más de sus atributos y por lo

19

Sistema Administrador de EslNcluras de Dalos Complejas Persistentes

tanto pueden sufrir modificaciones. Pero, dos,objetos son diferentes si tienen diferente OID? a pesar de que todos sus atributos tengan el mismo valor. Algo más? la llave es única dentro de una relación, el OID es único dentro de toda la base dc datos. Usando OIDs se pueden definir colecciones’ heterogéneas de objetos pertenecientes a diferentes clases. Los OIDs son independientes de las clases a las cuales pertenecen (Ref. 30).

Hay ciertas ventajas de usar OIDs en lugar de llaves como mecanismo de identificación de los objetos.

Dado que los OIDs son implementados por el sistema, los programadores de aplicaciones no tienen que ver con la selección de la llave apropiada para las diferentes clases u ob,jetos.

Aunque las llaves son más significativas para el usuario, se presenta una , dificultad - las llaves cortas, que son más eficientes (entre otras, WC, número

de parte y número de cliente) tienen poco significado para el usuario, y por otro lado ias llaves largas (por ejemplo, nombre y apellidos y titulo de libro) resultan extremadamente ineficientes especialmente si se usan como llaves externas, en donde se requieren mecanismos para manipular las tuplas de una relación. Los OIDs podrán tener poco significado, pero no son ineficientes y tampoco se requiere un mecanismo para incluir o asociar un objeto con otro.

El modelo permite compartir objetos basando la identidad en los mismos objetos y no en los valores, evitando a la aplicación la tarea de manejar los valores de las llaves y el problema asociado de la normalización.

3.2.4.6 Objetos CompIejos.

Los valores de los atributos de un objeto pueden ser a su vez objetos, primitivos o no. Primitivos son aquellos tipos de datos que tiene el sistema por definición, tales como enteros, flotantes, tipo carácter, etc.. y no primitivos los tipos de datos que el usuario define en el sistema. Cuando el valor de un atributo de un objeto O es un objeto no primitivo O’, el sistema almacena el OID de O’ en O. Cuando el modelo soporta valores complejos, el sistema almacena en los atributos del objeto el valor complejo completo, como el caso de un objeto que tiene definidos dentro su estructura otros objetos, correspondiendo al caso de agregación (Ref. 30).

Usar valores complejos es más eficiente que usar objetos. En el primer caso, una vez que un objeto es buscado y recuperado. todos los componentes que son valores complejos son recuperados al mismo tiempo. Mientras que en el segundo caso, el objeto O contiene solamente los OIDs de sus componentes, lo que origina que se tenga que hacer más de una búsqueda para recuperar el objeto completo.

7.0

Sistema Adminislrador de Eslrucluras de Datos Cornplelas PerSlSlenleS

Para la definición de objetos complejos y valores coniplcjos. un modelo debería suministrar un conjunto de constructores como son: conjuntos. listas y tuplas. En particular, el constructor para conjuntos permite definir atributos multivaluados y conjuntos de objetos. La lista es similar al conjunto, pero impone un orden en sus elementos. Finalmente, el constructor de tupla es importante porque proporciona una manera natural para modelar las propiedades de un objeto.

En algunos modelos de datos se maneja el concepto de objeto compuesto. Es decir, un objeto puede referenciar recursivamente a cualquier número de otros objetos.

Una relación importante en los objetos complejos es la relación parte-&, que significa que un objeto es parte de otro objeto. Un conjunto de componentes formando una sola entidad es un objeto complejo.

3.2.4.7 Encapsulación.

Con frecuencia, los atributos de un objeto no pueden ser accesados directamente. La única manera para accesarlos es invocando los métodos utilizables en la interfaz del objeto. Esto es lo que se denomina encapsulación de datos (Ref. 30).

La encapsulación no nace con el modelo orientado a objetos. Es el resultado final de un proceso evolutivo que inició con los lenguajes imperativos. Las razones de ello fueron:

La necesidad de hacer una clara distinción entre la especificación y la implementación de una operación.

La necesidad de modularidad.

La encapsulación en los lenguajes de programación se deriva del concepto de tipos de datos abstractos. En este contexto un objeto consiste de una interfaz y una implementación. La interfaz es la especificación de un conjunto de operaciones de un objeto que pueden ser invocadas y son solamente su parte visible. La implementación contiene los datos, por ejemplo, la representación del estado del objeto y los métodos con que cuenta.

La representación de un conjunto de empleados es un buen ejemplo de encapsulación. En un sistema relacional, un conjunto de empleados está representado por una alguna relación en la cual cada tupia representa un empleado. La relación se puede consultar usando un lenguaje relacional y probablemente se desarrollen programas de aplicación, generalmente escritos en lenguajes imperativos, incorporando instrucciones de un Lenguaje de Manipulación de Datos (DML). Este enfoque proporciona una clara distinción entre programas y datos y entre lenguajes de consulta y lenguajes de programación. En un sistema orientado a objetos, sin embargo, la entidad empleado se define como un objeto que comprende un componente datos (probablemente muy similar a la tupla definida en el

21


sistema relacional), y un componente operacional. por ejemplo incrementa-salario, disminuye-salario. La información se almacena completamente en la base de datos. La encapsulación proporciona una forma de independencia lógica de datos y significa que la implementación de objetos puede ser modificada. mientras la aplicación permanece sin cambio.

El manifiesto de Atkinson (Ref. 15) establece que la encapsulación real se obtiene cuando las operaciones son visibles y el resto del objeto está oculto. Sin embargo, hay casos en los cuales la encapsulación no es necesaria. El manejo de consultas (querys) es un ejemplo donde la violación de encapsulación es casi obligatoria. Las consultas se expresan con frecuencia en términos de predicados sobre los valores de los atributos. Por lo tanto casi todos los OODBMS permiten acceso directo a los atributos, proporcionando operaciones definidas por el sistema (no definidas por el usuario). Evitando al usuario tener que implementar una gran cantidad de métodos cuyo propósito consiste en leer y escribir los atributos,de los objetos.

3.2.4.7.1 Métodos

Los objetos de un sistema orientado a objetos se manipulan usando métodos. En general, la definición de un método consiste de dos componentes. El primer componente es la declaración del método, especificando el nombre del método, el nombre y clases de sus argumentos y la clase o tipo del resultado, si hay alguno. El segundo componente es la implementación del método, llamado el cuerpo que consiste de código escrito en algún lenguaje de programación. Los diversos OODMS usan diferentes lenguajes: ORION usa LISP, Gemstone usa una extensión de Smalltak. O, usa C, Otros OODBMS como VbaselOntos y Objectstore utilizan C++.

3.2.4.7.2 Acceso y Manipulación de Atributos

Como se estableció en el apartado anterior, algunos OODBMS permiten que los valores de los atributos de los objetos sean escritos y leídos directamente, resultando en lo que se conoce como el principio de violación de encapsulación. Su propósito es hacer menos complejo el desarrollo de las aplicaciones que simplemente accesan o modifican los atributos de los objetos, aplicaciones que son muy comunes en manejo de datos. Son dos las ventajas de accesar directamente los atributos de un objeto:

Evita al programador tener que desarrollar un gran número de métodos que son generalmente convencionales.

Incrementa la eficiencia de las aplicaciones, ya que el acceso es por medio de operaciones proporcionadas por el sistema.

Obviamente la violación de la encapsulación de la aplicación puede causar problemas, ya que la definición de los atributos de un objeto podría ser modificada. Algunos sistemas

22

Sistema Administrador de Eslnicluras de Datos Complejas Persistentes

- como VbasdOntos, por ejemplo suministran métodos definidos por el sistema para leer y escribir los atributos de un objeto, permitiendo redefinir estos métodos por el usuario (overriding). Esto es muy útil en ciertas situaciones. por ejemplo cuando los datos se van a importar de una base de datos relaciona1 externa. Los métodos son implementados eficientemente y a bajo nivel por el sistema. Otros sistemas como O, permiten establecer al usuario cuales métodos y atributos son visibles en la interfaz del objeto y cuales pueden ser invocados desde fuera de la clase. Atributos conocidos como públicos. Los métodos y aíributos que no son visibles se dice que son privados. El enfoque es muy similar al usado por C+t. Finalmente, en otros sistemas como ORION, todos los atributos pueden ser accesados directamente, los métodos de lectura, escritura y todos los métodos pueden ser invocados. En ORION se pueden usar mecanismos de autorización para prevenir acceso a ciertos atributos y la ejecución de ciertos métodos.

3.2.4.8 Clases.

3.2.4.8.1 Clases y Tipos

Los sistemas orientados a objetos pueden clasificarse en dos categorías principales: los sistemas que soportan el concepto de clase y aquellos que soportan el concepto de tipos.

Con frecuencia los conceptos de tipos y. clases se usan indistintamente. Sin embargo, cuando los dos están presentes en el mismo lenguaje, el tipo se usa para indicar la especificación de la interfaz de un conjunto de objetos, mientras que la clase tiene que ver con la implementación. Un tipo es un conjunto de objetos que comparten el mismo comportamiento, que puede observarse desde afuera. Esto significa que el tipo al cual pertenece un objeto depende de las operaciones que se pueden invocar sobre el objeto. Por otro lado, una clase es un conjunto de objetos. que tienen exactamente la misma estructura interna y los mismos métodos. La clase define la implementación de un conjunto de objetos, mientras que un tipo define como un objeto puede ser usado. Un tipo puede ser implementado por muchas clases. Y por otra parte una clase puede implementar varios tipos; si una clase implementa un tipo, automáticamente implementa todos los supertipos de este tipo.

En ENCOkE (Ref. 32), un tip6 es conocido como la especificación de la interfaz y la implementación, mientras que una clase es conocida como la extensión de un tipo. Un tipo puede tener varias clases asociadas con él y las clases pueden ser definidas por medio de predicados. Por ejemplo, dado el tipo de dato ‘Auto’, la clase ‘AutoAml’ puede ser definida como el conjunto de instancias del tipo de dato ‘Auto’, que tienen el valor azul en el atributo ‘color’.

Teóricamente, podría ser correcto usar los tres conceptos siguientes de extensión de un tipo en un modelo de bases de datos orientados a objetos.

23

Sistema Administfado! de Estructuras de Datos Complejas Pefsis1enteS

tipo, para significar la especificación de un conjunto de objetos; clase, para significar la estructura e implementación de un conjunto de

colección de objetos, el soportar el concepto de extensión de un tipo; objetos;

Pero podrían generarse muchas implicaciones en otros aspectos del modelo y para la implementación. Por ejemplo, se requerirían tres mecanismos diferentes de jerarquización para herencia. Más aún, cada objeto podría necesitar su tipo y su clase asociados con él. Por lo mismo la mayoría de los diferentes OODBMS manejan el concepto de tipos y el concepto de clases sin precisar distinción, (Ref. 16).

3.2.4.8.2 Clases y Mecanismos de Instanciación.

Instanciación significa que la misma definición pueda ser usada para generar objetos con la misma estructura y comportamiento. En otras palabras, por medio del cual las definiciones pueden ser reutilizadas. Los modelos orientados a objetos usan el concepto de clase como base para la instanciación. En este sentido, una clase es un objeto que actúa como una plantilla. En particular, especifica:

un conjunto de operaciones;

un conjunto de métodos, que implementan las operaciones.

una estruchq que es, el conjunto de atributos de las instancias; . .

Con la operación new se pueden generar objetos que respondan a todas las operaciones definidas para una clase dada (Ref. 30). Los valores de los atributos de cada objeto deben almacenarse separadamente, pero la definición de las operaciones y los métodos no deben repetirse. De hecho, cada clase se asocia con un objeto llamado clase-objeto que contiene la información común a las instancias de la clase y, en particular, los métodos de la clase; el objeto clase-objeto se almacena, por lo tanto, separadamente de las instancias.

Un enfoque alternativo para generar objetos consiste en usar objetos prototipo, involucrando la generación de un nuevo objeto a partir de uno ya existente, modificando sus atributos y su comportamiento, resultando útil cuando los objetos cambian rápidamente y son más diferentes que similares.

En general, el enfoque de generar objetos por medio de la instanciación es más apropiado donde el ambiente de la aplicación es más estable, es decir, cuando no es común experimentar con estructuras diferentes para los objetos.

24

Sislema Administrador de Eslrucluras de Datos Complejas Persistentes

3.2.4.8.3 Jerarquías de Agregacióii

En casi todos los modelos orientados a objetos.. un atributo tiene asociado con él un dominio que especifica las clases de los posibles objetos que pueden ser asignados como valores a estos atributos, constituyendo una diferencia importante comparada con ciertos lenguajes de programación orientados a objetos, en los cuales las variables de instancia no tienen tipo. Para aplicaciones que requieren manejar eficientemente grandes cantidades de datos y por lo tanto necesitan localizar las estructuras auxiliares apropiadas, el sistema debe conocer el tipo de los valores posibles de un atributo. Por ejemplo, para localizar un índice debe especificarse el dominio de los atributos.

El hecho de que un atributo de una clase C tenga una clase C’como un dominio, implica que cada instancia de C asuma como el valor del atributo una instancia de C’, o de la subclase del atributo. Es decir entre las dos clases se establece una relación de agregación. Una relación de agregación de una clase C a otra clase C’ especifica que C está definida en términos de C‘. Dado que C’ puede estar definida en términos de otra u otras clases, el conjunto de clases en el esquema se dice, está organizado en una jerarquía de agregación. Sin embargo, esto no es una jeraquía en el sentido estricto de la palabra, dado que las clases pueden ser definidas recursivamente.

3.2.4.8.4 Migración de instancias entre clases

La migración de instancias entre clases es un concepto importante. El hecho de que un objeto pueda ser convertido a una instancia de una clase que es diferente de la clase de la cual fue generado, es muy importante para la evolución de los objetos. Más específicamente, significa que un objeto puede modificar sus propias características, atributos y operaciones, mientras mantiene la misma identidad. Algunos sistemas, como Iris y Encore pueden hacer esto, mientras la mayoría de los otros no (Ref. 30). Si los objetos pueden migrar entre clases, se incrementan los problemas de integridad semántica.

3.2.4.8.5 Persistencia de las instancias de las clases

Otra importante característica es la persistencia de las instancias de una clase, por ejemplo, las modalidades bajo las cuales los objetos se hacen persistentes (insertados en la base de datos) y son eventualemente borrados (eliminados de la base de datos). Hay dos enfoques básicos:

Persistencia es una característica implícita de todas las instancias de clases. La creación de una instancia (típicamente, por medio de la operación new) tiene el efecto de insertar la instancia en la b&e de datos. Por lo tanto la creación de una instancia autbmáticamente implica su persistencia. Este enfoque, usado por

25

I I I I

II

Sistema Administrador de Eslructuras de Datas Complejas Persistentes

ejemplo, en ORION, es el más simple. ya’que para hacer persistente un objeto no se requieren operaciones adicionales aparic de crcar el objeto.

Persistencia es una caractenstica ortogonal. La creación de una instancia no tiene el efecto de insertar la instanci.a en la base de datos. Una instancia creada durante la ejecución de un programa es borrada al final del programa, a menos que se haga persistente. Se asocia un mecanismo para hacer persistente a una instancia, o para insertar la instancia en una colección de objetos persistentes. O, es un sistema que usa este tipo de enfoque, con la ventaja de ser más flexible que el primer enfoque, pero más complejo. Una posibilidad adicional, consiste en suministrar una operación que, si es invocada sobre el objeto, lo hará persistente.

Puede existir un enfoque intermedio entre estos dos extremos. Las clases se clasifican en clases persistentes y clases temporales. Todas las instancias de clases persistentes se guardaríautomáticamente, cosa que no sucede con.las temporales. Este enfoque se usa en el I enguaje E (Ref. 31).

Hay dos formas de borrar objetos. La primera implica suministrar una operación borrar explícita. Obviamente borrar, trae consigo el problema de la integridad de referencias. De hecho si un objeto es borrado y hay objetos que apuntan a este objeto, sus referencias pierden validez. Una solución, aunque costosa. consiste en mantener información, por ejemplo un contador de referencias, que se usa para determinar si un objeto es referenciado por otros objetos. Típicamente un objeto se puede borrar solamente si su contador de referencia tiene un valor de cero.

Otra solución, usada en ORION, consiste en no mantener información adicional y permitir operaciones de borrado libremente. Las referencias a objetos borrados se manejan como excepciones, haciendo las operaciones de borrado más eficientes. Sin embargo, se requiere código adicional en las aplicaciones para manejar estas excepciones originadas por los objetos borrados. También los OIDs de los objetos borrados no pueden ser reutilizados. El segundo enfoque está basado en no suministrar una función explícita de borrado, un objeto persistente es cancelado solamente si todos los nombres externos y referencias asociadas con él han sido removidas. Esto asegura integridad de referencias.

3.2.4.8.6 Meiaclase

Como se mencionó anteriormente. una clase se puede considerar como un objeto, es decir, una clase-objeto, en la cual los atributos y métodos comunes a las instancias de la clase se agrupan en forma conjunia, y en la cual se almacenan las Características que no pueden ser consideradas como características de una instancia de una clase, por ejemplo el número de instancias de la clase presentes en un determinado tiempo en la base de datos. Si se desea mantener el principio de que cada objeto es una instancia de una clase, y las clases son objetos, entonces, por cuestiones de uniformidad, el sistema debe soportar el concepto de

26

Scslema Administrador de Eslrunuras de Dalos Complejas Persistenles

metaclase en el sentido de la clase de una clase. A su \'ez la metaclase es un objeto y debe por lo tanto ser una instancia de una metaclase de un nivel más alto. La mayoría de los sistemas orientados a objetos no soportan el concepto de metaclase y solamente algunos tienen funcionalidades de metaclase. En ORION por ejemplo, una clase del sistema, CLASS, representa la clase de todas las clases y la raíz de la jerarquia de clases. es decir, la superclase de todas las clases presentes en el sistema. Generalmente la metaclase, si está presente, no puede ser accesada y manipulada por el usuario. En la figura 3.2.4.8-1 se muestra el ejemplo descrito anteriormente para la relación que se establece entre la metaclase de A y la clase A. Como se puede apreciar para poder el mantener la cuenta del número de objetos que se han creado de la clase A durante la aplicación se define la clase Meta-A, con un atributo que puede ser accesado por los métodos de la clase A para poder ser actualizado.

M e I a A

A A

+)nombre string @descripción string

*incrementa_Num_instancias( ) *Decrementa_Num_lnstancias()

Figura 3.2.4.8-1 Ejemplo de una relacibn enlre una Metaclase y su clase

3.2.4.9 Herencia.

El concepto de herencia es el segundo mecanismo de reusabilidad y muchos opinan que es el concepto más poderoso de la programación orientada a objetos. Con la herencia, una clase llamada subclase puede ser definida partiendo de la definición de otra clase llamada superclase. La subclase hereda los atributos. métodos y mensajes de su superclase. Además, una clase puede tener sus propios atributos, métodos y mensajes.

Como un ejemplo de reusabilidad, se puede usar el ejemplo.concerniente con las clases autobús y camioneta. Las características de estas dos clases se muestran en la figura 3.2.4.9-1 con una representación gráfica. En ella cada clase se representa por un rectángulo dividido en tres niveles. El prinier nivel contiene el nombre de la clase, el segundo, los

27

Sistema Administrador de EslNcluras de Dalos Complejas Penlslentes

atributos y el tercero los métodos. El tercer nivel puede estar vacío si la clase no tiene métodos definidos por el usuario.

En el modelo relacionai, se tendrían que definir dos relaciones, una para autobús y otra para camioneta, y los procedimientos para implementar las diversas operaciones deberían ser codificados.

Usando el enfoque orientado a objetos, se reconoce que los autobuses y camionetas son vehículos y que por lo tanto tienen características comunes y otras que los diferencian. Se introduce el tipo vehículo, con los atributos placa, modelo, fecha-última-Mtto y el método para implementar la operación próximo-Mtto. Luego se establece que autobús y camioneta son vehículos específicos y por lo tanto solamente las características que los hacen diferentes tendrán que ser definidas. Por lo tanto se obtiene la jerarquía de herencia mostrada en la Fig. 3.2.4.9-2. La figura muestra un arco dirigido de la clase C a la clase C' para mostrar que C es una subclase de la clase C'.

Camioneta '

PlacaNumero : STRING

Licencia: NUMERO

Fecha-Ultimo-Mtto : FECHA

Valor-Estimado() : NUMERO

Siguiente-MnoO : FECHA

Modelo : STRING

Autobus

Placa-Numero : STRING Modelo : STRING Asientos '. NUMERO Fecha-Ultimo-Mtto: FECHA I Siguiente-Mtto : FECHA

Figura 3.2.4.9-1 Un extracto de una base de dalos.

De esta manera, se requiere escribir menos c6digo. También existe la ventaja de que la herencia soporta una descripción más concisa y más precisa del modelo que se desea hacer de la realidad.

28

Srstema Administrador de Estructuras de Datos Complejas Persistentes

. . En algunos sistemas, una clase puede tener varias superclases. lo que define la herencia múltiple. Otros sistemas imponen la restricción de que una clase sólo puede tener una superclase, lo que se conoce como herencia simple. La posibilidad de definir una clase partiendo de otra simplifica la tarea de la definición de clases. Sin embargo pueden surgir algunos conflictos, especialmente en herencia múltiple. Generalmente si el nombre de un atributo o método definido explícitamente en una clase es el mismo para su superclase, los atributos de la superclase no se heredan, sino que se adecúan a la nueva definición. En este caso, se habla de redefinición o sobreescritura (overriding).

Figura 3 2 4 9-2 Un ejemplo de Herencia

29


Si el modelo soporta herencia múltiple. surgen otro tipo dc problemas, por ejemplo, dos o más superclases pueden tener un atributo con el misnio nombre, pero con diferentes dominios, cuyo efecto se veria refle,jado en la maiiipulacinn de este atributo por parte de los objetos de clase que hereda. ya que en un momento dado no se podria establecer a que clase heredada pertenece el valor del atributo. Generalmente, sc pueden implementar reglas para resolver estos conflictos, si los dominios son ligados por una relación de inclusión entonces el dominio más específico será seleccionado como el dominio de la subclase. Si, la relación no existe, la solución comúnmente adoptada es seleccionar el dominio basándose en la precedencia entre las superclases.

Sin embargo, el aspecto esencial de la herencia es la relación que se establece entre las clases: una subclase con su superclase y a su vez la superclase puede ser una subclase de otras clases.

Las clases en un esquema de base de datos pueden organizarse, en la misma forma que en la jerarquía de agregación.

Otra característica importante en el contexto de una base de datos son las consultas (queries) ya que son una herramienta para extraer información de la base de datos. Una consulta es formulada generalmente sobre un conjunto de instancias ylo miembros de una clase y consiste de una combinación booleana de predicados que expresan condiciones sobre los atributos de los objetos. Las consultas representan una violación al principio de encapsulación. También las consultas pueden invocar métodos. Cuando una consulta es aplicada a un conjunto de clases miembro (y por lo tanto, a instancias de sus subclases) que tienen una estructura diferente se pueden crear ciertos problemas. El hecho de que la estructura y sus atributos puedan ser modificados con respecto a la estructura heredada puede originar que sean modificados los atributos de la subclase cuyas instancias tienen estructuras radicalmente diferentes. El resultado puede ser que algunas consultas sean definidas muy pobremente.

3.2.4.10 Sobrecarga, sobreescritura y ligado iardío.

El concepto de polimorfismo es ortogonal con respecto al concepto de clase. Hay muchos casos en los cuales es útil usar el mismo nombre para diferentes operaciones. Si se considera por ejemplo la operación desplegar que recibe un objeto como entrada y desarrolla la tarea de desplegar un objeto en la pantalla. Dependiendo del tipo de objeto, se puede desear desplegar diferentes tipos de despliegue. Si es una imagen, deberá aparecer en la pantalla. Si el objeto es una persona. es probable que la función esté relacionada con el despliegue de datos como nombre, salario, etc. Y por otra parte, si es una gráfica, la operación deberá realizar y presentar un gráfico de c.iertos datos. Un problema más surge si el despliegue está relacionado con un conjunto, donde el tipo de los miembros no se conoce en tiempo de compilar el programa. En aplicaciones que usan un sistema convencional. debería haber tres operaciones:

30

Sistema Administiador de Estructuras de Datos Complejas Persistentes

despliega-gráfica: despliegagersona y despliega-figura.

Esto origina que el programador tenga la responsabilidad dc considerar estáticamente todos

for x in X do begin

case of type(x) persona: despliegagersona(x); figura : despliega-figura(x); grafica : despliega-grapli(x);

end; end;

los posibles casos de tipos de objetos. de todas las operaciones de despliegue asociadas, 1 consecuentemente, de usarlas adecuadamente. Por ejemplo:

En un sistema orientado a objetos; la operación de despliegue puede ser definida en una clase más general. La operación tiene un nombre único y puede ser invocado indistintamente para los diversos tipos de objetos. Sin embargo la implementación de la operación es redefinida para cada una de las subclases, denominándola sobreescritura. El resultado es un sólo nombre para una operación que denota diferentes métodos. El sistema decide cuál de ellos usar durante la ejecución dinámicamente. Por lo tanto, el código anterior se puede compactar a:

for x in X do desplegar(x)

Son muchas las ventajas que se obtienen por el uso del polimorfismo. Los programadores que implementan clases deben escribir los mismos números de métodos, pero el diseñador de las aplicaciones no tendrá contacto con ellos. El código es más simple y dar mantenimiento a las aplicaciones es más fácil, cuando se introducen nuevos tipos no es necesario hacerles modificaciones.

Sin embargo, para poder suministrar esta nueva funcionalidad, el sistema no puede decidir los nombres de las operaciones a los correspondientes métodos durante la compilación, sino que debe ser en tiempo de ejecución, propiedad que se conoce como ligado tardío (late binding).

31


3.2.4.11 Un ejemplo.

Esta sección se utilizará para mostrar un ejemplo del esquema de una base de datos orientada a objetos, la cual es representada graficamente en la Fig. 3.2.4.1 1-1. El ejemplo describe una pequeña base de datos para el manejo de un número de proyectos. Un proyecto puede ser organizado en la forma de varios sub-proyectos y la clase Proyecto es definida recursivamente apuntando a si misma. Un pian de trabajo que consiste de varias tareas, es asociado a cada proyecto. Cada tarea es asignada a un grupo de investigadores el cual consiste de varios investigadores y un jefe de proyecto. También debe especificarse un jefe de grupo para una tarea. Debe notarse que el jefe del proyecto de la tarea no es necesariamente el jefe de grupo asignado a la tarea, el grupo de investigación puede tener asignadas varias tareas. Para cada proyecto, los diversos documentos que se van generando durante el proyecto se van listando. Los documentos pueden ser artículos publicados en revistas o conferencias, o reportes técnicos del proyecto.

32

Sistema Administrador de ESlNcIuraS de Datos Complejas Persistentes

I

ReQOne-Tecnm

l&a.iniuo FECHA Fecha-Fin FECHA MMt1imimes.A

Artwlo

Tipo-Pihliceum STRING Lug-PuQlicasim STRING Fecha FECHA

Investigador

N m b m STRING E I w d 4 d a d STRING Selano NUMERO Bmo.PrcduCOm NUMERO Salano-Prmsdio NUMERO

Figura 3.2 4.1 1-1 Ejemplo de un esquema de base de datos

33

Sistema Adminislrador de Estructuras de Dalos Complejas Persistentes i ( 1

I I

'I En la Fig. 3.2.4.11-1 cada nodo representa unaclase. Un nodo está subdividido en tres niveles, el primero contiene el nombre de la clase. el segundo los atributos y el tercero los métodos. Los atributos con ' * ' son atributos multi-valuados (o sea que tiene una relación 1:muchos). Los métodos especificados y los atributos de la clase pueden distinguirse de los atributos y métodos de las instancias ya que están subrayados. Por ejemplo, en la Fig. 3.2.4.1 1-1, la clase investigador tiene un atributo llamado salariogromedio que está subrayado, este atributo tiene el valor del promedio de los salarios de todos las instancias en la clase investigador. La conexión entre nodos puede hacerse por dos tipo de arcos. El nodo que representa la clase C puede conectarse al nodo que representa la clase C' por medio de:

arco normal (delgado) indicando que C' es el dominio de un atributo A de C, o que C' es la clase del resultado de un método M de C;

un arco más grueso. indicando que la clase C es la superclge de C'.

Por ejemplo, la clase Proyecto, en la misma figura, tiene asociado el método participante() que determina todos los grupos de investigadores que están participando en el proyecto. Este método tiene asociado el caracter '* ' y está conectado por medio de un arco a la clase Grupo para indicar que este método regresa un conjunto de instancias de esta clase.

Por razones de simplicidad, si el dominio de un atributo es una clase base (por ejemplo cadena o Número), el nombre de la clase sigue al nombre del atributo después del símbolo de ':', por ejemplo nombre - grupo: String. Las clases base no se muestran explícitamente como nodos en el esquema.

~

' I/

!,

!I /j i i

34

Sistema Administrador de EstNctUraS de Dalos Complejas Persistentes

En este capítulo se describen los componentes del Sistema Administrador de Estructuras de Datos Complejas Persistentes, su arquitectura y se establecen los requerimientos del mismo.

4.1 CompOnentesdelSAEDCP

Un sistema de manejo de datos (en inglés, DBMS, database management system), consiste en un conjunto de datos relacionados entre sí y un grupo de programas para tener acceso a esos datos y un conjunto de usuarios de diferentes niveles haciendo uso de los datos. Los componentes de un DBMS se muestran la Fig. 4.1 -1

El SAEDCP tendrá las siguientes Características básicas, que constituyen lo que propiamente se conoce como "kernel" del sistema.

Soportar un modelo basado en el paradigma orientado a objetos. Debe proporcionar almacenamiento persistente para los objetos y sus descnptores (el esquema de la base de datos). El sistema también debe tener un lenguaje para la definición y la manipulación de los objetos y su esquema.

A continuación se enuncian las características adicionales que como manejador de base de datos orientado a objetos deben cubrirse, aunque no son parte del desarrollo de esta tesis:

inclusión generalmente de un lenguaje de consultas (query languaje) mecanismos necesarios para optimizar el acceso a la base de datos métodos de indexación y el agrupamiento control de concurrencia mecanismos de autorización para múltiples usuarios y recuperación.

El conjunto de datos se conoce comúnmente como la base de datos. El objetivo primordial de todo DBMS es crear un ambiente en que sea posible guardar y recuperar información de la base de datos en forma conveniente y eficiente. El SAEDCP, tendrá estas dos características como funciones primordiales. Es necesario que el sistema cuente con un lenguaje para la definición del esquema de los datos almacenados (El DDL).

35

Sistema Administrador de EsiNcturas de Datos Complejas Persistentes

El Lenguaje de Definición de los Datos (siglas en inglés, DDL). La mayoría de los sistemas de bases de datos orientados a objetos (OODBMS) introducen un lenguaje para la definición de los datos, Por ejemplo, en el caso del Modelo de Datos de Gemstone, usan el lenguaje OPAL para definición y manipulación de datos. En el caso del SAEDCP y con el fin de mantener todo el potencial que permite el lenguaje C++, el DDL será parte del mismo lenguaje. Es decir la definición de clases se podrá hacer usando las mismas reglas de sintaxis de C++, y cuando se desee hacer persistente una clase se agregarán a la definición de la clase, algunas características necesarias para comunicarla con el "kernel" del SAEDCP, que agregará todas las funciones de persistencia. La definición de clases persistentes soportará los conceptos de herencia, agregación y además se permitirá la asociación entre objetos.

El Lenguaje de Manipulación de Datos (siglas en inglés DML). Una vez creada una clase persistente, el usuario de esta clase podrá crear instancias de ella, es decir objetos. El lenguaje de Manipulación de Datos (DML), permitirá algunas funciones primitivas como:

Almacenar un objeto, Borrar un objeto, Listar o Visualizar todos los objetos dentro de la base de datos.

36

!I I /I I

I'

!'

I I¡

I !I

! /I

/I I

Sislema Adminisbador de Estructuras d e Dalos Compiejas'Persistenles ,., .

USIIARIOS

v COMANDOS DEL

DDL

I

, .

PRECOMP~LADOR

I I

COMPILADOR

ALMACENAMIENTO RECUPERACI~N DE

Figura 4.1-1 Componentes de un Sistema de Base de Datos

I!

37

Sistema Adminisirador de Esjructuras de Dalos Complejas Persislenles

La interfaz con el usuario. La interfaz con el usuario la generará el desarrollador de s o h a r e que use las librerías del SAEDCP. El sistema está enfocado a personas que desarrollan aplicaciones para bases de datos que usen tipos de datos complejos, y la interfaz puede variar entre aplicaciones, por lo que no hay funciones estándar para el despliegue visual de objetos en la base de datos, sin embargo, para la aplicación de prueba y validación del "kernel" del SAEDCP se usa una interfaz como prototipo que puede ser usada en más de una aplicación.

4.2 ArqurtecturadelsAEDcP.

4.2.1 El Sistema Administrador de Estnichiras de Datos Complejas.

En la Fig. 4.2.1 se muestra gráficamente el diseño de la arquitectura del SAEDCP. Se puede apreciar que en el nivel físico, (el nivel más bajo de abstracción en el que se describe cómo se almacenan realmente los datos), se mantienen tres archivos :

El archivo de índices. Este es un archivo que contiene los objetos ordenados de acuerdo a su OlD, usando para ello un árbol binario, de dónde se obtiene también la referencia a disco, es decir la posición física dónde a partir de la cual inician los datos del objeto en el archivo referenciado como archivo de clases.

El archivo de clases. Contiene información para la recuperación recursiva de la información de los objetos agregados o heredados de un objeto. Primeramente se guarda el nombre del objeto, la clase a la que pertenece y la referencia en disco correspondiente ai archivo de objetos, en dónde se localizan los datos del objeto, para así recuperar todos los valores de los atributos correspondientes a su clase. Luego se almacenan el número de referencias y los nombres de las mismas, con el fin de recuperar la información correspondiente a sus objetos agregados o heredados.

El archivo de objetos. Contiene los datos o valores primitivos de un objeto.

En la Fig. 4.2.2 se muestra gráficamente la relación entre los archivos descritos.

38

Sistema Administrador de Estructuras de Dalos Comple]as Persistentes

USIJAKIO FINAL

APLICACIONES ORIENTADAS A OBJETOS (OBJETOS COMPLEJOS)

'ABR1RlCERRARB.D. * CREAR OBJETOS 4 ' SALVAR OBIETOS I ' I:I.IMINAROBJETOS I ' CONSULTAOBJETOS I ' USO DE CONJUNTOS I

I'AKA OBJETOS I COMPLUOS I

.LISTAS FORMATODE I CLASES PERSISTENTES i ,

MAPEO-CONCEPTUAI.

I I -- SAEDCP

INSTANCIAS DE ESTRUIXURAS

COMPLEJAS.

-r7 MAPEO CONCEPTUAL-INTERNO

MODELO DE DATOS

O R l M T A D O A OBJETOS 0

AGREGACION ASCClAClON

DBA

I I

CLASES. OBJETOS Y SUS RELACIONES ALMACENADOS (VISTA INTERNA) EL ARCHIVO DE INDICES SE IMPLEMENTA USANDO OID'S.

Figura 4.2-1 Arquitectura del SAEDCP.

39

Sistema Administrador de Eslrucluras de Datos Complejas Persistentes

Num-. Objetos

inicio de bloque Bloque de continuación

Estado de bloque L / o wp objeto I

Num-Bloques Root ler Bloque Libre ARCHIVO DE INDICES

Fin Bloque

izq der OID ReiDisco

ESTRUCTURA DE LOS ARCHIVOS

bal

I I I I

Num-Objetos NBloques ler Bloque Libre ARCHIVO DE CLASES

Num-Objetor N-Bloques I er Bloque Libre ARCHIVO DE OBJETOS

NombreObjetd Nombreclase IRefDiscd NumRefs INombreRefs

Nombreclase _-_--- Datos del objeto -_-----

....

Figura 4.2-2 Sistema de Archivos del SAEDCP para lograr la persistencia

utilizar el lenguaje Host, que en este caso es el lenguaje C++, más las funciones correspondientes que se agregan al crear clases persistentes, para crear aplicaciones.

Estas funciones son las que se listan a continuación.

' I

I

Crear una base de datos. Abrir una bases de datos existente y recuperar todos los objetos ahí guardados. Crear objetos, simples o complejos. Guardar objetos previamente creados. Visualizar todos los objetos en una base de datos y las clases a las que pertenecen. Borrar objetos.

En la figura 4.2-3 se muestra gráficamente como los diversos usuarios A l , A2, B1, B2, B3 hacen uso del lenguaje host más el conjunto de librerías que establecen el DML. El uso de las vistas externas dependerá de los requerimientos de cada usuario. En el caso de las bases de datos orientadas a objetos cuando se efectúa la recuperación de un objeto se obtiene toda la información del mismo, por lo que el usuario definirá en una vista externa las características que desea ver del objeto. La definición del esquema de la base de datos, es decir la definición de clases y sus relaciones quedará establecida en el modelo conceptual y finalmente en el nivel interno se encontrará los mecanismos para el manejo de los datos en disco. El SAEDCP interactúa con cada una de las vistas, en el despliegue de los datos de un objeto, en la definición del esquema y en el guardado fisico de los datos.

En el caso del SAEDCP, cabe hacer la aclaración que el alcance de esta tesis no contempla que el sistema mismo brinde la posibilidad de la creación de diferentes vistas, pero dado el potencial del lenguaje Host, no se considera como una fuerte limitante.

1

I

I I I

I

I

I I

\

USUARIOS

NIVEL EXTIRNA EXTERNO

, MAPEO A

NIVEL CONCEF’IUAL

N N E L INTERNO

\

AI A2 p< 71 LENGUAJE

EXTERNO-CONCEPTUAL EXTERNO-CONCEPTUAL

VISTA CONCEPTUAL

J MAPEO z CONCEPTUAL-INTERNO \

t

BASE DE DATOS ALMACENADA (VISTA INTERNA)

Figura 4 2-3 Comunicación del DBA con el SAEDCP

42

I

En este capítulo se presentan el análisis y el diseño detallado del SAEDCP, usando la notación del Lenguaje Unificado de Modelado (siglas en inglés UML). (Ref. 19). Para la fase de análisis, es necesario la creación de un modelo orientado a objetos del dominio del problema.

Este proceso consiste de las siguientes fases:

Identificación de las clases principales. Definición de las relaciones entre clases. Definición de las operaciones de las clases. Definición de los atributos de las clases. Definición de las relaciones de herencia. Diagramas de interacción entre objetos.

5.1 Identsñcación de las dases pthdpaies.

Las clases que se consideran necesarias para la construcción del SAEDCP son las que se describen a continuación:

IOBASE.

Btree.

string.

Clase que contendrri todas las operaciones para manejo de la información Persistente, que debe ser almacenada en la Base de Datos. Esta clase manejará tres archivos: el archivo de objetos, el de clases y uno que será el archivo que contenga los Indices a los objetos, para y a localización rápida. Esta clase permitirá almacenar los diversos atnbutos de un objeto, as1 como los de sus clases asociadas o heredadas. Esta clase se define abstracta porque no se necesitará crear objetos o instancias de ella, ya que será a través de la clase IOout. que heredarA todas las propiedades de IOBASE, que se hae la comunicación con el SAEDCP.

Clase que permitirá almacenar las referencias a objetos en forma ordenada, de tal manera que se puedan localizar y recuperar rápidamente. Una clase Btree contendG Jn árbol Btree almacenado en disco usando los OID's de los objetos y sus referencias a la posición en el archivo donde se guardan los objetos.

:lase que permite el manejo persistente de cadenas de caracteres de cualqiiier ongitud. La clase mantiene el arreglo de caracteres y el tamario del arreglo. También

43 .

sistema Administrador de Estructuras de Datos Complejas Persistentes

InfoArbol. Clase que agrupa información para manipular la información en disco de un objeto referenciado en el archivo Btree. Esta clase contiene la referencia flsica en el archivo

I I cuenta con métodos para reemplazar el contenido de una cadena existente

I , de clases donde se encuentra informacibn de la clase y referencias de un objeto y de ! I

I SU referencia en el archivo Btree.

Estructura que mantiene información sobre un archivo fisico, como nombre, tiPo de archivo, etc.

Clase que permite la manipulación de arreglos que pueden contener información genérica y que son dinámicos, es decir, en tiempo de ejecución se puede cambiar el tamario del arreglo. Es útil para almacenar información que usa polimorfismo.

Estructura que permite leer o guardar el encabezado de un archivo tipo Btree. Esta estructura agrupa el numero de objetos. la referencia al objeto que es la entrada al

Archivo.

i ( - D ~ f i n ~ y .

I Header-Arbol.

tree-Disco

árbol Btree y el inicio donde se~encuentra el primer bloque libre.

Estructura que permite guardar la información requerida para la manipulación en disco del árbol Btree de OID's p.ira acceso rápido. Esta información corresponde

44

loout. Una clase que heredará de IOBASE todos los atributos y métodos y que será la clase que el usuario utilizará para definir sus clases persistentes; Un objeto del tipo de esta clase permitirá manipular la base de datos que el usuario usa^ en sus aplicaciones. Los m&odos de esta clase permiten almacenar las referencias a otras clases de un objeto que se definen mediante la herencia, la agregación o la asociación, también permite la recuperación de datos de un objeto que se encuentre en la base de datos y por ultimo permite listar todas las referencias a objetos heredados, agregados o asociados.

!

Sirlema Administrador de Estructuras de Datos C0mple)as Persistentes

loout IOBASE Btree InfoArbol I

~

. .

Figura 5 1-1 Conjunto de Clases del SAEDCP

5.2 Identificación de las Rdacionec entre clases.

En esta parte se adicionarán las relaciones entre las clases del modelo.

Una primera relación es la que se establece entre la clase ARCHIVO y la clase string. ARCHIVO tiene una instancia de string (filename) que define el nombre de una instancia de la clase ARCHIVO y que servirá para ponerle un nombre al archivo manipulado por esta clase.

Otra relación se establece entre treeDisco y string. La clase treeDisco tiene una instancia de la clase string (info), para guardar el OID Qe un objeto en el Btree.

La clase Btree usa una instancia de clase treeDisco en el método LeeRecord, que permite leer la información del Btree y pasar esta información a diferentes métodos de ordenamiento y búsqueda de la clase.

La clase Btree usa una instancia de la clase Header-Arbol para leer la información que se encuentra en el encabezado del archivo del árbol Btree.

Otra relación se establece entre la clase Btree y la clase Info-Arbol. La clase Btree usa en su interfaz a través del método BuscaEnArbol una instancia de la clase InfoArbol, donde se guarda información de la ubicación de un objeto almacenado en la base de datos.

La clase IOBASE tiene en su definición un objeto de la clase ARCHIVO (Arch), para manejo de la información del archivo que servirá para el almacenamiento de la información de los objetos que se creen durante una aplicación.

45

Sistema Administrador de Estructuras de Dalos Complejas Persistentes

La clase IOBASE tiene también en su definición un objeto de la clase Btree, que corresponde a la clase para manipular los objetos de una base de datos en forma ordenada.

La clase IOBÁSE usa en el método que guarda todas las referencias a otras clases para su posterior recuperación, un objeto de la clase DynArray. En este caso se recurre a un arreglo dinámico para permitir un número ilimitado de clases referenciadas.

IOBASE tiene en su definición un apuntador a una clase del mismo tipo para manejar la información que se guardará en el archivo de clases. Esta información corresponde a la identificación del objeto (el OID), el número de referencias a otras clases y el nombre de todas las referencias que deben ser almacenadas para su recuperación posterior.

Finalmente, se deriva de la clase IOBASE la clase IOout para generar una relación de herencia. La clase IOout permitirá la creación de bases de datos de objetos persistentes.

La clase ÍOout, usa en su constructor un objeto de la clase string para definir el archivo de la base de datos.

En la figura 5.2-1 se presenta el diagrama de Relaciones entre clases de acuerdo a la nomenclatura del UML. En el anexo C se describe esta nomenclatura.

Bt

Btreefile

1 1 1

filename 0 lA classRef

1

H e a d e r- M o l

r- - , Dynkray ~

I I C l a s e adicionada a una clase lpersistente definida pore1 usuario ~ 1 usuario para manejo d e I referencias a otras clases.

..

Figura 5.2-1 Diagrama de Relaciones entre clases del CAEDCP

46

Sistema Adminislrador de Esrrucluras de Datos Complejas PerSistenleS

53 Identificación de Attibutos y Operaciones de las Clases del SAEDCP.

Con la definición de clases, el establecimiento de responsabilidades de cada clase y la relación entre clases ya definidas. se pueden establecer las operaciones de cada una de las clases.

La clase string tendrá el conjunto de atributos y operaciones que se muestra en la Figura 5.3-1. La clase tiene un apuntador a la cadena (s), y un entero para almacenar el tamaño de la cadena ([en). Tendrá operaciones para imprimir la cadena (print), para modificar el contenido de la cadena apuntada (operuror = ), para regresar el tamaño de la cadena (length), y para convertir el tipo cadena a un tipo void, que podrá ser insertado en el arreglo de tipo @nArruy (operaior void *), que acepta apuntadores a void que después pueden ser recuperados mediante el tipo adecuado.

string : char' : unsigned in1

, *string( ) ., *string( ) , *string( ) , *string( ) . +string( ) , *print( ) , *operator =( ) , *operator =( ) , *length( ) , *operator void'()

Figura 5.3-1 Atributos y Operaciones de la

c

je string

La clase ARCHIVO contará con el conjunto de atributos mostrado en la figura 5.3-2. Esta clase contiene un apuntador a un archivo fisico @), y un buffer (bufer) que mantendrá la información en memoria antes de enviarla al disco, el tamaño de este buffer es de un bloque del sistema de archivos, una vez que se ocupe todo el bloque O que la operación de escritura o lectura haya concluido el contenido del buffer se vacía hacia un bloque físico del archivo. Mantiene también información del número de objetos n objeros), existentes en este archivo y una instancia de la clase string, para referencia elnombre del archivo (filename).

47

..

Sistema Administrador de Estnicturas de Dalos Complejas Persistentes

#buffer : char'

&nobjelos : long : FILE

d Figura 5.3-2 Alribulos de la clase ARCHIVO

La clase Header-Arbol, solamente contendrá tres atributos: el número de objetos en un archivo tipo Brree (nobjefos), el número de bloques fisicos que en un momento dado mantiene un archivo de esta clase (nbioques) y la entrada al primer objeto del archivo Btree (Root). Estos atributos se muestran en la figura 5.3-3.

La clase InfoArbol, contiene solamente dos atributos: la Referencia ai Archivo de clases donde se encuentra información de 1-n objeto determinado (RefArchCiuss) y su posición en el archivo de objetos (Record), la figura 5.3-4 muestra la información de la clase.

La clase treeDisco, agrupa atributos para almacenar en un archivo en disco la

Izq, referencia al objeto que se encuentra a la izquierda de este nodo en el recomdo del árbol Brree. Ref, la referencia en disco del archivo de clases donde se localiza la información acerca del objeto al que se corresponde este nodo. Der, referencia al objeto que se encuentra a la derecha de este nodo. bal, es una bandera auxiliar para el identificar la forma de balancear un subárbol dentro del Btree, en operaciones de insertar o eliminar nodos. Status, es una bandera que indica si el bloque está borrado. Si es así puede ser reutilizado. N-Refs, es un entero que indica el numero de objetos que hacen referencia a este objeto. Mientras el valor de esta variable sea mayor que cero no podrá ser eliminado de la base de datos. En la figura 5.3-5 se muestra grhficamente la

información correspondiente a un Btree. Entre sus atributos están:

. información de esta clase. Fi #"objetos :long ~

1

. ~~ ~ .~

Figura 5,3-3 Atributos de la clase Header-Arbol

I.

48

. Figura 5.34 Atributos de la clase InfoArbol

treeDisco &q : long ORef; long ODer : long Obal : int Oslatus ; char 0 - I

+beeDisco () : beeDiscol ~

N Refs :long I

I

~ ~

Figura 5.3-5 Atributos y Propiedades de la clase treeDisca

La clase DynArray, como se aprecia en la figura 5.3-6 tiene tres atributos, un apuntador a un buffer para mantener el arreglo dinámico (array), un entero para mantener el tamaño del arreglo y otro entero para permitir apuntar a los diferentes indices del arreglo. Los métodos de esta clase son:

add(void *), permite adicionar un elemento de cualquier tipo al arreglo. remove(void *), permite eliminar un elemento del arreglo, cuando se conoce

remove(int), permite eliminar un elemento del arreglo, cuando se conoce el

reset(), regresa el apuntador del indice del arreglo hasta el inicio. next(), avanza el apuntador del arreglo al siguiente elemento. index(), regresa el índice del arreglo al cual se está apuntando actualmente. current(), regresa el contenido del arreglo en la posición actual. operator[], sobrecarga el operador [I para inicializar el tamaño del arreglo. count(), regresa el número de elementos que contiene ei arreglo.

el contenido.

indice

49

Sistema Administrador de Erlrucluras de Datos Complejas Persistentes

DynArray . .

%array : void" &size : int Uursor ' int

d DynArray () : DynArray *add (newelement : void') : int b-DynArray () *remove (rp : void') : int bremove (ri : int) : int *reset () : void *next () : void' *index () : int *current () : void' *count () : int aperator 0 (x : int) : void'

-. ~ .~ ~~ __

error (msg : char' = "") ' int

Figura 5.34 Atributos y rnetodos de la clase DynArray

La clase IOBASE, agrupa un atributo para manejar una instancia de la clase ARCHIVO (Arch), donde se almacenará toda la información fisica en una serie de bloques, un atributo para mantener la forma en que se abrió el archivo (tipoArch), un entero largo para almacenar el número de objetos almacenados en el archivo, un entero largo para significar el número de objetos referenciados por una clase, un entero largo que indica dónde se encuentra el primer bloque libre dentro del archivo, y dos objetos agregados, un apuntador a la misma clase IOBASE, que mantendrá toda la información que un objeto necesita de sus clases heredadas y agregadas (clussRefi, y otro apuntador a una clase del tipo Btree, que mantiene un árbol tipo Btree (Bí ) , balanceado y ordenado con información de los OID's de los objetos para agilizar la recuperación de un objeto. Los atributos de la clase se muestran en la figura 5.3-7. La variable ugregundoBloque es una bandera que se activa al iniciar a escribir el bloque de datos de un objeto y se apaga cuando se termina de escribir. Los métodos públicos de esta clase se muestran en las figuras 5.3-8 y 5.3-9 y se describen a continuación :

IOBASE(fstring&), constructor de la clase, recibe un sfring que incluye el nombre del archivo para una base de datos y que concatenará con las extensiones .CLS y .ARB para crear los archivos de clases y de índices. -IOBASE(), destructor de la clase. open(), método que permite abrir el conjunto de archivos existente para almacenar objetos. creaBD(), permite crear el conjunto de archivos para almacenar objetos, si ya existen se reinicializan. cierra-arch(), cierra el conjunto de archivos donde se está manipulando la información de los objetos.

50

Sistema Admlnlslrador de EstrUC1Uras de Dalos Complejas Persistentes

I ~

I !

posiciona-archivo(longgos), método que permite posicionar el apuntador del archivo en la posición referida p o r p m actualiza-n-objetos(). actualiza el numero de objetos existentes en el ~

archivo de la clase. Este método se ejecuta al insertar o borrar objetos. inicializa-nobjetos(unsigned long n). método que actualiza el atributo nobjetos de la clase al abrir un archivo que tiene un determinado número de objetos. despliega(),'método que permite visualizar la posición donde está localizado el apuntador del archivo de esta clase, así como el apuntador del objeto agregado classRef y que pertenece a esta clase. goTop(), envía el apuntador' del archivo de la clase hasta el inicio del mismo, posicionándolo antes del encabezado. goBottom(), envía el apuntador del archivo de la clase hasta el final del archivo. PosicionActual(), regresa la posición actual donde se encuentra el apuntador del archivo de la clase. LeeHeaderO, lee el encabezado del archivo de la clase. AbreArchivoBuffered(), obtiene memoria para el buffer de archivo, para el manejo de bloques en memoria. CierraArchivoBuffered(), libera la memoria adquirida para el manejo de bloques del archivo. LeeInicioBloque(), método que permite extraer el carácter que indica el inicio de bloque en el archivo de clases. AumentaNObjetos() y DisminuyeNObjetos(), estos métodos actúan sobre el atributo n-objetos de la clase aumentando o disminuyendo el número de objetos respectivamente. ActualizaRefsObjeto(string& objref), una vez que se adicionó el objeto a la base de datos, mediante este método se actualizan todas las referencias que este objeto haga a otros objetos, para mantener integridad entre objetos referenciados. DeterminaClaseObjeto(ctring& csl, string& x2), regresa en x2 el nombre de la clase a la que pertenece el objeto csf. RegresaStatusBloque(char bande), método que identifica el carácter pasado en bande como el estado de un bloque, si está libre u ocupado. Los siguientes métodos permiten escribir y leer diferentes tipos de datos primitivos en el archivo de la clase, como datos tipo entero, caracter, flotante, long, unsigned long y el tipo string persistente.

Escribelnt(int entero) LeeInt() EscribeFloat(fl0at numero) LeeFloat()

51

Sistema Adrninirtradoi de EstRidu(as de Oaios Complejas Persistentes

EscribeChar(char c) Leechar() LeeUnsignedCharO LeeLong0 EscribeLong(1ong) EscribeUlong(unsigned long) LeeULong()

PosicionaEnBloque(1ong Pos), método para posicionar el apuntador del archivo en un determinado bloque de los existentes en el mismo. ApuntadorDeBufferO, regresa el nivel actual del apuntador del buffer de memoria del archivo de la clase. CompletaBloqueClases(int level-act), método que permite completar el buffer actual del archivo de clases, cuando la información es más pequeña que el tamaño del bloque definido y debe ser enviado a disco. SKIP(), método para avanzar al siguiente objeto que se encuentre en el archivo correspondiente a la clase. PoneNombreArchivo(string& f ) , método que permite ponerle nombre al archivo de la clase. EstableceTamanoBloque(int tam), método que permite establecer el tamaño del bloque utilizado en el archivo de la c'lase. FijaTipoArchivo(char *s), establece si el archivo será de lectura, escritura o ambos tipos. ActivaAgregandoBloque(), establece que los archivos están ocupados agregando nuevos bloques. y DesactivaAgregandoBloque(), establecer que los archivos están desocupados. EstadoAgregandoBloque(), regresa el estado de los archivos para manejo de los datos, ocupados o desocupados. Escribe - Header - Arbol(Header - Arbol head), escribe en disco el encabezado en el archivo Blrec. que maneja los indices, con los datos de head. Escribe-Header - Arbol(Header - Arbol 'head), lee de disco el encabezado en el archivo Bfree que maneja los indices, en head. EsiableceTamanoHeader(int tam), define el tamaño utilizado por el encabezado del header de los archivos.

0 FinEscribeBloqueO, método que permite terminar un bloque que no se llenó completamente al finalizar de enviar información hacia él.

0 ListaBD(), método que permite visualizar el nombre de todos los objetos existentes en la base de datos, y sus clases correspondientes. LocalizaObjeto(string &), metodo que encuentra un objeto referenciado por su OID y regresa información en una instancia del tipo InfoArbol.

0 BorraObjeto(string &obj), permite borrar un objeto referenciado por obj. 0 InicializaBrowseO, permite iniciar un proceso de despliegue de todos los

objetos existentes en la base de datos.

52

I

r

. . ! '

! . I

Sistema Administrador de EStNctUraS de Datos Complejas Persistentes

RegresaSgteObjetoBrowse()o .regresa un .wing con la información del siguiente objeto eii la base de datos y su clase correspondiente. LocalizaSgteObjetoBrowse(1ong record). método que permite avanzar ai siguiente objeto cuando se está desplegando el conjunto de objeto existentes en la base de datos. Este método solaniente posiciona el apuntador ai inicio del objeto. ReturnNameFile(). regresa el nombre del Archivo donde se almacena la información. BrowseObjetos(H WND HWindow) adiciona en la ventana HWindow los identificadores de los objetos existentes en la base de datos. RegresaLevelBufferArch(), 'regresa el nivel del apuntador de'l buffer del archivo de la clase. LiberaBloques(1ong ref)> libera todos los bloques a partir del bloque referenciado por ref: y todos los que involucre como bloques de continuación de la información que estaba almacenada en ellos. Escribe-Header(). método que permite escribir la información del encabezado del archivo. El conjunto de operadores mostrado a continuación está sobrecargado para esta clase y al recibir un objeto de la clase IOBASE una operación de lectura o escritura con datos primitivos, automáticamente se envían hacia el archivo:

operator <<(int i) operator «(long i)

rn operator << (unsigned long i) operator << (float f) operator << (unsigned char c) operator << (string &) operator << (int * n) operator >> (long &i) operator >> (unsigned char& c) operator >> (float & f) operator >> (string &c) operator >> (int *n) operator >> (unsigned long &i) ;

gregandoüloque : int ,%tipoArch : char' .~üUFDiSCO : long ,&TAM-HEADER : long .$&-referencias unsigned long .@PrirnerBloqueLibre : unsigned long

Figura 5.3-7 Atributos de la clase IOBASE

Sistema Administfador de Eslmciuras de Datos Complejas persistenteS

IOBASE *IOEASE () : IOBASE *IOBASE (f : string&) : IOEASE~ *open 0 : int *-IOEASE () WreaBD () :void +Posicionaarchiw (pos :long) 'void *aclualiza-n-objetos () :void +inicializa-nobjetos (n :unsigned iong) : w i d *despliega () :void Wer raa r ch () : w id +FindObject (object : string&) : unsigned long *goTop () : w id *goBoitom () : w i d *PosicionActual () :long +Lee-Header () +AbreArchivoEuffered () : int WCierraArchivoBuffered 0 : w i d *LeelnicioEloque () : w i d *RegresaStatusBloque (bande : char) : int +ActualizaRefsObjeto (objref: string&) : int +DeterminaClaseObjeto (csl.: string&, >a :string&) : voic +EscribeNuevoBloque 0 :long +PosicionaEnEloque (Pos :long) : int WmentaNObjetos () :m id +DisminuyNObjetos () : w i d +EscribeString (plr : const void-. size : size-t) : w id +FinEscribeBloque () :void +Escribelnt (entero : int): void +ApuntadorDeBuffer () : int +CompletaBloqueClases (level-act : ¡ni) :void +Leelnt () : int +Leestring (ptr : char'. size : size-1) : w i d *EscribeFloat (numero :float) :void +LeeFloat () : iioat +EscribeChar (ch :char) : void +EscribeChar (ch :unsigned char) : w i d +Leechar () :char WeeUnsignedChar () : unsigned char +EscribeLong (numlong :long) : w i d WeeLong () :long *EscribeULong (numlong : unsigned long) : w id +LeeULong () : unsigned long +SKIP () : int +PoneNombreArchivo [f : string.?.) : void +EstableceTamanoBloque (tam : int) :void +FijaTipoArchivo (s : char') :void *EstadoAgregandoEloque [) : int WesactivaAgregandoBloque () : void +ActivaAgregandoüloque () : w i d +Lee-Header-Arbol (head : Header-Arbol") :mid +Escribe-Header-Arbol (st : Header-Arbola) :m id +EstableceTamanoHeader (tam : ¡ni) :void

~ ~~~ ~~

Figura 5.34 Métodos Publicos de la Clase IOBASE

/I

Sistema Admlnmiaaor de Estructuras de Datos Compleias Persistentes

IOBASE - *ListaBD () :w i d - OLoCaIizaObjeto (s :string&) : InfoPrbol *RegresaLevelBufferArch () , int *Borraobjeto (obi :string&) : int *LiberaBloques (ref: long) :void *EscRbe-Header () : w i d *LocalizaSgteObjeto (record :long) : void *Browse () :void *BrowseObjetos (HWindow : HWND) : void *ReturnNarneFile () : string& *RegresaSgleObjetoBrowse () : string *InicializaBrowse () :long *operator c< (i : int) : IOBASEB *operator <c (i : long) : IOBASEB *operator CC (i : unsigned long) : IOBASEB *operator c< (f : float) : IOBASEB *operator <c (c : char) : IOBASE& *operator cc (c : unsigned char) : IOBASEB *operator (c: string&) : lOBASE& *operator << (n : int') : IOBASEB *operator >> (i : inlB) : IOBASEB *operator >> (i : long&) : IOBASEB *operator >> (c : char&) : IOBASEB *operator >> (c : unsigned char&) : IOBASEB *operator >> (f : float&) : IOBASEB *operator >> (c : stnng8) : IOBASE& *operator >> (n : int.) : IOBASEB +operator >> (i : unsigned long@ : IOBASEB

Figura 5 3-9 Métodos Publicas de la Clase IOBASE (Continuacián)

La clase requerirá de algunos métodos privados para responder a los mensajes enviados a través de su interfaz pública. Estos métodos se ilustran en la figura 5.3-10 y corresponden con los que se describen a continuación:

RegresaSgteBloqLibre(), regresa el inicio del siguiente bloque libre en el archivo de la clase. LiberaBloqueO, marca como libre un bloque que previamente había sido ocupado. DisminuyeNBLOQUES(), disminuye el número de bloques que tiene el archivo. Este método actualiza la variable de control n-referencias. OcupaBloque(), marca el bloque actual de un archivo como bloque ocupado. AumentaNBLOQUESO, método que aumenta el número de bloques creados en el archivo que maneja esta clase. Este método se ejecuta al solicitar y ocupar un nuevo bloque.

55

I

II

I I

II I I¡

Sistema Adminisirador de Estructuras de Dalos Complejas Persistentes . . . " . . -

PosicionaEnBloqueSL(1ong Pos). permite posicionar el apuntador del archivo al inicio de determinado bloque referenciado por Pos. Este método se ejecuta cuando se conoce el bloque exacto donde se quiere posicionar el archivo. ValidainicioBloque(), método que verifica que el archivo de la clase esté posicionado al inicio de un bloque con el fin de garantizar consistencia al momento de la lectura de los datos. CambiaApuntadorBuffer(int i): modifica el apuntador del buffer de memoria del archivo, para sustituir su valor actual por el valor referenciado por i . MarcaBloqueContin(). este método permite que cuando la información deba ir al archivo ocupe varios bloques, se vayan marcando como bloques que continúan en algún otro bloque. MarcaBloqueLibre(1ong pos), permite marcar un bloque que previamente habia estado ocupado como un bloque libre. SgteBloqueOcupado(), partiendo de la posición actual busca el primer b l ~ q u e ocupado en el archivo de la clase y lo rqresa. SgteBloqueOcupado2(1ong posact), dada una determinada posición del archivo @osaci), de la clase, busca y regresa el primer bloque ocupado.

IOBASE RegrecaSgteBloqLibre () :long Liberaüloque () :void

Validalnicioüloque () :w id Cambia+uniadorDeBuffer (i : int) : void IvbrcaBlcqueContin O :mid b?arcaBloqueLibre (pos : long) : w i d SgteBloqueücupado 0 : int SgteBloqueOcupadoZ (posad: long) : il

. - .

Figura 5,3-10 Mbtodos Privados de ia Clase IOBASE

56

. . ~. . .~ . ~~ . 'I

Sislema Administrador de Eslnicturas de Dalos Complejas Persistentes

La clase Btree, contiene dos atributos, uno de ellos para identificar el tipo de archivo. si es lectura, escritura o lectura y escritura (TipoArci7iio). otro que mantiene la referencia al primer' objeto de un archivo Btree (Root): estos dos atributos son privados. Y una asociación a la clase IOBASE a través del atributo público del tipo apuntador a la clase IOBASE para la manipulacion de objetos en disco. La interfaz pública del objeto consiste de las siguientes propiedades:

i

I1 li

AsociaArchivo(string &filename), para adicionar un nombre identificado por filename al archivo Btree. FijaTipoArch(char *s). que permite poner la forma en que se abre el archivo Btree. AbreArchivoBufferedO, permite definir el buffer de memoria para la manipulación de bloques del archivo Btree. RecorreInOrder(). mediante este método es posible recorrer e imprimir todos los objetos almacenados en orden dentro del archivo tipo Btree. InsertaBalan(string &sl, long RefDisco), método para insertar en forma balanceada la referencia a un objeto dentro del archivo tipo Btree. BuscaEnArbol(string si), método para localizar y regresar información de un determinado OID de un objeto. IniciaRoot(1ong rl), método que permite cambiar el objeto de entrada al archivo tipo Btree. LocalizaF'nmerObjeto(). Ubica el apuntador de objetos en el archivo tipo Btree en el objeto que corresponde al primero en forma ordenada. MarcaRecordComoBorrado(1ong record), método que permite que un conjunto de bloques utilizado por un objeto que está siendo borrado se marque para después poder ser reutilizado. EscribeRecordModificado(treeDisco* p. long record), método que permite reescnbir la información de un nodo en un árbol Btree. Escribe en el archivo de indices datos modificados, recuperados previamente por medio de LeeRecordO, para el registro referenciado record.

Este conjunto de operaciones públicas se muestran en la figura 5.3-1 1. Las operaciones o métodos privados necesarios para la manipulación de los atributos de la clase Btree, son los que se muestran también en la figura 5.3-1 1 y corresponden a los que se describen a continuación:

a InsertaInOrder(string &sl, long RefDisco), inserta en forma ordenada un OID de un objeto referenciado por sl y cuya referencia en disco de objetos es RefDisco, en el archivo Btree.

o MakeNodo(string &s, long RefDisco), abre un espacio en disco para la creación de un nuevo objeto referenciado por s y cuya referencia en el archivo de objetos es Repisco.

Sistema Admmt iado i de Estructuras de Dalos Complejas penistentes

0 EscribeRecord(treeDisco *p),' almacena en el archivo la información correspondiente a un nodo del árbol ~ ~ c J c , ,

LeeRecord(1ong record). método quc regresa la información actual en un nodo de un árbol tipo Brree. referenciado por rccord. ActualizaHeader(). método que modifica el encabezado que guarda la información del archivo tipo Brree. acerca del numero de objetos y el objeto raíz del árbol. inorder, permite recorrer los nodos del objeto agregado del tipo Btree, en forma ordenada. RotaciónDerecha(treeDisco *tree, long p-record), método que ejecuta una rotación a la derecha. como resultado de un proceso de ordenamiento en el archivo tipo Bíree. RotaciónIzquierda(treeDisco * tree, long p-record), método que ejecuta una rotación a la izquierda. como resultado de un proceso de ordenamiento en el archivo tipo Btree.

o LeeRecord( long record). este método permite leer un objeto tipo freeDisco que identifica un nodo en el archivo Brrco y regresarlo a quien lo llamó.

o DesMarcaRecordBorrado(1ong record), este método permitirá reutilizar un bloque que previamente se había marcado como borrado

Btree BTipoArchivo : char. BRoot : long

+Btree () : ütree +&reArchimBuffered () : int

Liberaüloques (bloque :unsigned long) : m i d MakeNodo (s :string&, Reiüisco : long) : treeDisco' Actualiza-Header () : w i d RotacionDerecha (tree : treeDisco', p-record : long) : w i d Rotacionlzq (tree : treeDisco'. p-record :long) : w i d EscribeRecord (p : treeDisco') : long LeeRecord (record :long) : treeDisco' LeeRecord (p : treeDisco*. record : long) : m id DesMarcaRecordüorrado (record :long) : m i d InserialnOrder (s1 : string&. Remisco : long) : w i d Inorder (record : long) : w i d t FijaTipoArch (s :char') : w i d

+AcociaArchim (filename :string&) : w i d +InsertaBalan ( 51 :string&, Rei i isco :long) : w i d +MarcaRecordComoBorrado (record : long) : w i d +RecorrelnOrder () :m id +BuscaEnArbol (SI :string&) : InfoArbol +LocalizaPrirnerObjeto () :long WniUaRoot ( r l :long) : m id +EscribeRecordModificado (p : treeDisco', record :long) : w i d

Figura 5 3-1 1 Alribulos y Métodos de la Clase Btree

58

. .

Sistema Adrninislrddo~ ae Eslwcluras de Datos Complejas Persistentes

La clase IOout. Esta clase no tiene atributos. solanienie cuenta con métodos para lograr la persistencia de una clase definida por el usuario. El usuario al declarar una clase persistente automáticamente adiciona a la clase una instancia de la clase IOour , y al ejecutar el método storeon de la clase persistente automáticamente se llamará ai método AlmucenuReferenciav(/. para guardar las características del objeto que se está creando. Para recuperar el usuario creará un objeto de la clase persistente deseada mismo que tendrá una referencia a un objeto IOour, el cual ejecutará el método Recuperu-duios() para rehacer todo el objeto desde la base de datos. También cuenta con un método para listar las referencias que tiene el objeto que está ejecutando el método. Los métodos de la clase se muestran en la gráfica 5.3-12.

, WXut (f : sttins) : loout , Wmam-!aRefer&as [WedRef : string&, dsdesc : smr@ ref : unsi@ iw,

n-refermias : msigned twig. Mmerefs : Dy&ay&. dassNames : DynArráyS) : void

I J

Figura 5.3.12 Meiodos de.la Clase IOoui

59

Sistema Adminetiador de Erlmauras de Datos Compleps Persistentes

¡I

54 Validación dei Modelo.

Con las clases y operaciones identificadas, se puede ahora validar el modelo. Para validarlo se va a suponer que el usuario ha creado una clase persistente y sobre ella se definirán los siguientes casos de uso.

1. El usuario crea un objeto de una clase persistente y ejecuta la operación de

2. El usuario lee datos de una clase que previamente almacenó en disco. 3. El usuario despliega los objetos que se encuentran en la base de datos. 4. El usuario borra un objeto de su base de datos.

salvar.

Para representar cada escenario se pueden construir diagramas de objetos o diagramas de interacción. Ambos modelan la relación y la interacción entre los objetos.

5.4.1 Diagramas de interaccibn entre objetos.

Para modelar el escenario1 se suponen algunas instancias de las clases que se han definido y una adicional de una clase llamada usuario la cual sólo tendrá dos atributos (descripción de la clase string y canridad de tipo entero), de la clase string: AI objeto de la clase usuario se le llamará objeto-usuario. Previo a salvar el objeto el usuario debe crear un objeto de tipo IOout y a través del método creaBD abrir la base de datos donde se almacenarán los objetos persistentes, este objeto será referenciado como Arch. Se supone que como primer paso en la secuencia el usuario ejecuta el método storeon, sobre su objeto. Hay que recordar que este método se adiciona automáticamente a l definir una clase persistente.

Toda definición de clase persistente tendrá también dos instancias de la clase DynArruy, uno que almacena el nombre de las referencias a las instancias de otras clases y otra para almacenar los nombres de las clases a las que pertenecen estos objetos, por lo tanto, lo primero que hace el SAEDCP, es crear los objetos de tipo string con la información de la clase y se adicionan a los arreglos correspondientes, cuando se está creando el objeto del usuario objeto-usuario. En el caso de este ejemplo la clase no tiene referencias a otras clases.

A continuación en'el paso 2, se usa el método AlmucenaReferencias para almacenar los datos referenciales del objeto. Para ello: en el paso 3 se busca el objeto en el archivo de índices y si no se encuentrase envía a disco la siguiente información del objeto: su OID, su descriptor de la clase, la posición actual del archivo, el número de referencias a otros objetos, el nombre de esos objetos referenciados y las clases a las que pertenecen dichos objetos. Estas referencias corresponden a aquellas que resultan si la clase tiene heredados, agregados o asociados, si el objeto no existe se ejecuta el método storeon sobre cada uno de los objetos heredados o agregados. si el objeto referenciado ya existe, solamente se hace referencia a él.

60

v

Sislema Administsador de EslNduras de Datos Complejas PeTsistenles

Enseguida, en el paso 1 O se inserta el OID del objeto en forma ordenada en el archivo de índices y se activa la bandera (paso 11) de que fue posible referenciar el objeto y que a continuación deben salvarse los datos del objeto. En los pasos 12 y 13 se envían a disco los atributos primitivos del objeto. Y en el paso 14 se da por teminada la escritura del bloque de datos de los objetos. En el paso 15 se desactiva la bandera de agregando datos del objeto. En el paso 15 se' actualiza la información en disco del número de objetos contenidos en el sistema de archivos. Y finalmente se actualizan las referencias que otros objetos tienen cuando son referenciados por el objeto que se acaba de insertar en la base de datos.

De esta manera se concluye la secuencia de eventos del escenario o caso de uso No. 1, para guardar un objeto persistente a la base de datos. Hay que hacer énfasis en este punto, el usuario, sólo ejecutará el método storeon sobre el objeto que desea guardar y automáticamente se iniciará el proceso de enviar a disco todos los atributos de la clase que se hayan definido como persistentes.

61

I

Sistema Admlnlstladol de Estructuras de Dalos Complejas ~ersistenles

Escenario 2. El usuario lee datos de una clase que Alniaccno pre\ ' tiamente.

El usuario incluirá la definición de las clases percistenics en su aplicación y podrá reconstruir los datos de un objeto mediante la siguiente secuencia de acciones:

Definir un objeto asociado con la base de datos, donde se almacenaron previamente los

Abrir la base de datos, mediante la operación open(). Crear un objeto del tipo de la clase deseada, esto puede ser en forma dinámica o en forma estática. En el primer caso usando el operador neM1 de la clase sobre un apuntador a un objeto de la clase y en el segundo caso, utilizando el constructor de la clase. En ambos casos los parámetros principales son: el nombre del objeto que se desea recuperar y el nombre de la base de datos de donde se desea recuperar.

objetos de la aplicación.

AI determinada clase que previamente había salvado en la base de datos.

El diagrama de interacción con la secuencia de acciones entre los diversos objetos del sistema, que tienen lugar internamente dentro del SAEDCP para la recuperación de un objeto de una determinada clase persistente, se muestra en la figura 5.4-2

llevar a efecto esta secuencia de acciones el usuario recupera un objeto de una

o AI intentar reconstruir o recuperar datos de un objeto, el constructor de una clase persistente llama al método: Recupera Daíos(l0ouf & in, srring srr) , que recibe el nombre del archivo de la base de datós (in) y el nombre del objeto (slr), que se desea recuperar.

Se busca el objeto (srr) en la base de datos referenciada, usando el llamado al método de la clase IOBASE Localiza_Objeio(l y si se encuentra, este método regresará una estructura ( r ) del tipo InfoArbol. dónde se identifica la información siguiente:

la posición en el archivo de clases donde se encuentran referenciada la posición del objeto en el archivo de clases, así como la información relativa a la relación que guarda con otras clases, como es el caso de agregación o herencia.

Se lee en el archivo de clases en la posición indicada. el nombre de la clase del objeto, el nombre del objeto, la referencia en disco donde se encuentra el objeto, el número de objetos referenciados por la clase y el nombre de esas referencias.

63

. .

Sirlema AdmimSlrador de Estructuras de Dalos Complejas Persrstentes

. Se construyen los objetos de tipo arreglo dinaniico para las referencias del objeto a otras clases. Esta información se utilizara en el caso de que el objeto que se está recuperando tenga herencia de otras clases, o tenga elementos agregados.

Finalmente se posiciona en el archivo de datos de objetos, en la posición previamente leída y se leen los datos de los elementos primitivos del objeto, que en este caso corresponden a descripción y cantidad.

l l 64

Figura 5.4-2 Diagrama de Inieracci6n Para la RecuperaCibn de un Objeto Persistente


Escenario 3. Corresponde al caso en el que el usuario obticric todos los objetos que existen en la base de datos y los despliega en una ventana. Es necesario establecer que no se requieren recuperar todos los datos del objeto para poderlo hacer el despliegue de objetos, sino que solamente se necesitan la clase a la cual perienece el objeto y el nombre del objeto. Una vez que se hayan desplegado todos los objetos contenidos en la base de datos el usuario puede decidir en recuperar alguno de ellos y entonces se procederia de la misma forma como se definió en el escenario 2, para recuperar un objeto.

Se supone que el usuario ya definió una instancia de la clase IOout, que en este caso se llamará Arch.

Para iniciar la visualización de objetos, es necesario primero, obtener el número de objetos contenidos en la base de datos, usando el método InicializaBrowse(j. Enseguida se puede iniciar un ciclo desde O hasta el número de objetos y usando el método RegresuSgteObjetoBrowseO, se pueden obtener en una cadena la clase del objeto y el nombre del objeto separados por una coma, que con alguna operación de cadenas puede ser separado. El usuario podrá decidir insertar estos datos en una lista para más adelante mostrarla en pantalla. Para posicionarse en el siguiente objeto se puede hacer uso del método SKIP(), de la instancia de la base de datos.

El diagrama de interacción se muestra en la figura 5.4-3

Arch IOout claJSRef -Bee IOBASE

!

i- z . > . .

! 1- IniciaizaBrowse I ] 2: poriciona_archivo (OL) Determina d nYmem de 0b)etor en 18 bass de dalos n_obistor

3. Lee-Header ( ) . 1 ; >- 1 ;

4: LeelnicloBloqus I ) i >:

ü operator << (long Ref Disco) >

Figura 5.4-3 Diagrama de InteracMo para Desplegar los Objetos Contenidos en una Base de Datos


Escenario 4. El caso de que el usuario desee borrar un objeto de la Base de Datos. Conocido el OID del objeto, solamente es necesario que el usuario cree la instancia correspondiente a la base de datos IOou/ y ejecute e l metodo BorraObjefoO de esta instancia.

El proceso interno consiste en localizar el objeto y si se encuentra en la base de datos leer el nodo correspondiente en el archivo de índices. Después en el archivo de clases se posiciona el apuntador del archivo en el bloque correspondiente al objeto y se leen el identificador del objeto, el identificador de la clase, el número de referencias y su referencia en disco en el archivo de objetos. Luego se inicia un ciclo desde O hasta el número de referencias a otras clases con el propósito de identificar los objetos a los que hace referencia y disminuir el número de veces que estos objetos son referenciados. Se liberan los bloques ocupados por el objeto tanto en el archivo de objetos. como en el archivo de clases. Y en el archivo de índices el nodo se marca como borrado. Finalmente se actualiza el número de objetos en la base de datos.

66

Si se emuenIra el objeto en la base de dalos entmces aplicar pasos 5 a 17

Iterar desde O hasta NRe is para leer las clases a las que hace r€+eremia el objeto pasos 10 a 14

Decremmta el numero de reierencias decadaclase

I I : Borraobjeto (strings DID)

2: LccalizaOb~eto (strings OID)

3: BUScaEnArboi ( s t n q 8 OID)

4: LeeRecord (IreeDisco' p. long record)

5' PmicionaEnülque (long i e l D ~ s v ~ )

6: OPeraIM >) (strings objiname)

7. opefator >> (strings classname)

-

9. operator << (long N-Refs)

I O ' operator >> (strings ob,)

11: operator >> (strings cis)

12: LaalizaObjeto (strings obi)

15: LiberaBloques (long)

1 6 Liberaülques (long referencia)

._

18 actuallra-n-obletor ( I

Figura 5.44 Diagrama de Inleracción Para Borrar Un Objeto

67

Sislema Administrador de EstNcturas d e Dalos Complejas Pemlslentes i

I I componentes:

macrosp. Que contiene el conjunto de macros que sirven para expandir las

La aplicación del usuario deberá incluir los componentes string, Dynarray y IOouf y el módulo macrosp.

El módulo de componentes IOout depende de los módulos srringp y DynArray.

En la figura 5.5-1 se muestra la dependencia lógica entre componentes del SAEDCP.

68

Usuario

I

/ DynArray 1' I

loout

g+ \

stringp

A l

Figura 5.5-1 Diagrama de Componentes del SAEDCP

69

Sistema Administrador de Estructuras de Datos Complejas Persistenles

En este capítulo se presenta en forma detallada la construcción de una serie de clases persistentes. Se muestra la forma de definir una clase con elementos primitivos solamente, es decir sin herencia, sin agregación y sin asociaciones. El segundo ejemplo contiene la definición de una clase con una asociación. Y en el tercer ejemplo se muestra la forma de definir una clase cuando hereda de otra clase y además la clase heredada tiene una clase agregada. Los ejemplos que se han seleccionado son sencillos pero muestran el potencial del administrador de estructuras de datos complejas persistentes. Ciertamente las bases de datos Orientadas a Objetos se asocian únicamente con sistemas complicados como sistemas multimedios, sistemas expertos o sistemas de información geográfica, pero también se puede hacer uso de ellas para solucionar esquemas tradicionales como sistemas de inventarios, sistemas de facturación, etc.

6.1 Ejemplo 1

Declaración de la clase: La clase Componente con dos atributos, nombre de tipo cadena de caracteres y un entero para manejar el precio unitario, se puede declarar en C++ como se muestra en el siguiente cuadro

.lass Ccomponente

string .description; int precio-unitario;

public: string& Ret-description(); int RetqUnitario();

void modgUnitario(int new-cant);

70

Sistema Administrador de Esliunuras de Datos Cornpielas Persistentes

CComponente() ; -Ccomponente();

Se han agregado algunos métodos para la manipulación de la información.

Adicionar Persistencia.

Para agregar la persistencia a esta clase de tal forma que sus instancias puedan adicionarse a una base de datos, es necesario adicionar una serie de macros persistentes, que en primera instancia parecen complejos, pero que en realidad, una vez identificados resultan simples y fáciles de manejar. Estos macros pueden usarse como una plantilla y solamente modificar los datos pertinentes, El siguiente cuadro muestra el resultado de adicionar persistente a la clase Componente.

'include "stringp.h"

'ifndef FiO-H tinclude "1Oout.h" !define F I O H tendif

// se debe incluir para crear objetos persistentes

[include <fstream.h>

iifndef MACROSP-H #include "macrosp.h" ?define MACROSP-H Sendif

:lass Ccomponente

string descripcion; int precio-unitario;

DECLARA - DESCRIPTOR

public: string& Ret-descnpcion0;

Sistema AdminstlaJor ee Esirucluras de Dalos Complejas Persistentes

int RetpUnitario(); void modgUnitario(int ne-cant):

Ccomponente(char *01D, char *e lm, int cant) ; CComponente(char* OID): CComponente() ;

-Ccomponente();

STORE-DESCRIPTOR; definemember(descripcion): definemember@recio-unitario);

STOREON;

FINSTORE;

READFROM; READDESCRIPTOR: readmember(descripci0n); readmember@recio-unitar io);

FINREAD:

PRINTSTART; PRINTMEMBER("E1emento: ", descripci0n.s); PRINTMEMBER("cantidad: ", precio-unitario);

ENDPRINT;

START-RECUPERA-D ATOS(CComponente); END-RECUPERA-DATOS(CComponente);

Primero, deben incluirse tres archivos de encabezados, 1Out.h , macr0sp.h y stringp.h, corresponden respectivamente, a los encabezados de las clases de persistencia del SAEDCP, del archivo de macros de persistencia para expandir este conjunto de macros, y de la definición de la clase para manejo de una cadena de caracteres persistente, cabe aclarar, que esta clase tuvo que adicionarse al conjunto de librerías del SAEDCP, para lograr la persistencia de cadenas de longitud variable, contiene entre otras, operaciones para construir cadenas, para reasignar una cadena, etc.

Como segundo paso, se debe agregzr el macro DECLARA-DESCRIPTOR que agrega las definiciones de~variables para manejo de persistencia de los datos de la clase.

72

Sistema Administrador de Esirunuras de Dalos Carnplelas Persistenles

Como tercer paso, se define el conjunto de constructores necesario para manipular la clase, el sistema no genera .un identificador del objeto (Olí>). sino que esta tarea se la deja al usuario. Pero se debe tener en cuenta que en realidad combina los primeros cuatro caracteres de la clase con la cadena que define al OID por parte del usuario. Debe haber dos constructores mínimo para cada objeto, uno que defina la creación del objeto con un determinado OID y ciertos parámetros adicionales, necesarios para definir el objeto, y otro que sirve para crear objetos en forma dinámica, es decir. al principio se define un apuntador al objeto y después durante la aplicación se crea el objeto..En el último caso es necesario que se defina que el OID es nulo.

Como cuarto paso se deben inicializar las variables que permiten la persistencia de la clase, esto se debe hacer en la definición de los constructores y debe tener la sintaxis siguiente, se agrega DEF - DESCIUPTOR con el nombre de la clase como parámetro y después se inicializan todos los agregados de la clase, en este caso se inicializa el objeto agregado de la clase des,cripcion del tipo de clase string. Este es el código agregado en el archivo donde se implementa el constructor de la clase.

Ccomponente::CComponente(char 'OID. char 'elem, int cant): DEF-DESCiUPTOR(CComponente), descripcion(e1em)

En el quinto paso deben adicionarse los macros para definición de las funciones de

START-RECUPERA-DATOS. Estos macros permiten definir los elementos que el usuario desea que sean persistentes, generalmente lo son todos, para guardar un estado completo del objeto.

En el caso de STOREON, al usar el macro definemember(de~cripcion) se está definiendo que el elemento descripción del tipo string será almacenado en la base de datos. Cabe hacer notar que string es un elemento persistente por definición, es un tipo de dato definido para ser manejado como primitivo, junto con los tipos de datos, long, int, float, char, unsigned long, unsigned int, unsigned char. Una vez concluida la definición de los elementos persistentes, se termina este bloque con FINSTORE.

A continuación debe definirse el macro de recuperación para los objetos de la clase persistente, READFROM el cual de igual manera y en el mismo orden en que se definieron en el macro STOREON, se deben definir los elementos que deben recuperase de la base de datos, anteponiendo sólo READDESCRIPTOR, y enseguida los readmember necesarios. Para terminar el bloque de recuperación debe usarse FINREAD.

La definición de macros de impresión es a través del macro PRINTSTART, y se finaliza con ENDPRINT, incluyendo en el interior del bloque todos los elementos que se desean imprimir de la clase. Este es un bloque opcional, ya que generalmente se construirá una función para desplegar los datos en algún cuadro de diálogo.

persistencia: STOREON, READFROM Y PRINTSTART Y

73

Sisierna Adminislradoi de Erlrucluras de Datos Complqas PeBislenles

Para terminar, dos macros que no pueden faltar, ya que indican el control de la recuperación de un objeto, sobre todo cuando tiene objetos agregados o heredados. debe iniciar el macro con START - RECUPERA-DATOS y END-RECUPERA-DATOS, los dos macros usan como parámetro el nombre de la clase. Si la clase tuviese relaciones de herencia, agregación o asociación, deben incrustarse los macros respectivos en este bloque de persistencia, como se indica en el ejemplo 3.

De esta forma ha quedado definida una clase de tipo CComponente para ser utilizada en forma persistente. En realidad al definir los macros de persistencia se está adicionando la semántica de la base de datos, tal que el usuario no tenga que escribir código para salvar o recuperar un objeto.

Manipulación de la clase persistente.

Una vez definida la clase, se pueden crear instancias de la misma y almacenarlas si se desea en una base de datos. En el cuadro que se muestra a continuación se presenta la definición de un objeto de tipo base de datos orientada a objetos, y se adiciona o guarda una instancia del tipo de clase CComponente.

Ccomponente compol("compl","Componente X de prueba ", 10);

IOout basedat(string("compon 1 "));

basedat.creaBD();

compo 1 .storeOn(basedat);

Primeramente se crea el objeto compol, cuyo OID será CCom - compl, no olvidar que se le agregan los cuatro primeros caracteres de la clase. A continuación se declara un objeto de tipo base de datos busedar y cuyo archivo principal se llama componl . Se crea y se abre la base de datos declarada y se uso del método s/oveOn en la base de datos recientemente declarada para almacenar el objeto conipol. Y esto es todo para almacenar un objeto en la base de datos.

El código para la recuperación del objeto, se muestra en el cuadro siguiente:

IOout bd("compon1"); bd.open();

74


CComponente * comp-new; compnew = new CComponente (bd, "componl ");

Como se puede apreciar define y se abre la base de datos asociada. La recuperación del objeto se puede hacer de dos maneras:

De manera dinámica, definiendo un apuntador y creando el objeto desde una base de datos, como el caso del ejemplo, y De manera estática, creando el objeto directamente desde la base de datos, en la cual se podria hacer U'omponenre comp(bdJ, "componl '7, arrojando el mismo resultado que el anterior.

El SAEDCP preserva las propiedades y relaciones de los objetos. Si se lee un objeto de la base de datos este parece y actúa como el objeto que fue almacenado. En este caso se puede ver que CComponente, cuenta con una agregación (el objeto descripción de la clase string). El objeto recuperado tendra esta relación. Y además podrá hacer uso de las propiedades definidas para la clase CComponente.

6.2 Ejemplo2.

En este ejemplo se describirá el caso en que una clase está asociada con otra en una relación uno a uno. No se explicará a nivel de detalle que el ejemplo anterior, ya que la definición de las clases se hace en la misma forma.

Para el ejemplo se ha seleccionado la relación Producto - Componente de acuerdo a la figura 6.2-1

codigo

descnpcion , \ti; ,/scripcion

@precio-unitario . int

Figura 6.2.' Reiacioo de Asoclacion Producto-Componente

75

Sistema Administrado< de Estwctuias de Datos Complejas Persistentes

La definición de la clase CProducto persistente pueden verse en el siguiente cuadro, la clase CComponente es la misma del e,jemplo 1 y la clasc,srri,i(: es un agregado de las dos clases pero, se maneja como un tipo primitivo, por lo que no es necesario crear una clase persistente adicional.

.ass Cproducto

string codigo; string descripcion; CComponente *comp ; ublic: CProducto(); virtual -CProducto(); CProducto(char* OID, c~ x *cod, ( U * sc, CComponente& c ) :

DEF-DESCRIPTOR(CProducto),codigo(cod), descripcion(desc)

codigo=cod; descripcion = desc; comp = &c;

1 string& Ret-Codigo()( return codigo ;] string& Ret-Description() return descripcion ; CComponente *Ret-Componente() (return comp;

DECLARA-DESCRIPTOR;

STOREON:

definejother(comp);

STORE-DESCRIPTOR; definemembeflcodigo); definemember(descripcion);

FINSTORE:

RE ADFROM; READDESCRIPTOR; readmember(codig0); readmember(descripcion);

FINREAD;

'I

76

Sistema Adminislraam de Estructuras de Datos Complejas Pemisteoies

START-RECUPERA-DATOS(CProducto),

END - RECUPERA - DATOS(CProduct0); RECUPERAPOINTER(CComponente, comp),

Lo nuevo en la definición de la clase CProducto es el uso del macro dejneg-other(comp); para realizar la asociación de CProducto con el objeto comp, en el bloque de STOREON y en el bloque START-RECUPERA-DATOS se anexa el macro RECUPERA-POINTER con los parámetros: nombre de la clase y nombre del objeto.

En el cuadro siguiente se presenta el código para crear y almacenar un objeto de la clase producto, en una base de datos orientada a objetos, usando el conjunto e librerías SAEDCP.

IOout basedat(stnng("compon I 'I));

basedat.creaBD();

Xomponente compol("comp1 ","componente X para un producto",lOO);

CProducto productol("producto 1 ","prod-O01 ", "Producto 1 con componente", compo 1 );

producto 1 .storeOn(basedat);

Cabe hacer notar que el objeto producto1 de la clase CProducrol es el que ejecuta el método sloreOn para almacenar los datos, si el objeto asociado, en este caso compol, se hubiese enviado a la base de datos con anticipación a la ejecución de este método, el SAEDCP reportará que ya existe este objeto en la base de datos y solamente asociará el objeto producrol con el objeto compo1 existente en la base de datos. Si no se ha almacenado, como es el caso del ejemplo, se ejecutará automáticamente el método storeon de compol para salvar el objeto asociado.

1

i

Sistema Administiador de Estructuias de Datos Complejas Persistentes

6.3 Ejmplo3.

En este ejemplo se presentará el caso para la definicinn de un conjunto de clases en las cuales existe herencia y agregación. para ello se ha scleccionado el modelo para representar una figura geométrica, que en este caso es un círculo. definido por la clase CCirclep, que sólo tiene un atributo, r a d , para especificar el radio del circulo. Esta clase hereda de Shape que a su vez tiene dos atributos. el color de la forma. representado por colorshape, y el color del fondo de la figura, colorani. Shape tiene un agregado de la clase punto persistente CPoinp, el cual tiene dos atributos X e Y. El modelo se representa en la figura siguiente:

CPointp x t ini i

@ y t : ini I 1 *suma (deliax: int= default, deliay: int= default) :void I O M

Shape &coiorsiiaoe : ini

Idcoiorani :' int I

-.. *Draw(pDC: CDC*:default) virtualvoid& -.

Figura 6.3-1 Diagrama de Clases del Ejemplo 3

La definición s clases persistentes se muestra en los cuadros siguientes:

- class CPointp public:

// int xc, yc; CpointpO xc = yc = O;) Cpointp(char *OID, int n e w , int newy) : DEF-DESCRiPTOR(CPoíntp)

78

Sistema Administrador de Estruduras de Dalos Complejas Persistentes

xc = n e w ; yc = newy;

1 Cpointp(char *OID=O):DEF-DESCRIPTOR(CP0intp) ;

void suma(int deltax, int deltay)

xc+=deltax; yc+=deltay ;

//Macros de Persistencia DECLAIL-DESCRIPTOR;

STOREON;

// Aqui referencias a agregados

definemember(xc); definemember(yc) ;

STORE-DESCRIPTOR;

FINSTORE;

READFROM; READDESCRIPTOR readmember(xc); readmember(yc);

FINREAD;

START_RECUPERA-DATOS(CPointp), %D-RECUPERA-DATOS(CPointp);

class Shape

protected:

int colorshape; int color ant; CPointp org;

int RegresaOrigenY(); int RegresaOrigenX();

-

public:

79


Shape(char *OID=O); virtual void Draw(CDC *pDC); Shape(int color); virtual -Shape(); Shape(char *OID, int color, consi CPointp& p).

DECL ARA-DESCRIPTOR;

STOREON;

/ I Aquí referencias a agregados defineother(org);

STORE-DESCRIPTOR;: i definemember(co1orshape);

FINSTORE;

READFROM; READDESCRIPTOR; readmember(co1orshape);

FINREAD;

START-RECUPERA-DATOS(Shape); //RECüPERAPOINTER(Ccomponente, comp);

// Aqui recupera otros objetos RECUPERAFROMOTHER(CPointp, org) ;

END-RECUPERA-DATOS(Shape);

:lass CCirclep : public Shape i

int rad;

void Draw(CDC *pDC); CCirclep(char *OID, const CPointp& c, int r, unsigned long color) ; virtual -CCirclep(); CCirclep(char *OID=O):DEF-DESCRIPTOR(CCirclep) ;

mblic:

DECLARA-DESCRIPTOR;

STOREON;


/ I Aquí referencias a agregados STOREONBASE(Shape):

STORE-DESCRIPTOR; definemember(rad);

FINSTORE;

READFROM; READDESCRIPTOR; readmember(rad);

FINREAD;

START RECUPERA-DATOS(CCirc1ep); //REtUPERAPOINTER(CComponente, comp);

// Aqui recupera otros objetos RECUPERAFROMBASE(Shape) ;

END-RECUPEFU-DATOS(CCirclep);

En el momento de la asignación de un OID para objetos que tienen herencia o agregación y que deben construirse dinámicamente a partir del OID del objeto más bajo en la jerarquía, es cuando se aprecia el significado de que el OID sea una concatenación de los primeros cuatro caracteres de cada clase más el 01D del objeto, ya que de no hacerlo en el momento de la construcción de una instancia de la clase resultaría que se estaría tratando de definir con el mismo nombre objetos diferentes, y como el SAEDCP no lo permite, se decide que se concatene las Primeras letras de la cada clase con el OID del objeto. En el caso particular de la definición del objeto circl. de la clase CCirclep, se generarían los siguientes objetos en la base de datos:

La forma para crear y guardar ob.jetos de la clase círculo persistente (CCirclep), es la que se muestra en el cuadro siguiente:

CCirclep circlel("circl",pl, 150, 4 );

circle 1 .storeOn(basedat);

81

Sistema Admintsliador de Eslnic1u:as de Dalos Complejas Persistentes

Para su recuperación podría hacerse de varias formas. en Iornia directa para asignarlo a una variable del tipo CCirclep, es de la manera siguiente:

circl = CCirclep(bd, "circl") ;

Y para una forma tal que permita almacenar un conjunto de objetos gráficos en un arreglo genérico, el código sería el siguiente:

CCirclep *circ-new; -circ-new = new CCirclep(bd, csl .s); array-cir.add(circ-new);

CClientDC dc(this); Shape *cl ; array-cir.reset(); // reinicia el arreglo for (int i=O; i-aycir.count(); i++)

c l = (Shape*)arraycir.curent(); cl->Draw(&dc); array-cir.next();

// Determina el dispositivo de contexto íí Crea el objeto de más alto nivel en la jerarquía

//dibuja todos los objetos gráficos

1

En este ejemplo, se puede apreciar el crecimiento de la complejidad de los objetos creados. Se puede suponer que al igual. como se hizo para la definición para la clase círculo persistente, se puede añadir a esta clase una línea persistente, un rectángulo y en general cualquier tipo de figura, que pudiera heredar de la clase Shape. O más aun, generar una clase que heredara de la clase Circulo persistente (CCirclep), Y para hacer la estructura un poco más compleja pudiera definirse una clase con un conjunto de agregados de estas clases ya definidas para crear, por ejemplo, una clase Mono (con cara, cuerpo, manos, pies). Y empezar a construir objetos de estas instancias, que ya pueden considerarse de cierta complejidad para su almacenamiento y recuperación, pero que con SAEDCP, sigue siendo de una manera sencilla.

82


De acuerdo a la problemática establecida en el capitulo 2 del documento, se concluye que un administrador de una base de datos orientada a objetos, es la mejor solución para el manejo de estructuras de datos complejas y persistentes. Y más aun cuando permite combinar el poder expresivo de un lenguaje de programación con el lenguaje de definición de la base de datos.

En términos generales se puede establecer que el proyecto de la construcción de un administrador de estructuras de datos complejas persistentes, en este trabajo (el SAEDCP), es una herramienta que arroja varios beneficios en esta etapa inicial que servirá como plataforma para la construcción de otras implementaciones consideradas como expectativas del presente trabajo, con el fin de obtener como producto final una herramienta totalmente completa.

7.1 Beneñcios.

Tomando en consideración que los modelos de la representación de un problema de investigación o del área ingenieril, generalmente contemplan el manejo de estructuras de datos complejas persistentes, la herramienta que se diseño y construyó en este trabajo será de gran apoyo en la construcción de esos modelos, sobre todo en la forma de adicionar la persistencia de la información. La herramienta desarrollada puede aplicarse a cualquier tipo de sistema que manipule datos que representados mediante el modelo orientado a objetos y que requiera persistencia de la información. Entre otras aplicaciones en las que puede usarse esta herramienta, se encuentran los sistemas para manejo de información gráfica, con una gran cantidad de objetos combinados para formar otros objetos más complejos, otra aplicación en la que puede usarse es en los sistemas para simulación de procesos, donde generalmente, la representación de los elementos que participan en'un proceso, por ejemplo, están muy relacionados y tienen una gran cantidad de propiedades, además se requiere que en cualquier instante de tiempo de un proceso de simulación se guarde el estado de todos los elementos participantes. Así se podrían enumerar una gran cantidad de aplicaciones en las que podría tener una utilidad exitos'a esta herramienta.

Entre las ventajas más importantes del uso de una BDOO está su flexibilidad, para el soporte de datos complejos. Por qjemplo, en una base de datos convencional, si una empresa adquiere varios clientes por referencia de otros clientes que le proporcionan un servicio, pero la base de datos existente, que mantiene la información de clientes y compras, no tiene un campo para registrar quién proporcionó la referencia y de qué manera

83

Sistema Adminislrador de Estnicfuras de Datos Complejas Persistentes

fue hecho el contacto, o si debe compensarse con una comisión, sería necesario reestructurar la base de datos para añadir este tipo de modificaciones. Por el contrario, en una BDOO, el usuario puede añadir una "subclase" de la clase de clientes para manejar las modificaciones que representan los clientes por referencia. La subclase heredará todos los atributos de la definición original. contribuyendo a incrementar la productividad del programador de aplicaciones.

Una de las principales aportaciones de este trabajo es el de proporcionar un conjunto de librerías que permitan de manera natural, es decir en forma directa, a partir de la definición del modelo, obtener los esquemas para manejo de datos en forma persistente, almacenar y recuperar desde los objetos más simples hasta objetos de una extrema complejidad, donde algunos objetos contemplarán agregación en su definición, otros herencia o combinación de ambas.

El uso de esta herramienta incrementa la productividad de desarrollo de los programadores que crean sistemas complejos persistentes, al permitir el reuso de ciertos tipos de datos definidos previamente, y eliminar el tiempo dedicado a la construcción y diseño de sistemas de bases de datos convencionales y centrar la atención en forma total en el diseño del modelo de datos para cubrir los requerimientos de la aplicación final.

Otro beneficio, consiste en la generación de una herramienta que puede ser la base para desarrollo de trabajos futuros en el área de bases de datos orientadas a objetos, las cuales no están muy difundidas a pesar de su alto potencial. Queda la experiencia para apoyar en la difusión de estas herramientas y para la generación de nuevos proyectos de investigación.

Otro beneficio importante, es el uso de la herramienta como material de apoyo didáctico, para la enseñanza a nivel licenciatura y maestría, en áreas de bases de datos orientadas a objetos y en bases de datos para ingeniería.

7.2 Alcanceslogradoc.

En general el objetivo de este trabajo de investigación fue cumplido. Se creó una herramienta que permite la definición de objetos complejos persistentes.

La herramienta permite efectuar las funciones básicas de un administrador de bases de datos:

Definir un objeto, simple o complejo, y guardar información del objeto en disco y de todos los objetos a los que haga referencia, ya sea mediante agregación, asociación o herencia. Recuperar desde disco un objeto, simple o complejo, recuperando junto con él todos los objetos referenciados.

84

Sistema Administrador de Esiructuras de Datos Complejas Persistentes

Visualizar todos los objetos existentes en una base de datos orientada a objetos. Cuenta con una libreria de objetos gráficos persistentes. útil para la construcción y manipulación de objetos gráficos.

7.3 sugerencias para mejoras y ampliaciones del adminisbador de esbucáias de datos complejas persistentes (SAEDCP).

Diseño y construcción de un precompilador del lenguaje, para que los macros de persistencia que se insertan en forma manual en la clase, fuesen insertados en forma automática, con el fin de hacer más amigable la interfaz al usuario.

Implementar un nuevo tipo de dato, con el propósito de permitir la definición de conjuntos dentro de la definición de una clase y con ello poder diseñar relaciones 1 a muchos.

Agregar algunas clases persistentes para el manejo de objetos típicos, como el caso de bitmaps, datos multimedia, crear algunas otras clases para manejo de objetos gráficos basados en las que se incluyen en la herramienta.

Diseñar e implementar el lenguaje de consultas, aplicado a los objetos de la base de datos

!

85

Sislema Pdmnalradoi de EslNduras de Oatas Complejas Persistentes

ANEXOA

Instancias y esquemas de una base de datos.

Las bases de datos cambian con el tiempo al insertar y eliminar información de la base de datos. El conjunto de información almacenado en la base de datos en cierto momento se denomina una instancia en la base de datos. El diseño general de la'base de datos se llama el esquema de la base de Jatos. El concepto de esquema de la base de datos corresponde a la idea de definición de un tipo en un lenguaje de programación. Una variable de un determinado tipo tiene Un valor especifico en un momento dado. Así el concepto de valor de una variable en los lenguajes de programación corresponde al concepto de instancia en una base de datos.

Independencia de los datos.

La independencia de los datos es la capacidad para modificar el esquema en un nivel sin afectar la definición del esquema en el nivel inmediato superior. Existen dos nivel de independencia:

independencia fisica.

Capacidad de modificar el esquema fisico sin obligar a que se vuelvan a escribir los programas de aplicación.

Independencia lógica

Capacidad de modificar el esquema conceptual sin obligar a que se vuelvan a escribir los proganias de aplicación. Las modificaciones en el nivel conceptual son necesarias cuando se altera la estmctura lógica de la base de datos.

El lenguaje de definición de datos

Es el lenguaje usado para especificar el esquema de la base de datos (en inglés DDL, data definition ianguaje). El resultado de la compilación de las proposiciones en DDL es un conjunto de tablas que se almacenan en un archivo especial llamado diccionario de datos. El diccionario es un archivo que contiene metadatos, es decir, datos acerca de los datos.

86

Sistema Administrador de Esihlduras de Datos Complejas Persistenles

La estructura de almacenamiento y los métodos de acceso empleados por el sistema de base de datos se especifican por medio de un conjunto de definiciones de un tipo especial de DDL llamado lenguaje de almacenamiento 1 definición de los datos

Lenguaje de Manejo de Datos.

El manejo de los datos consiste en:

La recuperación de información almacenada en la base de datos

La inserción de información nueva en la base de datos.

La eliminación de información en la base de datos.

En el nivel fisico, deben definirse algoritmos que permitan tener acceso a los datos en forma eficiente. En los niveles de abstracción más altos lo imFortante es la facilidad de uso. El objetivo es lograr una interacción eficiente entre las personas y el sistema.

Un lenguaje de manejo de datos (en inglés, DML, data manipulation language) permite a los usuarios manejar o tener acceso a los datos que estén organizados por medio del modelo apropiado. Existen básicamente dos tipos de DML.

De procedimientos. Necesitan, que el usuario especifique cuáles datos quiere y cómo deben obtenerse.

Sin procedimientos. Requieren, requieren que el usuario especifique cuáles datos quiere sin especificar cómo obtenerlos.

Una consulta es una proposición que solicita la recuperación de información. La parte de un DML que implica la recuperación de información se conoce como lenguaje de consultas.

Manejador o Administrador de la Base de Datos.

Es la interfaz entre los datos de bajo nivel almacenados en la base de datos y los programas de aplicación y las consultas hechas ai sistema El manejador de la base de datos es responsable de las siguientes tareas:

Interacción con el manejador de archivos.

Los datos sin procesar se almacenan en disco mediante el sistema de archivos proporcionado normalmente por un sistema operativo convencional. El manejador de base de datos traduce las diferentes proposiciones del DML a comandos de sistemas de archivos de bajo nivel.

87

!

Sistema Adminislrador de Estniduras de Datos Complejas Persistentes

Así el manejador de base de datos se encarga rcalmente del almacenamiento, recuperación y actualización de los datos en la bare de datos.

rn Implantación de la integridad.

Los valores en la base de datos deben satisfacer ciertos tipos de limitantes de consistencia, por ejeniplo cierto dato no debe admitir valores menores que cierta cantidad. El administrador de la base de datos debe especificar en forma explicita estas limitantes. El manejador de la base de datos deberá verificar que durante las actualizaciones a la base de datos no haya violaciones a estas limitantes.

Puesta en práctica de la seguridad.

Debido a que no todos los usuarios deben tener acceso a todo.el contenido de la base de datos, es preciso que haya un mecanismo para prevenir que los datos sean accesados sólo por los usuarios con autorización para ello.

Respaldo y recuperación.

Si el sistema falla, es reponsabilidad del manejador de la base de datos detectar las fallas y restaurar la base de datos al estado que existía antes de presentarse la falla: esto se logra normalmente iniciando diversos procedimientos ae respaldo y recuperación.

rn Control de concurrencia.

Cuando varios usuarios tienen acceso a la base de datos en forma concurrente, pueden surgir problemas de consistencia de los datos. Es necesario que el sistema controle la interacción entre los usuarios concurrentes.

Administrador de Base de Datos.

La persona que tiene el control sobre el sistema es el DBA (en inglés, data base administrator). Las funciones del administrador de base de datos son:

Definición del esquema.

rn Definición de la estructura de almacenamiento y del método de acceso.

Modificación del esquema y de la organización fisica

Concesión de autorización para el acceso a los datos

Especificación de las limitantes de integridad.

88

Sistema Adrnlnatrador de Estuduras de Dalos ComWias Persistentes

Usuarios de la Base de Datos.

Existen tres tipos de usuario de un sistema de base de datos y se distinguen en la forma como ellos esperan interactuar con el sistema.

Programadores de aplicaciones. Usuarios que interactúan con el sistema mediante llamadas al DML, las cuales están incmstadas en un programa escrito en algún lenguaje huésped. Estos programas se llaman programas de aplicaciones.

Usuarios casuales. Usuarios que' interactúan con el sistema sin escribir programas. Solamente hacen consultas al sistema a través del lenguaje de consultas.

Usuarios ingenuos. Usuarios que interactúan con el sistema llamando alguno de los programas de aplicaciones escritos previamente.

Usuarios especializados. Usuarios que escriben aplicaciones para la base de datos que no encajan en el marco tradicional de procesamiento de información. Entre dichas aplicaciones se cuentan los sistemas de diseño asistido por computadora, los sistemas expertos, los sistemas que almacenan información con tipos complejos (p. ej., datos gráficos o de audio), y los sistemas que incluyen el modelado dinámico de sistemas de procesos.

89

Sistema Admmstradoi de Eslniduras de Datos Carnpiejas PelSisfenteS

1 ANEXOB

!!

/I

Los requerimientos de un sistema de base de datos de pueden clasificar como fundamentales, básicos y secundarios. A continuación se describen brevemente.

rn Fundamentales.

- Que soporte un modelo de datos y un lenguaje. - Que soporte relaciones entre entidades. - Que tenga persistencia. - Que soporte concurrencia. - Que maneje un tamaño arbitrario de base de datos.

rn Básicos.

- Que tenga un sistema de integridad. - Que tenga un sistema de seguridad. - Que tenga un lenguaje de consultas. - Que proporcione un metamodelo. - Que soporte la definición de vistas. - Que proporcione software para la administración de la base de datos

Secundarios.

- Que proporcione un generador de reportes y formas. ' - Que soporte un diccionario de datos.

El Modelo de Datos.

Existen varios enfoques para modelar los datos en los niveles externo y conceptual. Estos enfoques incluyen el uso de modelos sernánticos, diagramas entidad-relación y diseños orientados a objetos. Algunos modelos son:

El modelo entidad-relación E R

Sistema Administrador de EstNuuras de Datos Complejas Penistentes

Modelos lógicos. Modelo relacional. Modelos semánticos. Modelos orientados a los objetos.

Todas estas técnicas manejan conceptos comunes, expresadas en la forma como manejan los elementos y sus conexiones, como se muestra en la Fig. B. I . Por ejemplo, en el modelo orientado a objetos, los objetos corresponden a las entidades en el modelo entidad-relación, mientras que los mensajes corresponden a las relaciones.

El enfoque orientado a los objetos ve el mundo en términos de objetos que son elementos conceptualmente identificables. Cada objeto tiene un conjunto de atributos que pueden tener valores. Los objetos tienen métodos asociados que describen un comportamiento con respecto a otros objetos. Los objetos interactúaii con otros a través de mensajes. Los objetos pueden heredar dentro de un jerarquía de clases.

Los modelos de datos semánticos se diseñaron para solucionar el problema del pobre significado que las bases de datos tradicionales tienen, incorporando más signiricado hacia la base de datos. Un enfoque a modelos de datos semánticos, adiciona significado hacia una base de datos en cuatro etapas.

1. Identifica un conjunto de conceptos semánticos que describen información relevante y significante. Este conjunto de conceptos incluye instancias: propiedades y asociaciones. Estos conceptos pueden ser ligados en un formalismo descriptivo donde el mundo se describe en términos de entidades, que son descritas por propiedades y ligadas por asociaciones.

2. Representa los conceptos semánticos identificados en el.estado anterior, en términos de un conjunto de objetos simbólicos correspondientes. tales como los proporcionados en el modelo entidad-relación.

3. Dispone un conjunto de reglas de integridad que gobiernan la descripción de los conceptos semánticos en términos de los objetos simbólicos.

4. Desarrolla un conjunto de operadores para manipular los objetos simbólicos.

El enfoque entidad-relación (ER) es una técnica Pmpliamente aceptada como modelo de datos (Chen 1976). En el modelo ER. una entidad es un objeto o cosa que existe y puede ser distinguida de otras entidades. Una entidad puede ser una persona, una institución, un avión, etc. Las entidades se describen en términos de sus atributos o propiedades. Las entidades generalmente representan a los registros, mientras que los atributos son representados como los campos de estos registros. Una relación se define como una lista ordenada de conjuntos de entidades. Aunque existe mucha analogía entre el modelo relacional y el modelo entidad-relación, también hay diferencias importantes. El modelo entidad relación es una descripción conceptual que no determin,a cuales- relaciones pueden o deberían ser necesarias y cuales relaciones pueden o deberían ser omitidas, De acuerdo con esto el modelo entidad-relación puede ser útil como un punto de inicio para construir una base de datos relacional.

91

I I I II

1 Las relaciones entre entidades

U R Lógicos Relaciona1 Semanticos Orientado a Objetos

Entidad Argumento Registro-Tabla Concepto Objeto Atributo Predicado Campo Propiedad Atributo Relación Predicado Tabla Asociación Mensaje.

il

/I

Se puede definir la entidad como aquel objeto (real o abstracto) acerca del cual se quiere almacenar información en la base de datos. Existen tres reglas generales que debe cumplir una entidad :

tiene que tener existencia propia cada ocurrencia de un tipo de entidad debe poder distinguirse de las demás todas las ocurrencias de un tipo de entidad deben tener los mismos tipos de caractensticas (atributos)

Existen dos clases de entidades: regulares, que son aquellas que tiene existencia por sí mismas, y débiles cuya existencia, depende de otro tipo de entidad.

Por interrelación se entiende aquella asociación o correspondencia existente entre entidades. Entre dos tipos de entidades puede existir más de un tipo de interrelación.

Persistencia.

Persistencia es la propiedad que permite que una vez finalizada una transacción con éxito, sus efectos perduren en la baje de datos.

Concurrencia.

En sistemas multiusuarios es necesario un mecanismo de control de concurrencia.

Se trata de un mecanismo' imprescindible para consenw la integridad de la base de datos en la que se pueden producir importantes inconsistencia derivadas del acceso concurrente, como por ejemplo de la operación perdida. Suponiendo que en una biblioteca, para cada libro existente hay un campo en el que se almacena el numero de copias disponible para préstamo. El valor de este campo debe incremeniarse en 1 cada vez que se devuelve un ejemplar del libro y disminuirse en la misma cantidad cuando se presta un ejemplar de este libro. Si existen varias bibliotecarias, podría suceder que una de ellas iniciara una transacción TI leyendo en un

92

Sistema Admnirlrador de Esbuduras de Dalos Comwjas Persistentes

determinado momento la variable número de ejemplares W). cuyo contenido se podría guardar en la variable nl; al poco tiempo. otra bibliotecaria p d n a leer esa misma vanable incrementando en una unidad (transacción T2). Si poco despues la transacción iniciada por la primera bibliotecaria también añade una unidad a esa variablc y la actualiza, el resultado es erróneo, puesto que ai final de las dos transacciones en lugar de haberse incrementado la variable N en dos unidades, sólo se ha incrementado en una. La operación T2 se ha perdido.

Se han implementado técnicas para el coiitrol de concurrencia, las cuales se dividen en técnicas psimistus, como el bloqueo y las marcas de tiempo. que establecen controles previos para evitar que se produzcan situaciones que puedan provocar inconsistencias, y en técnicas optimistas, que suponen que en principio no tiene porqué haber problemas y en el caso que éstos tengan lugar, actúan a fin de volver la base de datos a un estado original consistente.

Tamaño arbitrario de la base de datos.

Este requerimiento establece que el tamaño de la base de datos sólo es restringido por la capacidad del dispositivo de almacenamiento masivo, generalmente un disco. La forma de guardar la información no influye en la capacidad de almacenamiento de la base de datos.

Integridad.

El objetivo de implementar un subsistema de integridad es proteger la base de datos contra operaciones que introduzcan inconsistencias en los datos. Se habla de integridad en el sentido de corrección, validez o precisión de los datos de la base. El subsistema de integridad, debe detectar y corregir, en la medida de lo posible. las operaciones incorrectas.

Seguridad

El objetivo del concepto de seguridad. (a veces referenciado como recuperación, del inglés recoveiy), es el de proteger la base de datos contra fallos lógicos o físicos que desiruyan los datos en todo o en parte. Estos fallos van desde catástrofes. como un incendio o un terremoto, sabotajes, fallos del sistema operativo y fallos de disco u otras caídas del sistema, sea cual sea la causa que las ha provocado. En io que afecta al sistema de gestión de base de datos, existen dos tipos importantes de fallos:

Los que provocan pérdida de memoria volátil @or interrumpirse el suministro eléctrico o por funcionamiento anormal del equipo físico). Los que provocan la pérdida de contenido de memoria secundaria, (el producido, por ejemplo, al fallar las cabezas de un disco).

I

93

Ststema Administrador de Estructuras de Dalos Complejas Persistentes

El lenguaje de Consultas.

Este es un requerimiento para proporcionar al usuario una interíaz amigable, para la consulta de la información existente en la base de datos. Entre las funciones que normalmente se encuentran no sólo funciones de consulta. sino que también realiza permiten la definición de la estructura de los datos, lamodificación de los mismos. y para especificar las limitantes de la seguridad.

El metamodelo.

El metamodelo es un modelo que define el lenguaje para expresar una abstracción semánticamente consistente de un sistema. Los datos, en un principio, se organizaban a fin de atender a las necesidades de cada proceso; posteriormente se intenta que respondan a los requisitos de un conjunto de pi-oceso, y, por último, se busca una interpretación de la realidad con el objetivo de conseguir captar la semántica del mundo real.

Definición de vistas.

El sistema de administración de una base de datos tendrá que atender ordinariamente múltiples pedidos simultáneos de datos. Debe por tanto organizar JUS almacenes intermedios de modo que en ellos puedan procesarse varias operaciones al mismo tiempo. Es posible que múltiples programas de aplicación se hallen en ejecución al mismo tiempo y que ellos utilicen diferentes subesquemas. El sistema debería estar organizado de manera que la vista del programador de aplicaciones se restrinja al programa de aplicación, su área de trabajo y su subesquema. Muchos analistas de sistemas tendrán que estar familiarizados con el esquema, pero su perspectiva debería estar limitada de modo que nada tengan que ver con las estructuras fisicas. Por otra parte, el programador de sistemas y otros especialistas tienen como campo de actividad la organización física de los datos. Su perspectiva debe estar limitada de manera que no la afecten los cambios que introduzcan los programas de aplicación y los subesquemas, siempre que estos no requieran un cambio de esquema.

El software para la administración de la base de datos.

Que el sistema manejador de la base de datos, consistente en el conjunto coordinado de programas, procedimientos y lenguajes, proporcione los medios necesarios para describir, recuperar y manipular los datos almacenados en la base, manteniendo su integridad, confidencialidad y seguridad.

El generador de reportes y formas.

94

/I

Sistema AdmnuShadat de Esmauras de Datos ComFiejas Persistentes

El generador de reportes es un programa de aplicacion que permite presentar en forma organizada y rápida de acuerdo a las necesidades del usuario. información extraída de la base de datos, mediante alguna consulta.

El diccionario de datos.

El diccionario de datos reúne la información sobre los datos almacenados, como descripciones (narrativas y técnicas). significado estructuras, consideraciones de seguridad, edición y uso de Las aplicaciones, etc., esto es lo que los usuarios necesitan para comprender el significado de los datos y poder recuperarlos y manejarlos adecuadamente. El diccionario de datos tiene, por tanto, una finalidad de descripción lógica de los datos y está orientado hacia el usuario.

95

ANEXO c

AI inhwluccióna UML

E] Lenguaje Unificado de Modelado UML (siglas en inglés de Unified Modeling Langmje), es estándar que surge de la combinación de lo mejor de:

e Conceptos de modelado de datos (diagrama entidad relación). e Modelado de negocios (diagranas de flujo) 0 Modelado de Objetos. e Modelado de Componentes

UML es el lenguaje estándar para visualización, especificación, construcción y documentación de los elementos de un sistema de software.

UML combina los métodos de Jacobson, Rumbaugh y Booch, utilizando conceptos implementados en estos modelos, por ejemplo: se utiliza el concepto centrado en los datos de las metodologías de Rumbaugh. MartídOdell y Shlaerhlellor. el concepto de basado en escenarios de Jacobson y el concepto estructural de Booch, como categonas para las diferentes clases de métodos.

De los métodos mencionados, cada uno tiene su potencial. Rumbaugh es muy fuerte para producir el modelo del dominio de los objetos'. Jacobson tiene un método fuerte para producir el control del usM0, modela el espacio de solución y Booch tiene un método fuerte para producir el modelo OOD.

Cada método tiene también sus puntos débiles. Mientras que Rumbaugh es fuerte para modelar el problema en el dominio, el modelo de OMT puede ser simplista para el espacio de solución. Jacobson enfatiza el dominio de modelado, y mientras cubre un amplio rango del ciclo de vida no trata de manera detallada el OOD en el mismo nivel que Booch, quien se centra totalmente en el diseño, no en el análisis.

96

sistema p,jmrnstra~ de E s t m m s de Datos Complejas Persistentes

A2 Elementos notachnales de UML

A Conhmción se revisan 10s conceptos básicos de los diversos elementos notacionaies que presenta el Lenguaje Unificado de Modelado. Estos elenicnios pretenden ser un lenguaje c o m h para el modelado de cualquier sistema.

Esta descripción no pretende ser exhaustiva en términos sintácticos, semánticos y de presentación de los elementos de la notación., debe entenderse como una guía inicial al tema en forma más extensa pueden encontrarse en la Ref. [ 191

Para su descripción se agrupan los conceptos básicos por tipo de diagrama:

1. Diagrama de Estructura Estática 2. Diagrama de Casos de Uso 3. Diagram a de Secuencia 4. Diagrama de Colaboración . 5. Diagrama de Estados 6. Diagrama de Implementación

C.l.l Elementos básicos en un diagrama de estructura esiática o diagrama de clases.

Un diagrama de estnictura estática muestra el conjunto de ciases y objetos importantes que forman parte de un sistema, junto con las relaciones existentes entre estas clases y objetos. Muestra de una manera estática la estructura de información del sistema y la visibilidad que tiene cada una de las clases, dada por sus relaciones con las demás en el modelo.

Ejemplo de la Máquina de Café

Supongamos que se requiere desarrollar el control de una máquina de entrega de café automática. La máquina debe permitir a una persona depositar una cantidad de dinero en monedas de 100, 200 o 500. escoger uno de los productos de acuerdo a su precio (café negro concentrado, café negro normal y café negro claro ), escoger (si es pertinente) un nivel de azúcar y entregar el producto y el cambio. El dinero que los usuarios introducen se guarda en un recipiente aparte al disponible para cambios, el cual se encuentra ordenado por denominación. Existen estados de error de la máquina. cuando detecta un mal funcionamiento, inexistencia de cambios o inexistencia de ingredientes. El usuario puede en cualquier momento antes de escoger el azúcar cancelar la operación, mediante un botón existente uara este obietivo.

_ I ~

Si se supone el modelado de una W n a de cafe. Un diagrama de estructura estática inicial podría ser:

97

','

swma Mmmsiraaa de Eslniduras de Datos Complejas Penistentes

lnorediente I mgredienles

@nombre string ,&cantidad float = O

siring I - - .. ..&nombre - . _ , 1 1 . . - ,&costo : float = O I

Maquina 7 recoieclado i_

. - _- : int = O I ,,_,_

-. . . . -.l"

. *RecibirMoneda( )

,// Todo ingrediente en

existencias

200 o 500

*AgregarMoneda( )

. . Clase

Representada por un rectángulo con tres divisiones internas. son los elementos fundamentales del diagrama. Una clase describe un conjunto de objetos con características y comportamiento idéntico.

I ClaccName I

En el ejemplo se encuentran las clases Ingrediente, Producto, Máquina, DepositoMonedas y DepositoMonedasIguales.

Los tres compartimientos estándares alojan el nombre de la clase, sus atributos y sus mensajes, respectivamente.

Atributo

sistema Administrador de Estnicluras de Datos Complejas Persistentes

Identifican 1% caractensticas propias de cada clase. Generalmente Son de tipos simples. ya que los de tipos compuestos se representan mediante asociaciones de Composición con otras clases. La sintaxis de un atributo es: . .

visibility name ; type-expression = initial-value property-sthng 1 Donde visibility es uno de los siguientes:

+ public visibility

# protected visibility

- pnvate visibility

typeexpression es el tipo del atributo con nombre name. Puede especificarse como se ve un valor inicial y un conjunto de propiedades del atributo.

En el caso del ejemplo, la clase Ingrediente tiene dos atributos: uno denominado cantidad, de tipo float y con valor inicial O: y el atributo nombre de tipo string sin valor inicial. En este caso, la herramienta utilizada para generar los diagramas (rational ) ha cambiado la represenración de la visibilidad, utilizando el síniholo para visibilidad protegida y el siniholo ~ para indicar visibilidad pública,

para indicar visibilidad privada, el símbolo

Operación

El conjunto de operaciones dcscrihen el comportamiento de los objetos de una clase. La sintaxis de una operación en UML es:

visibility name ( parameter-list ) : return-type-expression prope~-str ing)

Cada uno de los parámetros en parameter-list se denota igual que un atributo. Los demás elementos son los mismos encontrados en la notación de un atributo.

Asociación (rol, multiplicidad, cualificador)

Una asociación en general es una linea que une dos o más símbolos. Pueden tener varios tipos de adornos, que definen su semántica 4 características. Los tipos de asociaciones entre clases presentes en un diagrama estático son. 4'

Asociación binxia Asociación n - x i a Agregación o Composición

99

-~ .. . -. -

sistema AdminiSVador de Esmiduras de Datos Complejas Persistentes

Generalización Refinamiento

Cada asociación puede presentar algunos elementos adicionales que dan detalle a la relación, como son:

Rol: Identificado como un nombre al final de la línea, describe la semántica de la relación en el sentido indicado. Por ejemplo, la asociación de composición entre Máquina e Ingrediente recibe el nombre de existencias, como rol en ese sentido

Multiplicidad: Describe la cardinalidad de la relación. En el ejemplo anterior se utilizan 1, 1 ..*, 5, *, como indicadores de multiplicidad.

Asociación binaria

Se identifica como una línea sólida que une dos clases. Representa una relación de algún tipo entre las dos clases, no muy tuerte (es decir, no se exige depsndencia existencia1 ni encapsulamiento).

En posible ejemplo es la relación entre una compañía y sus empleados:

empleador empleado 1. Persona 1 Trabaja Para u

-1 1 ..*

en este caso la relación recibe el nombre genérico Trabaja Para, la compañía tiene uno o más instancias de la clase Persona denominadas empleado y cada empleado conoce su empleador (en este caso único).

Agregación ó Composición

Es una forma de relación más fuerte donde la relación es entre un todo y sus partes. La clase cliente es algunas veces llamada clase agregada, una instancia de la clase agregada es un objeto agregado. La clase proveedor de la relación es el todo de la parte. La agregación se usa para mostrar que el objeto agregado está tisicamente incluido en otra clase. Se dibuja con una línea y en el extremo de la clase agregada he dibuja un rombo.

loo

Sistema Administrador de Esmduras de Datos Complelas Persistentes

(I- 1 supplier 1 3- -

Dependencia

Denota una relación semántica entre dos elementos (clases o paqutes) del modelo. indica que cambiar el elemento independiente puede requerir cambios en los dependientes.

Expresa una relación entre dos clases para mostrar que la clase cliente depende de la clase proveedor para suministrar ciertos sewicios, tales como:

La clase cliente accesa un valor (constante o variable) definido en la clase proveedor. Operaciones de la clase cliente invocan operaciones de la clase proveedor. El valor de retorno o el valor de un argumento en las operaciones de la clase cliente son instancias de la clase proveedor.

, jTEi-l . . . . . . . - . . . . . .

Generalización

La relación de generalización denota una relación de herencia entre clases. Se representa dibujando un triángulo sin rellenar en el lado de la superclase. La subclase hereda todos los atributos y mensajes descritos en la superclase. En el ejemplo se encuentra una generalización entre DepositoMonedas (superclase) y DepositoMonedasIguales (subclase).

101

sistema Administrador de Estuduras de Datos Complelas Penistentes

lnterfaz MFC

Clase paramétrica

Una clase paramétrica representa cI concepto de clase genérica en los conceptos básicos O 0 o de template en Ct+. Se dibuja como una clase acompañada de un rectángulo en la esquina superior derecha, con los paráiiietros del caso.

Paquete

Un paquete es una forma de agrupar clases (u otros elementos en otro tipo de diagramas) en modelos grandes. Pueden tener asociaciones de dependencia o de generalización entre ellos. Un ejemplo puede ser el siguiente

lnterfaz MFC l-7 > -

Modelo del

-.. -. P-l Comunicaciones

En este caso existen tres paquetes (que se muestran vacios en este caso, con su contenido encapsulado), con dos de ellos dependiendo del Modelo del Mundo

Nota

Es un comentario dentro de un diagrama. Puede estar relacionado con uno o más elementos en el diagrama mediante lineas punteadas. Pueden representar aclaraciones al diagrama o reshicciones sobre los elementos relacionados (cuando el texto se encuentra entre '['y '7'). Se representa mediante un rectángulo con su borde superior derecho doblado.

En el ejemplo inicial de esta anexo se encuentran dos notas: Una relacionada con la clase máquina y otra con el depósito de monedas iguales.

C.1.2 Conceptos de un Diagrama de Casos de Uso.

Un Diagrama de casos de uso es una secuencia de transacciones desarrdlada por el sistema en respuesta a un evento disparador iniciado por un actor del sistema. Un caso de uso muestra las distintas operaciones que se esperan de una aplicacijn o sistema y cómo se relacionan con su entomo (usuarios u otras aplicaciones).

Casodeuso.

Se representa en el diagrama por una elipse, denota un requerimiento solucionado por el sistema. Cada caso de uso es una operación completa desarrollada por los actores y por el sistema en un diálogo. El conjunto de casos de uso representa la totalidad de operaciones desarrolladas por un sistema. Va acompañado de un nombre significativo. Por ejemplo, en el caso de cafetera, se tienen como casos de uso: Recibirlhero. PedirAnicar, PedirProducto, Darvuelto y Cancelar.

lo3

-.. , . ~

-, Cisterna Admnsbadar de Estniduras de Datas ComPkJas Persistentes

RecibirDinero (,----3 Pedir &u c a r

Pedir Producto

Darvueltas Cancelar

Actor.

Es un usuario del sistema. que necesita o usa algunos casos de uso. Se representa mediante un.

acompañado de un nombre significativo. Q A

Relaciones en un diagrama de casos de uso.

104

Sistema Administador de Estnidiras de Dalos Compkjas Persistentes

Entre los elementos de un diagrama de Casos de Uso se pueden presentar tres tipos de relaciones, representadas por líneas dirigidas entre ellos (del elemento dependiente al independiente).

Comunica. Relación entre un actor y un caso de uso, denota la participación del actor en el caso de uso determinado.

Usa. Relación entre dos casos de uso, denota la inclusión del comportamiento de un escenario en otro.

Extiende. Relación entre dos casos de uso, denota cuando un caso de uso es una especialización de otro.

C.13

Un Diagrama de Secuencia muestra la interacción de un conjunto de objetos en una aplicación a través del tiempo. Esta descripción es importante porque puede dar detalle a los casos de uso, aclarándolos al nivel de mensajes de los objetos existentes, como también muestra el uso de los mensajes de las clases diseñadas en el contexto de una operación. A continuación se muestra un ejemplo de diagramas de secuencia . para detallar el caso de uso PedirProducto del ejemplo de la cafetera.

Conceptos Básicos en un Diagrama de Secuencia.

1 m: 1 I p:Producto 1 MáauinaCafe I : lnarediente I

PedirProducto

I < , I

, I

sobrante del precio del producto

Servir ( Servir

Darvueltas

1

1 o5

Sistema Adminishador de Estniciuras de Datos Complejas Persistentes

Un objeto se representa como una linea vertical punteada con un rectángulo de encabezado y con rectángulos a través de la linea principal que denotan la ejecución de métodos. El rectángulo de encabezado contiene el nombre del objeto y el de su clase.

Línea de vida de un objeto.

Activación.

Muestra el pendo de tiempo en el cual el objeto se encuentra desarrollando alguna operación

Mensaje.

El envío de mensajes entre objetos se denota mediante una línea sólida dirigida, desde el objeto que emite el mensaje hacia el objeto que lo ejecuta.

C.1.4 Conceptos Básicos en un Diagrama de Colaboración.

Un diagrama de colaboración es una forma de representar interacción entre objetos, alterna al diagrama de secuencia. A diferencia de los diagramas de secuencia, pueden mostrar el contexto de la operación (cuáles objetos son atributos, cuales temporales, ...) y ciclos en la ejecución. Para el caso de uso PedirProducto del ejcmplo de la cafetera, el diagrama de colaboración sena:

Sistema Administrador de ~sbuciuras de Datos Complejas Persistentes

3: Darvueltas (int) d

m : MáauinaCafe

4 I: Servir ( ) +=association>> 1 p : Producto 1

j, 2: (i=i ..n) Servir (int)

I ' I

[ inaredientes : lnarediente

Objeto

Un objeto se representa con un rectángulo. que contiene el nombre y la clase del objeto .

Enlaces.

Un enlace es una instancia de una asociación en un diagrama de clases. Se representa como una linea continua que uno dos objetos. Esta acompañada con un número que indica el orden dentro de la interacción y por un estereotipo que indica que tipo de objeto recibe el mensaje. Pueden darse varios niveles de subindice5 para indicar anidamiento de operaciones. Los estereotipos indican si el objeto que recibe el mcnsrije es un atributo, un parámetro de un mensaje anterior, si es un objeto local o global.

107

Sistema Administrador de Esbuduras de Datos Campielas Persistentes

Flujo de Mensajes.

Expresa el envío de un mensaje. Se representa mediante una flecha dirigida cercana a un enlace.

C.1.5 Conceptos Básicos en Un Diagrama de Estados.

Un diagrama de estado muestra el conjunto de estados por los cuales pasa un objeto durante SU vida en una aplicación, junto con los cambios que permiten pasar de un estado a otro. Un ejemplo en el caso de la cafetera son los estados posibles para la clase MaquinaCafe:

odo0k = false ] Todc,'jk:iriJe 1 MalFuncionamiento

V BuenFuncimarniento

Lista

MosiraiDineroActual

I J

uset~nput! Burton )[ todoOk = true 1 I MOsirarNiveIA~u~ar MostrarProducto [TodoOk = true] I

Initlndicadores I

[ TodoOk=true 1 I seMrFrOdUCt0

[ TodoOk = false ]

userlni

\

I

Ofíüunon 1

Estado.

Identifica un período de tiempo dd ohjcto (no instantáneo) en el cual el objeto está esperando alguna operación, tiene cierto e m d o cmcteristico o puede recibir cierto tipo de estímulos. Se

.. - Sistema Admmisbador de Estniduras de Datas Complejas PenisteIUer

representa mediante un rectángulo con los bordes redondeados, que puede tener tres compartimientos: uno para el nombre, otro para el valor caracteristico de los atributos del objeto en ese estado y otro para las acclones que se realizan al entrar, salir o estar en un estado

Se marcan también los estados iniciales y finales mediante los símbolos:

Eventos.

Es una ocurrencia que puede causar la transición de un estado a otro de un objeto. Esta ocurrencia puede ser una de vanas cosas:

Recepción de un niensaje.

Condición que toma el valor de verdadero o falso. Recepción de una seiial de otro objeto en el modelo

Paso de cierto período de tiempo.

C.1.6 Conceptos Básicos en un Diagrama de Implementación.

Un diagrama de implementación muestra la estnictura del código (Diagrama de Componentes) y la estructura del sistema de ejecucicin (Diagrama de ejecución).

Diagrama de Componentes

Un diagrama de componentes muestra las dependencias lógicas entre paquetes de componentes y componentes de software. Los componentes se derivan de los siguientes elementos de Booch: programa principal. paquete, subprograma y tareas. Cada diagrama de componente provee una vista fisicn del modelo actual.

Los diagrama de componentes contienen íconos para representar los siguientes elementos, cada uno de ellos se ha asociado con la figura de igual número para mostrar su icono respectivo,

1. Paquetrs de componentes. 2. Componentes. 3. Programa Principal 4. Paquetcs. 5. Subpro, vmias. 6. Tarcas. 7. Depciidc.iici~s.

109

Sistema Administrador de Estwduras de Datos Complejas Persistentes

r l Fig 2

Sub-spec

El Fig 4 rl Fig 3

Gardener m Task-spec

37 Fig 5

Fig 1

Fig 6

Se pueden crear uno o más diagrama de componentes para mostrar los paquetes de componentes y componentes.

Diagramas de Ejecución.

Un diagrama de ejecución muestra la configuración de los elementos de procesamiento en tiempo de ejecución y los componciites de software. procesos y objetos que se ejecutan en ellos. Instancias de los componentes de sotiware representan manifestaciones de en tiempo de ejecución del código. Componentes que solo sean utilizados en tiempo de compilación deben mostrarse en el diagrama de componentes.

Un diagrama de ejecución contiene:

Procesador. Componentes de hardware capa/ dc cjc~ittrll programas.

110

Sistema Administrador de EStRldllras de Datos Cornpkjas Persistentes

Dispositivos.

Elementos de hardware que no tienen potencia computacionai.

Conexiones.

Representa algun tip de acoplamiento de hardware entre dos entidades, siendo una entidad un procesador y la otra un dispositivo, por ejemplo.

= < " \

111

..

sistema Administrador de Eshuduras de Datos Compieias Persisientes

GLOSARiO

-A- abstracción Las características esenciales que distinguen a una entidad de todas

las demás entidades. Una abstracción define una delimitación relativa a la perspectiva del observador.

Una forma especial de asociación que especifica una relación todo- parte entre el agregado (todo) y una parte que lo compone.

agregación

análisis

arquitectura

asociación

atributo

-B- booleano

-C- cardinalidad

caso de uso

clase

clase abstracta

La parte del proceso de desarrollo cuyo propósito principal es realizar un modelo del dominio del problema. El análisis enfatiza el qué hacer, el diseño en como hacerlo.

La estructura organizacional de un sistema. Una arquitectura puede ser descompuesta recursivamente en: partes que interaciuan entre sí por medio de interfaces, relaciones que conectan las partes, y restricciones para ensamblar las partes.

Una relación que describe un conjunto de vínculos. Puede ser binaria (entre dos clase) o n-aria (entre tres o más clases).

Una propiedad de un tipo, identificada mediante un nombre.

Una enumeración cuyos valores son verdadero o falso.

La cantidad de elementos de un conjunto

Un conjunto que define un conjunto de escenarios, que muestran casos de aplicación, desde el punto de vista de los usuarios del sistema.

La descripción de un conjunto de objetos que comparten los mismos atributos. operaciones, métodos, relaciones y semántica. Una clase es una implenientación de un tipo.

Una clase que no puede ser instanciada directamente.

112

Sistema Mmmstrador de Estniduras de Datos Complejas Persistentes

cliente

componente

concurrencia

-D- DBA

dependencia

diagrama de clases

diagrama de interacciones

-E- evento

un tipo. clase 0 componcnie qiic solicita un servicio de otro tipo, clase o componente.

Un módulo e software ejecutahlc que tiene identidad y una interface bien definida.

La ocurrencia de dos o mác actividades durante el mismo intervalo de tiempo.

Siglas en inglés de Administrador de la.Base de Datos (Database Administrator)

Una relación entre dos elementos del modelo, en la cual si se efectúa un cambio a uno. de los elementos (el elemento independiente) posiblemente afecte al otro elemento.

Un diagrama que muestra una colección de elementos del modelo declarativos (estáticos), como clases y tipos, y sus contenid-s y relaciones.

Un término genérico que se aplica a diversos tipos de diagramas que enfatizan la interacción entre objetos.

Un acontecimiento significativo. Un evento tiene una ubicación en el tiempo y en el espacio y puede tener parámetros.

-G- generalización

-H- herencia

herencia múltiple

-1- implementación

instancia

Una relación taxonómica entre un elemento más general y uno más específico. El elemento más especifico es totalmente consistente con el más general y contiene más información.

El mecanismo por el cual elementos más específicos incorporan la estmctura y el comportamiento de elementos más generales. Una variación semántica de la generalización en la cual un tipo puede tener más de un supertipo.

La definición de cómo está construido o compuesto algo. Por ejemplo. una clase es una implementación de un tipo, un método es una implemeniación de una operación.

Un individuo descrito por una clase o un tipo. De acuerdo con la interpretación estricta del metamodelo un individuo de un tipo es una instancia y un individuo de una clase es un objeto. En un contexto

l í 3

Sistema Administrador de Esbuduras de Datos Camplejas Persistentes

menos formal se usa instancia u objeto para referirse a un individuo de h a clase.

La utilización de un tipo para describir el comportamiento visible de un objeto.

Una comunicación entre objetos que transmite información con la expectativa de desatar una acción. La recepción de un mensaje es considerada normalmente un evento.

interfaz

-M- mensaje

metaclase Una clase cuyas instancias son clases. Las meiaclases son típicamente utilizadas para construir metamodelos.

metamodelo Un modelo que define el lenguaje para expresar un modelo.

miembro

modelo

módulo

-N- nodo

-0- objeto

objeto persistente

operación

-P- paquete

-R- relación

Una paite de un tipo o una clase que denota a un atributo o una operaciih.

Una abstracción semánticamente consistente de un sistema.

Una unidad de manipulación y almacenamiento de un software, incluye: módulos de código fuente, módulos de código binarioo módulos de código ejecutable.

Un nodo es un objeto fisico existente en tiempo de ejecución, que representa un recurso. computacional, que generalmente tiene al menos memoria y habitualmente también capacidad computacional.

Una entidad delimitada precisamente y con identidad, que encapsula estado y comportamiento.

Un objeto que existe más allá del proceso que lo creó.

Un servicio que puede ser requerido a un objeto para producir un componamiento.

Un mecanismo de propósito general para organizar elementos en grupos. Es posible incluir paquetes dentro de paquetes. Un sistema puede pensarse como un paquete de nivel superior, con todo el resto del sistema conienido en él.

Una coiic.uii,ii semántica entre elementos del modelo. La asociación

114

CCC

'eA!iJadsJad ES3 emd SJiWAJ[JJ UOS OU anb SJpep!iUJ Ji!LüO .anb A epep eA!lmdsJad e m apsap epehiasqo sa anb 'oiapotu [ap uo!mañoJd eun

Sistema Administrador de Esmiduras de Datos Complejas Persistentes

REFERENCIAS BIBLIOGRAFICASm

Número Referencia

Object Oriented Database Management System : Concepts and Issues. Elisa Bertino. Universidad de Génova. Lorenzo Martino. Datamont Research and Development Centre. O0 18-9 162/9 1/0400-0033 50 1 .O0 199 1 IEEE April 199 1.

Insight into object-oriented databases s. Khoshafian Vol 32 No. 2 May 1990 Information and S o h a r e Technology 0950-5849/90/010274- I6 I990

Object Oriented Databases. Technology, Applications, and Products. Bindu R. Rao Ed. McGraw-Hill, Inc. United Ststes. 1994

A Framework for Schema Updates In An Object-Oriented database System. Roberto Zicari. GIP Altair. 78153 Le Chesnay Cedex, France and Politecnico di Milano, Milano Italy. 1991, IEEE

How Spacey Can They Get ? Space Overhead for Storage and Indexing with Object-Oriented Databases. Mary Jane Willshire. College of Computing, Georgia Institute of Technology, Atlanta Georgia. 1991, IEEE

ObjectBehavior Diagramas Gerti Kappel. Department of Statistics and Computer Science. University of Vienna. Austria. 1991,IEEE

An Object Oriented Laiiguaje for CAD and Required Database capabilities.

116

Sistema Administrador de Esbuduras de Dalos Complejas Penistentes

8

9

10

11

12

13

14

15

Miguel Gemo. Alejandro P. Buchmann IIMAS-National University, México. 1984 IEEE.

ODMG-93. The Object Database Standard for C t t . Steven Moscowitz. Jornal of Object Oriented Programming. C++ Report, October 1993.

Data Abstraction and Object-Oriented Programming in C++. Keith E. Gorlen. National Institutes of Health.Maryland USA. Ed. John Wiley & Sons. England, 1991

Data Abstraction. The Object-Oriented Approach Using C t t . Joseph Bergm. Ed, McGrawHill International Editions. Computer Science Series. Singapore, 1994.

Introduction to object-oriented databases. A. Garvey and M. S. Jackson. Buttenvorth & Co (Publishers) Ltd. Vol. 31 No. 10 december 1989.

InfoExec : object-orienteasemantic database implementation Balfour and C. Britton. 1990 Butterworth-Heinernann Ltd.

Precomputacion in a Complex Object Environment. Anant Jbingian. IBM TJ Watson Research Center. 1991, IEEE

Panorama de las B&es de Datos Orientadas a Nuevas Aplicaciones. Dra. Lucina Garcia Hernández Universidad de La Habana Cuba.. Memona del Primer Congreso Internacional de Ciencias Computacionales CICC'95, México. Toiuca.

Atkinson, M., Banciihon. F.. DeWitt The object-oriented database system manifiesto. In Proc. of 1" Intemüiioiiai Conference on Deductive and Object Oriented Databases.

Sistema Admnisüadorde EsVUdllras de Datos Campielas Persistemes

~

16

17

18

19

20

21

22

23

24

(DOOD), Kyoto, Japan. December, 1989

Object-Oriented Database Systems Concepts and Architectures International Computer Science Series Addison-Wesley Publishing Company First Printed 1993

Building an OOP Engine Interface Blake Watson. PC Techniques April/May 1993 Vol. 4, No. 1, Canada.

Object Oriented Analysis and Design with aplications Grady Booch The Benjamin Cummings Publishing Company, Inc. Second Edition

Elementos Notacionales de lJML Pablo Figueroa Dirección internet: http:iiw~~w.agamenon.uniandes.edu.co

Un Panorama de las Bases de Datos Orientadas a Objetos Vladimir Estivill Castro Boletín Informático No.4 Soluciones Avanzadas

Glosaio semántico del URL Rational S o h a r e Corporation dirección internet: hap:N~~~~~.baufest.com/umYglosaio.htm

Organización de las bases de datos James Martin Ed. Prentice Hall Internacional.

Concepción y Diseño de Bases de Datos Del modelo E/R al modelo relaciona1 Adoración de Miguel / Mano Piattini U. Addison Wesley Iberoamericana De la edición rama 1993

Simula and ALGOL.- htised simulation languaje Dahl, O-J.' and Nygaard. K. ( I 966). Communications ofilic :\C'M. 9

Sistema Adminismdorde Estniciuras de Datos Complejas Persistentes

25

26

27

28

29

30

31

32

Smalltalk-80. The languaje and'its implementation Goldberg, A., 1983 Reading, MA: Addison-Wesley

C++ Reference Manual Stroustrup, B. (1986). Reading MA: Addison- Wesley

The Common Lisp object-oriented programming languaje standard. Moon, D. A,, 1989 Reading MA: Addison-Wesley

Object Oriented Software Constmction Englewood Cliffs, NJ. Prentice Hall

The role of frame-based representation in reasoning. Fikes, R and Kehler, T. ( 1985) Communications ACM.28

Object-Oriented Database Systems Concepts and Architectures International Computer Science Series Addison- Wesley

A data model and quev language for EXODUS. In Proc. of ACM-SIGMOD International Conference on Management of Data. Chicago IL, May 1988

ENCORE: an object oriented approach to database modeling and querying. Zdonik, S and Mitchell. G. (1991). IEEE Data Engineering. 14

'I

119

9 8 - 0 5 2 2 .

cenidet jose... · sistema administrador de estruduras datos complejas persistentes contenido i 4...

Documents