Desarrollo de una aplicación de generación de scripts de creación de tablas a partir de un diagrama de clases

62 

Loading.... (view fulltext now)

Loading....

Loading....

Loading....

Loading....

Texto completo

(1)ISC-2003-1-25. DESARROLLO DE UNA APLICACIÓN DE GENERACIÓN DE SCRIPTS DE CREACIÓN DE TABLAS A PARTIR DE UN DIAGRAMA DE CLASES. JOSÉ ALEJANDRO MANRIQUE FRAGOSO. UNIVERSIDAD DE LOS ANDES FACULTAD DE INGENIERÍA DEPARTAMENTO DE SISTEMAS Y COMPUTACIÓN BOGOTÁ, D.C. 2003.

(2) ISC-2003-1-25. iv. DESARROLLO DE UNA APLICACIÓN DE GENERACIÓN DE SCRIPTS DE CREACIÓN DE TABLAS A PARTIR DE UN DIAGRAMA DE CLASES. JOSÉ ALEJANDRO MANRIQUE FRAGOSO. Tesis para optar al título de Ingeniero de Sistemas. Asesora: ÁNGELA CRISTINA CARRILLO Ingeniera de Sistemas. UNIVERSIDAD DE LOS ANDES FACULTAD DE INGENIERÍA DEPARTAMENTO DE SISTEMAS Y COMPUTACIÓN BOGOTÁ, D.C. 2003.

(3) ISC-2003-1-25. A toda mi familia por todo el apoyo y cariño, y en especial a mis padres que han procurado darme siempre lo mejor. Y a Toya por su infinito amor que siempre me ha demostrado..

(4) ISC-2003-1-25. AGRADECIMIENTOS. Deseo agradecer a todas aquellas personas que de una u otra forma me ayudaron para realizar esta tesis. En especial a Ángela Carrillo, por su guía y orientación en la elaboración y culminación de este trabajo de grado, y por su infinita paciencia y amabilidad con nosotros sus estudiantes. A Rodrigo Cardozo, Fernando de la Rosa, Maria del Pilar Villamil, y a todos los profesores del departamento de Ingeniería de Sistemas, cuyos aportes a nuestra formación han sido vitales para que seamos unos excelentes profesionales..

(5) ISC-2003-1-25. TABLA DE CONTENIDO. 1. OBJETIVOS ................................................................................................................... 1. 2. ALCANCE ..................................................................................................................... 1. 3. PRODUCTO A REALIZAR .......................................................................................... 1. 4. PRODUCTOS RELACIONADOS EN EL MERCADO ............................................... 2 4.1. COCOBASE ENTERPRISE O/R [1] ..................................................................... 2. 4.1.1. Características Adicionales de CocoBase....................................................... 3. 4.1.2. Precio de CocoBase ........................................................................................ 3. 4.2. THE VISUAL BUSINESS SIGHT FRAMEWORK [2]........................................ 4. 4.2.1. Características ................................................................................................. 5. 4.2.2. Precio de VBSF .............................................................................................. 5. 4.2.3. Tipos de licencia ............................................................................................. 6. 4.3 4.3.1. OBJECT RELATIONAL BRIDGE [3] .................................................................. 8. 4.4. Características ................................................................................................. 8 CONCLUSIÓN....................................................................................................... 8. 5. MOTIVACIÓN............................................................................................................... 9. 6. MODELO DE TRASLACIÓN DE MODELOS ORIENTADOS-OBJETOS A. MODELOS DE DATOS-RELACIONAL ........................................................................... 10 6.1. INTRODUCCIÓN................................................................................................ 10. 6.2. DE UML AL MODELO DE DATOS RELACIONAL ...................................... 11. 6.2.1 6.3. REPRESENTACIÓN LÓGICA DEL DIAGRAMA DE CLASES ............. 12. 7. REPRESENTACIÓN LÓGICA DEL MODELO DE DATOS RELACIONAL. 16. 6.3.1. REGLAS DE MANIPULACIÓN DE DIAGRAMAS DE CLASES ........... 17. 6.3.2. REGLAS DE TRANSPOSICIÓN................................................................ 19. 6.3.3. CONCLUSIONES ........................................................................................ 27. LEVANTAMIENTO DE REQUERIMIENTOS ......................................................... 27 7.1. HERRAMIENTAS Y DESARROLLO ................................................................ 28. 7.2. VISUALIZACIÓN ............................................................................................... 28. 7.3. INTERACCIÓN ................................................................................................... 29.

(6) ISC-2003-1-25. vi. OPERACIÓN ....................................................................................................... 29. 7.5. DESEMPEÑO ...................................................................................................... 30. 7.6. COMPATIBILIDAD............................................................................................ 30. 7.7. ROBUSTEZ Y RECUPERACIÓN DE ERROR ................................................. 32. 7.8. MANTENIBILIDAD ........................................................................................... 32. 7.9. CONTROL DE ACCESO .................................................................................... 33. 8. 7.4. DEFINICIÓN DE LOS CASOS DE USO ................................................................... 34 8.1. DIAGRAMAS DE CASOS DE USO................................................................... 34. 8.2. CASOS DE USO .................................................................................................. 34. 8.3. DIAGRAMA DE CLASES DE DISEÑO ............................................................ 37. 8.4. DIAGRAMAS DE SECUENCIA ........................................................................ 38. 8.4.1 Creación del modelo orientado por objetos formal a partir de un diagrama de clases:............................................................................................................................ 38 8.4.2 Creación del diagrama de datos relacional formal a partir del diagrama orientado por objetos formal:........................................................................................................ 39 8.4.5. Generación de los scripts de creación de tablas a partir de un modelo de. datos relacional formal: ................................................................................................ 39 9. CONSIDERACIONES PARA EL USO DE LA APLICACIÓN................................. 40 9.1. CONSIDERACIONES INICIALES .................................................................... 40. 9.2. CONSIDERACIONES PARA LO SCRIPTS DE CREACIÓN DE TABLAS .... 40. 9.3. EJEMPLO DE UTILIZACIÓN DE LA APLICACIÓN ...................................... 41. 9.4. CONSIDERACIONES PARA FUTUROS DESARROLLOS ............................ 43. 10. CONCLUSIONES .................................................................................................... 44. 11. BIBLIOGRAFÍA ...................................................................................................... 46.

(7) ISC-2003-1-25. vii. LISTA DE TABLAS. TABLA 1. PRECIOS LIC ENCIA BINARIA VBSF ............................................................. 7 TABLA 2. PRECIOS LICENCIA FUENTE VBSF............................................................... 7 TABLA 3. TABLA COMPARATIVA ENTRE HERRAMIENTAS .................................... 8 TABLA 4. CONSTRUCCIÓN DE REGLAS DE TRANSPOSICIÓN............................... 20.

(8) ISC-2003-1-25. viii. LISTA DE FIGURAS FIGURA 1. EJEMPLO DE UN DIAGRAMA DE CLASES DE UML .............................. 14 FIGURA 2. EJEMPLO DE DIAGRAMA DE CLASES ANTES DE LA MANIPULACIÓN DE LA REGLA 2. ........................................................................ 18 FIGURA 3. EJEMPLO DE DIAGRAMA DE CLASES DESPUÉS DE LA MANIPULACIÓN DE LA REGLA 2. ........................................................................ 18 FIGURA 4. EL PROCESO DE INTRODUCIR UNA TABLA ASOCIATIVA ................. 23 FIGURA 6. DIAGRAMA DE CLASE DE DISEÑO. ......................................................... 37 FIGURA 7. DIAGRAMA DE SECUENCIA PARA LA CREACIÓN DEL MODELO ORIENTADO POR OBJETOS. ................................................................................... 38 FIGURA 8. DIAGRAMA DE SECUENCIA DE LA CREACIÓN DEL DIAGRAMA DE DATOS RELACIONAL FORMAL A PARTIR DEL DIAGRAMA DE ORIENTADO POR OBJETOS FORMAL. ......................................................................................... 39 FIGURA 9. DIAGRAMA DE SECUENCIA PARA LA CREACIÓN DE LOS SCRIPT DE CREACIÓN DE TABLAS A PARTIR DE UN MODELO DE DATOS RELACIONAL FORMAL ........................................................................................... 39 FIGURA 10. VENTANA INICIAL DE LA APLICACIÓN. .............................................. 41 FIGURA 11. VENTANA PARA ABRIR EL DIAGRAMA DE CLASES. ........................ 41 FIGURA 12. VENTANA CON EL SCRIPT DE CREACIÓN DE TABLAS..................... 42 FIGURA 13. VENTANA PARA GUARDAR EL SCRIPT DE CREACIÓN DE TABLAS. ...................................................................................................................................... 42 FIGURA 14. DIAGRAMA DE CLASES EJEMPLO.......................................................... 47.

(9) ISC-2003-1-25. ix. LISTA DE ANEXOS ANEXO 1. SECUENCIA DE EJECUCIÓN DE LA APLICACIÓN.................................. 47.

(10) ISC-2003-1-25. DESARROLLO DE UNA APLICACIÓN DE GENERACIÓN DE SCRIPTS DE CREACIÓN DE TABLAS A PARTIR DE UN DIAGRAMA DE CLASES. 1 OBJETIVOS w Desarrollar una aplicación que transforme un modelo orientado-objeto a un modelo de datos relacional. w. Generar a partir del modelo de datos relacional los scripts necesarios para la creación de una base de datos en un Sistema Manejador de Bases de Datos Oracle 8i.. 2 ALCANCE Desarrollar una aplicación que tome un modelo orientado por objetos generado por DIA v9.01 , lo traslade a un modelo de datos relacional y a partir de este modelo, crear un script de generación de tablas a una base de datos Oracle8i.. 3 PRODUCTO A REALIZAR Al final de este trabajo se espera tener un producto, que permita mejorar el desempeño en la construcción de aplicaciones, mediante la traslación automática de un modelo orientado a objetos a un modelo de datos relacional, debido a que muchas de las aplicaciones que se desarrollan en la actualidad tienden a crearse bajo la programación por objetos y la. 1. DIA v9.0, es un programa especializado en la graficación de diagramas estructurados. DIA es un software con licencia GNU. http://www.lysator.liu.se/~alla/dia/dia.html.

(11) ISC-2003-1-25. 2. persistencia se realiza bajo bases de datos relacionales basadas en un modelo de datos relacional.. La aplicación tendrá una interfaz gráfica que permitirá al usuario abrir un modelo orientado a objetos (diagrama de clases en UML) creado en Dia v 0.90 o anteriores. Luego la aplicación procederá a procesar el diagrama de clases y trasladarlo a un modelo orientado por objeto formal, y a su vez realizar la traslación. a un modelo de datos relacional.. Finalmente la aplicación creará un Script de creación de tablas a partir del modelo de datos relacional, mostrando el script gráficamente y con la opción de guardarlo en un archivo.. Si el tiempo lo permite, se intentará extender la lectura de modelos UML a varios formatos, tales como Rational Rose o Poseidón, etc.. 4 PRODUCTOS RELACIONADOS EN EL MERCADO En el mercado actual se encuentran tres productos muy importantes relacionados con la propuesta de la presente Tesis, desarrollados por organizaciones muy importantes tales como el Grupo Jakarta, Cocobase y Objectmatter Inc.. 4.1. COCOBASE ENTERPRISE O/R [1]. CocoBase Enterprise O/R es una aplicación que provee un nivel de traslación dinámica O/R que se sitúa por encima del driver JDBC entre los objetos de la aplicación (a menudo están en un servidor de aplicación) y la base de datos (que usualmente es una base de datos relacional para muchas organizaciones IT). CocoBase administra la persistencia y recupera los datos desde la aplicación a un lugar donde es guardada en la base de datos relacional.. CocoBase toma el código específico de la base de datos y prescribe SQL de los objetos y guarda esta información a un nivel de mapa. De este modo desacopla el objeto de su código interno para adaptarlo a la base de datos. El código específico de la base de datos es.

(12) ISC-2003-1-25. 3. dinámicamente creado en tiempo de ejecución. Esto permite que los objetos sean fácilmente usados una y otra vez. Esta capa dinámica provee una multitud de optimizaciones de desempeño que son fácilmente modificados por el programador para mejorar sus necesidades específicas. Si se está trabajando con clases de Java, Tablas de Datos relacionales y/o Modelos de Objetos CocoBase ofrece las siguientes funcionalidades: w Crea mapas de objetos a tablas, tablas a objetos, objetos existentes con tablas existentes, modelos existentes de objetos que utilizan persistencia transparente, modelo de objetos UML/XML. w Genera código java a partir de plantillas editables, Persistencia Dinámica Transparente, clases persistentes de Java, EJB CMP/BMP Beans de Entidad, Beans de Sesión, JSPs y Servlets. w Realiza el deploy de Clases de Java y/o EJB’s para todos los servidores de Aplicación más populares tal como J2SE/J2EE.. 4.1.1 Características Adicionales de CocoBase w CocoBase Enterprise O/R ofrece un sistema flexible y sofisticado para reunir las necesidades de traslación de modelaje Objetos a Relacional. La herramienta soporta características tales como mapas que se extienden a través de tablas, uno-uno unoMuchos Muchos-Muchos, mapas en subconjuntos de tablas. w CocoBase ofrece un acceso centralizado a la administración de la base de datos permitiendo que la administración de la base de datos se realice desde allí. w La herramienta está escrita completamente en Java permitiendo una alta portabilidad. w Alto nivel de ejecución O/R w Soporta automáticamente todos los tipos de relaciones. Detecta llaves foráneas, bean to bean y bean a relaciones de objetos.. 4.1.2 Precio de CocoBase CocoBase tiene un precio de $US6,000 por desarrollador. Incluye CocoBase Enterprise O/R Runtime, GUI Mapping admin. Tool, CMP Installer, documentación, y un año de.

(13) ISC-2003-1-25. 4. soporte técnico vía e-mail y actualizaciones. Dos años de soporte técnico vía e-mail y actualizaciones: Costo de $US1,250 por cada desarrollador. Todos los precios están sujetos a cambios sin previo aviso. Cocobase entiende por desarrollador a cualquiera que utilice el GUI (interfaz), las herramientas, el API o el Runtime – “Directamente o indirectamente” para utilizar un objeto que tenga acceso directamente o indirectamente a CocoBase Runtime o CocoBase Map durante las etapas iniciales o finales para el despliegue del desarrollo en orden para realizar una función durante el proceso de desarrollo de una nueva lógica. Cada desarrollador requiere una licencia de desarrollador individual por separado.. 4.2. THE VISUAL BUSINESS SIGHT FRAMEWORK [2]. Visual BSF™ (VBSF) aplicación desarrollado completamente en un sistema Java objetorelacional que permite que los objetos en Java sean persistentes en una base de datos relacional. Aunque Java es un lenguaje orientado objeto, las aplicaciones que acceden a bases de datos relacionales deben trabajar con tablas, filas y columnas. Esto es indiferente de cualquier JDBC, o cualquier otra librería que Java use para acceder a una base de datos. Esto tiene un desafortunado efecto colateral de forzar a programador para cambiar entre el modelo de objetos de la aplicación y el modelo de datos relacional.. Porque los objetos de Java no pueden ser directamente salvado o recuperado de una base de datos relacional, los desarrolladores trabajan sobre las aplicaciones en Java que tienen acceso a bases de datos relacionales son forzados a escribir masivas rutinas de conversión para poder usar los dos lenguajes diferentes, SQL y Java, Además, ellos tienen que preocuparse sobre el API del Driver (por ejemplo, JDBC). VBSF sobrelleva la correspondencia de tipo entre objetos de java y bases de datos relacionales resolviendo los complejos problemas envueltos en la traslación. VBSF contiene un motor de traslación objeto/relacional que permite a un programador estar atento sobre el modelo de objetos. Los objetos de Java pueden ser fácilmente salvados y recuperados por un simple llamado de.

(14) ISC-2003-1-25. 5. métodos, tales como update() y get(). Soporta cargar y salvar colecciones de objetos, al igual que búsquedas complejas.. VBSF está compuesto de dos componentes: una herramienta de traslación gráfica (GUI) y soportado por la librería interna que provee los servicios en tiempo de ejecución de la capa de persistencia. La herramienta de traslación permite visualizar la traslación de las clases del negocio a tablas y columnas de la base de datos, y para especificar las relaciones de los objetos. Pueden ser usados para definir el lado del servidor SQL, validar las comprobaciones, y personalizar la configuración de la base de datos. Si es necesario, los modelos pueden también ser definidos o modificados enteramente en código sin el uso de la herramienta. La capa de persistencia puede generar objetos persistentes en una configuración local o en una distribuida.. 4.2.1 Características w Completo Modelaje de Objetos: Parte de la falta de correspondencia de tipos entre los modelo objeto-relacional gira alrededor de las diferentes formas en que las relaciones son mantenidas. En el modelo de datos relacional una fila referencia a una fila en otra tabla mediante llaves. Para recuperar la referencia de una fila en un join en la base de datos debe ser desarrollado. En el modelo de objetos, un objeto puede acceder a otro objeto por referencia directa. VBFS permite mantener el modelo de objetos intacto manteniendo la traslación entre los dos modelos, entonces las relaciones entre objetos puede ser mantenida usando referencias directas. Todos los tres tipos de relaciones uno a uno, uno a muchos, y muchos a muchos son completamente soportados usando referencias directas a objetos. VBFS distingue entre la diferencia entre agregación y asociación y permite recorrer una jerarquía de agregación desde el todo a una parte.. 4.2.2 Precio de VBSF Todos los precios para Visual BSF 3.x son por desarrollador y por aplicación o proyecto. Todos los precios están definidos en dólares Estadounidenses. Una licencia es válida por la vida de un proyecto o aplicación y no puede ser reutilizada cuando un nuevo proyecto o aplicación comienza..

(15) ISC-2003-1-25. 6. Para propósitos de la licencia, un desarrollador es definido como alguien que usa la herramienta de traslación o el API de VBSF directa o indirectamente. El uso Indirecto ocurre cuando se tiene acceso al API dentro de la aplicación en turno que utiliza VBSF para completar sus funciones. Un caso común es cuando se construye una capa de persistencia en la aplicación que envuelve funciones de VBSF. Otro caso común de uso indirecto es cuando el servicio de persistencia está incorporado dentro de los objetos del negocio.. VBSF es también disponible en paquetes de desarrollo y en licencias para organizaciones con descuentos sustanciales. También se ofrecen descuentos para organizaciones educativas sin ánimo de lucro, como también para estudiantes.. 4.2.3 Tipos de licencia VBSF es ofrecida bajo dos modos de licencias: Binarios y fuentes. La licencia Binaria incluye sólo los ejecutables. La licencia Fuente incluye los fuentes y los ejecutables. Una organización puede tener ambos tipos de licencia si lo desea. Por ejemplo, una organización con diez desarrolladores trabajando con VBSF puede destinar a dos desarrolladores para mantener el código de VBSF, y el resto para desarrollar aplicaciones que utilizan los ejecutables personalizados de VBSF. En este caso, la organización deberá comprar dos licencias de Fuente y ocho licencias Binarias.. Licencia Binaria incluye las licencias de redistribución de todos los binarios de VBSF, con la excepción de los binarios de la herramienta de traslación. (maptool2.jar)..

(16) ISC-2003-1-25. 7. Productos de Edición Profesionales. Precio ($US). Nueva Licencia Binaria. 895.00. Licencia de Actualización de v2.x. 295.00. Soporte. y. Mantenimiento. básico. 195.00. anual Soporte y Mantenimiento completo. 345.00. anual TABLA 1. PRECIOS LICENCIA BINARIA VBSF. La licencia Fuente incluye la capa de persistencia y el fuente de la herramienta de traslación para las ediciones Profesional y Enterprise. La licencia Fuente permite las clases binarias resultado de. la compilación y modificación de los archivos fuente para ser. vendidos o redistribuidos dentro o fuera de la organización. Hay que notar que el código fuente y de los binarios de la herramienta de mapeo (maptool2.jar) no puede ser redistribuida. Todas las licencias de los códigos fuentes deben estar explícitamente de acuerdo a los términos de la licencia del código fuente firmando la sección apropiada en la forma de orden.. Producto. Precio ($US). Nueva licencia del código fuente. 3,995.00. Actualización de la licencia de la fuente. 1,995.00. v2.x Mantenimiento y soporte básico anual Mantenimiento anual. y. Soporte. completo. 495.00 695.00. TABLA 2. PRECIOS LICENCIA FUENTE VBSF.

(17) ISC-2003-1-25. 4.3. 8. OBJECT RELATIONAL BRIDGE [3]. Object Relational Bridge (OJB) es una herramienta de traslación Objeto/Relacional que permite la persistencia transparente para objetos de Java contra bases de datos relacionales.. 4.3.1 Características w OJB soporta múltiples APIs de persistencia. w OJB ha sido diseñado para un gran número de aplicaciones, desde sistemas embebidos hasta aplicaciones de clientes orientados multinivel con arquitecturas basadas en J2EE. w OJB utiliza un mapeo Objeto/Relacional basado en XML. El mapeo reside en una capa dinámica de MetaData que puede ser manipulada en tiempo de ejecución a través de un protocolo de Meta Objetos (MOP) para cambiar el comportamiento de la persistencia del Kernel. w Se encuentra actualmente en desarrollo por el grupo Apache.. 4.4. CONCLUSIÓN. A continuación se presenta un cuado comparativo entre las herramientas expuestas y la herramienta que se desea implementar, como objeto de esta propuesta de tesis.. Portabilidad. CocoBase. Visual BSF™. Object Relational Bridge. Completa. Completa. Completa. $US6000 Costos. por desarrollador. Estado. Desarrollado. $US895. desarrollador Desarrollado Es. Mantenimiento. por. No es posible sólo. Gratis. En desarrollo. posible, bajo Si es posible. licencia Fuente Licencia Interfaz Gráfica. Sí. EULA. GNU. Si. Sí. TABLA 3. TABLA COMPARATIVA ENTRE HERRAMIENTAS.

(18) ISC-2003-1-25. 9. 5 MOTIVACIÓN En los proyectos de desarrollo de software,. el punto de partida para poder entender el. sistema a diseñar es generar un diagrama orientado por objetos. Esto se logra utilizando el modelo UML; este modelo describe los objetos que pertenecen al sistema y las relaciones que los objetos tienen entre sí.. Es frecuente que durante el desarrollo de un proyecto se tome la decisión de utilizar un Sistema Manejador de Bases de Datos para el manejo de la persistencia de la información. La dificultad existente en ese momento es la traslación del modelo orientado por objetos, que se ha realizado para poder entender el sistema, a un modelo de datos relacional que es el que se utiliza para poder realizar un diseño de la base de datos necesaria para la realización de la persistencia.. El interés de esta propuesta de Tesis es diseñar una aplicación que tome un modelo orientado por objetos, lo traslade a un modelo de datos relacional para aumentar la eficiencia del desarrollo de software y posteriormente generar un script de creación de tablas tomando como base el modelo de datos relacional.. Después de una intensa búsqueda de software disponible relacionado con el objetivo de esta propuesta, se ha encontrado con productos de alta calidad pero con ciertas restricciones sobre su uso. Algunos productos no son fácilmente accesibles por sus altos costos, como CocoBase y VBFS, y otros porque se encuentran actualmente en desarrollo.. Una de las principales motivaciones es realizar una aplicación libre, la cual pueda ser actualizada o extendida hacia otras funcionalidades. Actualizada a nuevos estándares de modelaje de objetos o de lenguaje SQL para Oracle, o extendida a lenguaje SQL de otras bases de datos como Postgres o MySQL..

(19) ISC-2003-1-25. 6 MODELO. 10. DE. TRASLACIÓN. ORIENTADOS-OBJETOS. A. DE. MODELOS. MODELOS DE. DATOS-. RELACIONAL 6.1. INTRODUCCIÓN. El crecimiento del valor estratégico y la importancia del software, aumenta la necesidad de sistemas integrados que contribuyan a la supresión de las necesidades para tener una vista global y comprensiva sobre los procesos de la concepción del sistema.. UML responde estas inquietudes, proveyendo un conjunto de diagramas que dan la capacidad de modular diferentes perspectivas del sistema, incluyendo el modelo orientado a objetos (Diagrama de Clases).. UML llegó a ser una metodología estándar para el diseño y concepción de los sistemas. Por ello, las herramientas centrales que se encuentran en el mercado están basados en UML.. Las dificultades ocurren cuando se tiene que manejar con sistemas reales que implementan modelos de objetos en paradigmas relacionales debido a que los dos modelos no tienen una transformación de uno al otro, usualmente la implementación llega a ser deficiente o inconsistente.. Actualmente se piensa que el mapeo objeto-relacional es un paso necesario para establecer la forma en que los dos modelos puedan cohabitar. Sin embargo, en la literatura no es posible encontrar análisis sólidos sobre ese modelo de traslación.. Algunos sistemas de. desarrollo proponen sus propias reglas de traslación, pero usualmente no cubre todos los alcances de la expresión del modelo de objetos..

(20) ISC-2003-1-25. 11. El paradigma orientado a objeto está llegando a ser el principal soporte para el modelaje de sistemas, pero infortunadamente las bases de datos orientadas a objetos no progresan en la misma velocidad, haciendo que las bases relacionales el estándar para el almacenamiento de datos.. 6.2. DE UML AL MODELO DE DATOS RELACIONAL. El modelo de lenguaje unificado (UML) es un lenguaje para visualización, especificación, construcción y documentación de los componentes del sistema de software, también para el modelaje de negocios y otros sistemas que no son software. UML representa la colección de las mejores prácticas ingenieriles que han tenido éxito en el modelaje de una gran cantidad de sistemas complejos.. UML, un lenguaje visual de modelaje, no tiene la intención de ser un lenguaje de programación, en el sentido de tener todo el soporte visual y semántico necesarios para remplazar a los lenguajes de programación visuales.. UML es un conjunto de diagramas que provee múltiples perspectivas del sistema bajo el análisis o el desarrollo. El diagrama de clases muestra la estructura estática del modelo, en particular, de las cosas que existen (tales como clases y tipos), su estructura interna y sus relaciones con otras cosas. El estándar UML está definido por una organización independiente, Object Management Group (OMG), y el primer objetivo de OMG fue permitir la Interoperabilidad entre herramientas. UML es usado para el modelaje de objetos debido a que las herramientas más populares lo usan y además es un estándar que está bien establecido y mantenido por OMG.. Las bases de datos relacionales son usadas en lugar de bases de datos orientadas a objetos, debido a que las bases de datos relacionales están bien establecidas. Las bases de datos relaciones son el estándar para el almacenamiento de datos y una de las características que le da la mayor contribución para la importancia de su éxito es que es muy conocido y está.

(21) ISC-2003-1-25. 12. soportada por una teoría matemática. En comparación, las bases de datos orientadas a objetos son inmaduras y tienen muy pocos progresos.. Es posible trasladar el diagrama de clases de UML a. un modelo de datos relacional. correspondiente. Para alcanzar este objetivo se debe establecer una representación formal para los dos y un conjunto de reglas que deben ser seguida para trasladar un diagrama de clases en un modelo de datos relacional.. Una combinación efectiva de UML y bases de datos relacionales permite la verdadera compleja traslación Objeto/Relacional en momento del diseño. La traslación en el momento del diseño asegura que el código del acceso de los datos del sistema, que se trabajen con objetos y bases de datos está bien estructurada. Inconsistencias que son descubiertas en el momento del desarrollo, son más difíciles y costosas de arreglar.. Para comenzar es necesario representar y formalizar cada modelo. Se decidió utilizar el cálculo de predicados. Las razones principales para tomar esta decisión están basados sobre las características principales de la lógica matemática, tales como la universalidad, la flexibilidad y la expresividad.. Teniendo una formal representación de los dos modelos es posible establecer un conjunto de reglas lógicas para trasladar de un modelo a otro.. 6.2.1 REPRESENTACIÓN LÓGICA DEL DIAGRAMA DE CLASES El primer paso en orden para construir un modelo de datos relacional crear una lógica representación del diagrama de clases de UML. Esto implica la existencia de una conceptualización lógica del Universo (el diagrama de clases). El modelo de la conceptualización es descrita por la tupla: M = {D, R}. En donde D para el universo en discurso, significado de los objetos del dominio en que el conocimiento es expresado:.

(22) ISC-2003-1-25. 13. R es el conjunto de relaciones a través de cómo los objetos interactúan.. D = { todas las expresiones comienzan por pequeñas capas } R = { Clases(cl), Asociacion(as), Generalizacion(g), Agregacion(ag), Composicion(comp), MiembroAsociacion(as, cl, role, lower_mult, upper_mult), Atributo(cl, at), AtributoID(g, cl) Especificación(g, cl), ParteAgregación(ag, cl), ParteComposición(comp, cl), ClaseAsociativa(asc) }. Clases(cl), esta relación enumera todas las clases. Asociacion(as), esta relación enumera todas las asociaciones. Generalizacion(g), esta relación enumera todas las generalizaciones, Agregacion(ag), esta relación enumera todas las agregaciones, Composición (comp), esta relación enumera todos las composiciones, MiembroAsociacion(as, cl, role, lower_mult, upper_mult), relaciona las. Clases(cl),. con. las. asociacion(as). que. tienen. un. role(role). y. multiplicidad. (lower_mult...upper_mult), donde lower_mult es el límite inferior y upper_mult es el limite superior. Atributo(cl, at), asocia una tributo (at) a una clase (cl). AtributoID(cl, at), asocial los atributos a las clases que ellos identifican. Especificacion(g,. cl), socia la clase que es un caso particular de la. Generalización (g) respectiva. ParteAgregacion(ag,x,lower_mult, envueltas en la agregación.. upper_mult), asocial las clases.

(23) ISC-2003-1-25. 14. ParteComposicion(comp, cl, lower_mult, upper_mult), asocia las clases envueltas en una composición (comp.). ClaseAsociativa(asc), enumera las clases que son simultáneamente clases y asociaciones.. Una clase asociativa es una asociación con propiedades de clase (o una clase con propiedades de clases). Una clase asociativa es simplemente una asociación con atributos, que significa que la representación de una Clase de Asociación es representada también como una clase y una relación de asociación. Los atributos de la Clase de Asociación son representados como los atributos de las clases correspondientes.. A continuación es presentado un diagrama de clases en UML para la explicación de las reglas y una mejor comprensión de las mismas:. FIGURA 1. EJEMPLO DE UN DIAGRAMA DE CLASES DE UML. Este ejemplo es conceptualizado al modelo orientado objetos formal a continuación:.

(24) ISC-2003-1-25. Clase(Compania) AtributoID(Compania, comp_nombre). Clase(Producto) AtributoID(Producto, producto_ID) Atributo(Producto, nombre) Atributo(Producto, precio). Clase(Departamento) AtributoID(Departamento, dep_ID) Atributo(Departamento, nombre) Atributo(Departamento, ubicación) Clase(Productos_plasticos) Atributo(Productos_plasticos, tipo_plastico). Clase(Productos_metalicos) Atributo(Productos_metalicos, tipo_metal). Clase(persona) AtributoID(persona, persona_ID) Atributo(persona, nombre). Clase(direccion) AtributoID(direccion, direccion_ID) Atributo(direccion, calle) Atributo(direccion, pais) Atributo(direccion, ciudad) Atributo(direccion, cod_postal). Clase(labor) Atributo(labor, labor_nombre) Atributo(labor, salario) Agregacion(Compania) ParteAgregacion(Compania, Departamento, 1,*) Composición(Persona). 15.

(25) ISC-2003-1-25. 16. ParteComposicion(persona, direccion, 1,*) Asociacion(labor) MiembroAsociacion(labor, Compania, empleado, 0,*) MiembroAsociacion(labor, Persona, empleado, 1,*) Asociacion(dirige) MiembroAsociacion(dirige, labor, jefe, 0,1) MiembroAsociacion(dirige, jefe, trabajador, 1,*) MiembroAsociacion(produce, Compania, hace, 1, 1) MiembroAsociacion(produce, Producto, hecho, 0,*) Generalización(Producto) Especificación(Producto, Productos_plastico) Especificación(producto, Productos_metalico. 6.3 REPRESENTACIÓN LÓGICA DEL MODELO DE DATOS RELACIONAL El segundo paso es para usar la lógica para representación del modelo para realizar la traslación. El modelo de datos relacional es descrito por la tupla: MR = { DMR, RMR }. En el que DMR, representa el universo en discurso, esto es, los objetos del dominio sobre el cual el conocimiento es expresado. RMR es el conjunto de relaciones a través de los cuales los objetos interactúan.. DMR = { todas las expresiones comienzan por pequeñas capas } RMR = { Tabla(tb), Columna(tb, col), Llave(tb, k), LlaveForanea(fk, tbo, tbd), MiembroFK(fk, co) }.

(26) ISC-2003-1-25. 17. Tabla(tb), esta relación enumera todas las tablas, Columna(tb, co), asocia una columna (co) con una tabla (tb), Llave(tb, k), asocia el atributo con la llave que identifica la tabla, LlaveForanea(fk, tbo, tbd), asocia las tablas con las relaciones entre ellos. MiembroFk(fk, co), asocia las relaciones con los atributos que lo implementan.. 6.3.1 REGLAS DE MANIPULACIÓN DE DIAGRAMAS DE CLASES Estos axiomas presentados en esta sección intentan realizar la transposición entre los dos modelos más fácilmente. Ellos hacen algunos cambios a los diagramas de clases UML, haciendo el proceso de transposición más fácil, sin alterar su semántica. Los siguientes axiomas ayudan este objetivo.. Como se verá más adelante, las asociaciones "uno a muchos” no originan tablas, incluyendo asociaciones con atributos (clases asociativas). En el último caso, el proceso de transposición puede llegar a ser difícil si la clase asociativa está envuelta en otras asociaciones. El hecho que ellos no originan tablas se debe al desplazamiento de los roles que juegue esta clase para otras clases.. REGLA 1: todas las clases que son una asociación son denominadas clases asociativas. ∀x (Class ( x) ∧ Asociacion ( x) ⇔ ClaseAsoci ativa( x)). REGLA 2: todas las clases asociativas en que una de los participantes como “0..1” o “1..1” de la multiplicidad, transfiere sus atributos y roles en sus asociaciones para las clases que participan en esas asociaciones (solo aquella que participa con una multiplicidad mayor que uno (1)). ∀a(∀x(∀b(∀r(∀lm(∀um(∀lm1(∀um1(∀at( ClaseAsociativa(a) ∧ MiembroAsociativo(a,x,r,lm,um) ∧um>1∧ ∃y(MiembroAsociativo(a,y,r1,lm1,um1) ∧um1=1∧ Atributo(a, at) ⇒ Atributo(x, at)))))))))).

(27) ISC-2003-1-25. 18. Ejemplo de un diagrama de clases, antes de la REGLA 2:. FIGURA 2. EJEMPLO DE DIAGRAMA DE CLASES ANTES DE LA MANIPULACIÓN DE LA REGLA 2.. Después de la REGLA 2:. FIGURA 3. EJEMPLO DE DIAGRAMA DE CLASES DESPUÉS DE LA MANIPULACIÓN DE LA REGLA 2.. REGLA 3: todas las clases asociativas que no están incluidas en el axioma anterior tienen como identificación atributos el conjunto de identificación de atributos todas las clases que participan en la asociación. ∀a(∀x(∀b(∀r(∀lm(∀um(∀r1(∀um1(∀r2(∀lm2(∀um2( ClaseAsociativa(a) ∧MiembroAsociativo(a,x,r,lm,um) ∧um>1∧ ∃y(MiembroAsociativo(a,y,r1,lm1,um1) ∧um1=1∧ MiembroAsociacion(b,a,r2,lm2,um2) ⇒ MiembroAsociacion(b,x,r2,lm2,um2)))))))))))). Aplicando esta regla al ejemplo de diagramas de clase en la figura 1, se tiene:.

(28) ISC-2003-1-25. 19. ClaseAsociacion(labor) AtributoID (labor, Labor, comp_nombre) AtributoID (labor, persona_ID). 6.3.2 REGLAS DE TRANSPOSICIÓN Las reglas de transposición tienen el propósito de expresar un conjunto de reglas que realizan la transposición entre el diagrama de clases y el modelo de datos relacional. El uso de estas reglas será la base para la creación del modelo de datos relacional basado en la conceptualización lógica del diagrama de clases.. Las reglas de transposición están divididas en dos clases: w Las reglas de construcción, que son el conjunto de reglas básicas que implementan la trasposición entre los dos modelos. w Las reglas que son definidas por el usuario, haciendo posible para el usuario controlar el proceso, adaptándolo en orden para cubrir sus necesidades.. Las reglas de construcción son un conjunto de reglas predefinidas que no pueden ser manipuladas por el diseñador del proceso. Antes de comenzar la enumeración de las reglas, es necesario introducir dos conceptos que se usarán a menudo para explicar la semántica de las reglas, ellos son: la relación de identidad y la relación de no-identidad.. La relación de identidad es una relación entre dos tablas dependientes, en donde una tabla hijo no puede existir sin la tabla padre. La llave primaria de la tabla padre llega a ser parte de la llave primaria de la tabla hijo y es una llave foránea de la tabla hijo.. La relación de no-identidad representa la relación entre dos tablas independientes. La columna de la llave foránea no participa en la llave de la tabla hijo..

(29) ISC-2003-1-25. 20. La tabla 3 define una secuencia de pasos para trasladar un Diagrama de Clases de UML en un Modelo de Datos Relacional:. Regla. Descripción. 1. Traslada las clases y asociaciones de muchos-a-muchos a tablas.. 2. Traslada atributos a columnas.. 3. Traslada identificadores de clases a llaves de tablas.. 4. Generar relaciones de identidad a tablas originados por asociaciones de muchos a muchos y clases asociativas. 5. Trasladar asociaciones uno a muchos a relaciones de no-identidad.. 6. Traslación de Generalización a relaciones de identidad.. 7. Traslación de agregación por referencia a relaciones de noidentidad.. 8. Traslación de agregación compuesta a relaciones de identidad. TABLA 4. CONSTRUCCIÓN DE REGLAS DE TRANSPOSICIÓN.. Regla 1: Trasladar clases y asociaciones de muchos a muchos en tablas Cada clase y asociación de muchos a muchos se traslada a una tabla.. Para implementar esto se necesitan dos axiomas: Las clases, excluyendo aquellas que son clases asociativas, se trasladan a tablas:. ∀x (Clase (x ) ∧ ¬ClaseAsoci ativa( x ) ⇒ Tabla ( x )). Las asociaciones de muchos-a-muchos, incluyendo aquellas que son clases asociativas, se trasladan a tablas asociativas; el nombre de la tabla será el nombre de la asociación.. ∀x (∀r (∀lm(∀um( Asociacion ( x ) ∧ ¬∃z ( MiembroAsociacion ( x, z, r , lm, um) ∧ um ≡ 1) ⇒ Tabla ( x ))))) Esta tabla asociativa es necesaria porque en modelo de datos relacional no permite las relaciones muchos-a-muchos. Una tabla asociativa es un dato de entidad donde su único propósito es mantener la asociación entre dos o mas tablas en una base de datos relacional. Esas relaciones entre tablas serán creadas en la regla número cuatro..

(30) ISC-2003-1-25. 21. Aplicando la Regla 1 al ejemplo propuesto (ver figura 1) se obtiene:. Tabla (Compania) Tabla (Departamento) Tabla (Producto) Tabla (Persona) Tabla (Direccion) Tabla (Productos_plasticos) Tabla (Productos_metalicos) Tabla (Labor). Regla 2: Trasladar atributos a columnas Los atributos de las clases y las clases asociativa, que originaron las tablas, se trasladan a columnas de las tablas relacionadas. Traslación de los atributos de las clases:. ∀x (∀y (Clase( x ) ∧ ¬ClaseAsoci ativa( x ) ∧ Atributo( x, y ) ⇒ Columna( x, y ))). Traslación de los atributos de las clases asociativas, se deben excluir las asociaciones que no originan tablas: ∀x(∀a(∀r(∀lm(∀um( ClaseAsociacion(x) ∧¬∃z(MiembreoAsociacion(x,z,r,lm,um) ∧um=1)∧ Atributo(x,a) ⇒ Columna(x,a))))). Estas reglas sólo trasladan atributos que no son parte de los identificadores de Clases. Estas últimas serán trasladadas por la siguiente regla.. Usando el ejemplo previo, y aplicando la Regla 2, se tiene: Columna (Persona, nombre) Columna (Labor, labor_nombre) Columna (Labor, salario).

(31) ISC-2003-1-25. 22. Columna (Departamento, nombre) Columna (Departamento, ubicacion) Columna (Direccion, calle) Columna (Direccion, pais) Columna (Direccion, cod_postal) Columna (Direccion, ciudad) Columna (Producto, nombre) Columna (Producto, precio) Columna (Productos_plasticos,. tipo). Columna (Productos_metalicos, tipo). Regla 3:Traslación de Identificadores de Clases a Llaves de Tablas Todos los atributos que son parte de los identificadores de clases, serán trasladados a llaves primarias de columnas de la tabla asociada:. ∀x (∀y (Clase( x ) ∧ ¬ClaseAsociacion ( x ) ∧ AtributoID( x, y ) ⇒ Columna( x, y ) ∧ Llave( x, y ))). Utilizando el ejemplo propuesto, y aplicando la Regla 3, se obtiene: Llave (Persona, persona_ID) Llave (Compania, comp_nombre) Llave (Producto, producto_ID) Llave (Departamento, dep_ID) Llave (Direccion, direccion_ID). Regla 4: Generar las relaciones de identidad a tablas originadas por asociaciones de muchos-a-muchos y clases asociativas Por la regla 1, las clases asociativas se trasladaron a tablas asociativas. Además se necesitan generar las relaciones ( llaves y llaves foráneas).. Paso Uno – La Llave: La llave de tabla asociativa será la combinación de las llaves en las tablas envueltas en la relación..

(32) ISC-2003-1-25. 23. Paso Dos – Las llaves foráneas: La regla usada para generar las relaciones es descrita en el siguiente diagrama: M. A. 1. N. N. M. B. 1. Tabla. A. B. asociati. FIGURA 4. EL PROCESO DE INTRODUCIR UNA TABLA ASOCIATIVA. La tabla de asociación divide la asociación muchos a muchos (no soportada en el modelo de datos relacional) en dos relaciones uno-dos-muchos (soportadas por el modelo de datos relacional) usando relaciones de identidad. Para mantener la semántica es necesario implementar una llave foránea por cada tabla envuelta en la relación. ∀a(∀x(∀r1(∀lm1(∀um1(∀r(∀lm(∀um( Clase(x)∧ Asociacion(a) ∧MiembroAsociacion(a,x,r1,lm1,um1) ∧um1>1∧ ¬∃z(MiembreoAsociacion(a,z,r,lm,um) ∧um=1) ⇒ LlaveForanea(r1,a,x)))))))) ∀a(∀x(∀r1(∀lm1(∀um1(∀r(∀lm(∀um(∀at( Clase(x)∧ Asociacion(a) ∧MiembroAsociacion(a,x,r1,lm1,um1) ∧um1>1∧ ¬∃z(MiembreoAsociacion(a,z,r,lm,um) ∧um=1) ∧ AtributoID(x,at) ⇒ Columna(a,at) ∧Llave(a,at) ∧MiembroFK(r1,at))))))))). Utilizando el ejemplo propuesto y aplicando la Regla 4, se tiene: Columna(Labor, jefe) Columna(Labor, comp_nombre) Llave(Labor, persona_ID).

(33) ISC-2003-1-25. 24. Llave(Labor, comp_nombre) LlaveForanea (empleado, Labor, Persona) LlaveForanea (empleador, Labor, compania) MiembroFK (empleado, persona_ID) MiembroFK (empleador, comp_nombre). Regla 5: Traslación de las asociaciones de uno a muchos a relaciones de no-identidad. Cada instancia del lado muchos necesita una asociación a exactamente una instancia del lado Uno. Una llave foránea es generada para construir la relación. Los atributos que implementan el identificador de la clase en el lado muchos, generarán columnas en la tabla de asociación con la clase del lado uno. El rol de estas columnas es implementar las llaves foráneas. Eso pasa porque en el paso anterior se estableció la relación y ahora es necesario especificar las columnas que lo implementan.. Usando el ejemplo previo y aplicando la Regla 5, se obtiene:. Columna (Labor, comp_nombre) Columna (Labor, persona_ID) LlaveForanea(jefe, Labor, Labor) MiembroFK(jefe, comp_name) MiembroFK(jefe, persona_ID) Columna(Producto,comp_name) LlaveForanea (hecho, Producto, Compania) MiembroFK (hecho, comp_name). Regla 6: Traslación de Generalización a relaciones de identidad La traslación de la generalización en una tabla por clase, cada clase da lugar a una tabla. La tabla padre es unida a cada una de las tablas hijo por una relación de identidad. Además, cada tabla hijo contiene una llave primaria/foránea relacionada a la llave primaria de la tabla padre..

(34) ISC-2003-1-25. 25. ∀g (∀x (Generaliza cion (g ) ∧ Especifica cion( g , x ) ⇒ LlaveForanea (concat ( x, g , ' _ FK '), x, g ))) ∀g(∀x( Generalización(g) ∧Especificacion(g,x) ∧ AtributoID(g,y) ⇒Columna(x,y) ∧Llave(g,y) ∧MiembroFK(concat(x,g,’_FK’), y)))). Utilizando el ejemplo y aplicando la Regla 6, se obtiene: Columna (Productos_metalicos, producto_ID) Llave (Productos_metalicos, producto_ID) LlaveForanea. (productos_metalicos_producto_FK,. Productos_metalicos, Producto) Columna (Productos_plasticos, producto_ID) Llave (Productos_plasticos, producto_ID) LlaveForanea Productos_plasticos, Producto). (productos_plasticos_producto_FK,.

(35) ISC-2003-1-25. 26. Regla 7: Traslación de agregación por referencia a relaciones de no-identidad Traslación de la agregación por referencia (conocida como agregación) a relaciones de noidentidad. La agregación es usada cuando se tienen múltiples instancias de una clase padre que posee clases dependientes. Una agregación es el rey de la asociación donde una clase padre es requerida por el uso de una multiplicidad “1..N”. La diferencia entre asociación y agregación es cuan listo esta los objetos limitados a cada uno entre sí. Para implementar esta relación la llave primaria de la tabla de agregación migra a las tablas de agregación de partas como llaves foráneas.. ∀a (∀b( Agregacion(a ) ∧ ParteAgregacion (a, b ) ⇒ LlaveForanea(b, b, a )))    Agregacion (a ) ∧ ParteAggregacion (a, b) ∧ AtributoID (a, x ) ⇒       ∀a ∀b ∀x   Columna ( b , x ) , MiembroFK ( b , x )      . Usando el ejemplo y aplicando la Regla 7, se obtiene:. LlaveForanea (departamento, Departamento, Compania) Columna (Departamento, comp_nombre) MiembroFK. (Departamento, comp_nombre). Regla 8: Traslación de agregación compuesta a relaciones de identidad La agregación compuesta consiste de un todo y una parte, donde la parte no puede existir sin el todo. La llave primaria de la tabla de Composición migra a la tabla de ComposiciónParte como llave foránea y también como llave primaria – relación de identidad.. ∀a (∀b(Composicion(a ) ∧ ParteComposicion (a, b) ⇒ LlaveForanea(b, b, a )))    Composicion(a ) ∧ ParteComposicion (a, b) ∧ AtributoID (a, x ) ⇒       ∀a ∀b ∀x   Columna ( b , x ) ∧ Llave ( b , x ) ∧ MiembroFK ( b , x )      .

(36) ISC-2003-1-25. 27. Usando el ejemplo propuesto y aplicando la Regla 8, se obtiene:. LlaveForanea(direccion, Direccion, Compania) Columna (Direccion, persona_ID) Llave (Direccion, persona_ID) MiembroFk (direccion, persona_ID). 6.3.3 CONCLUSIONES La expresividad de la lógica formal permite definir fácilmente un conjunto de reglas de traslación entre el modelo orientado a objetos y modelos relacionales. Estas reglas pueden ser enriquecidas con un conjunto de reglas específicas que expresan las preferencias del diseñador. La lógica representación relacional puede ser fácilmente trasladada a otros lenguajes, tales como, SQL, XML, etc.. 7 LEVANTAMIENTO DE REQUERIMIENTOS Los requerimientos son una descripción de las necesidades o deseos de un producto. La meta primaria de la fase de requerimientos es identificar y documentar lo que en realidad se necesita, en una forma que claramente se lo comunique al cliente. El reto consiste en definirlos de manera inequívoca, de modo que se detecten los riesgos y no se presenten sorpresas al momento de entregar el producto[5].. Es por ello que se definen a continuación los siguientes requerimientos funcionales y no funcionales..

(37) ISC-2003-1-25. 7.1. 28. HERRAMIENTAS Y DESARROLLO. IDENTIFICADOR:. NOMBRE:. 1.0. Plataforma de desarrollo. Descripción: La plataforma que se empleará para el desarrollo de esta tesis será Windows. CRITERIOS DE ACEPTACIÓN Cualquier versión de Windows tales como 98, Me, XP y 2000. IDENTIFICADOR:. NOMBRE:. 1.1. Lenguaje de programación.. Descripción: El lenguaje de programación que se utilizará para el desarrollo de esta aplicación será Java JDK 1.4.1. CRITERIOS DE ACEPTACIÓN Ejecución de la aplicación en una versión de JDK 1.4.1 o superior.. 7.2. VISUALIZACIÓN. IDENTIFICADOR:. NOMBRE:. 2.1. Interfaz. Descripción: Se proveerá al usuario final una interfaz provista de ventanas para la visualización de la aplicación CRITERIOS DE ACEPTACIÓN La aplicación será implementada con Frames, que permite crear ventanas durante su ejecución..

(38) ISC-2003-1-25. 7.3. 29. INTERACCIÓN. IDENTIFICADOR:. NOMBRE:. 3.1. Interacción. Descripción: w. La interacción del usuario con la aplicación se desarrollará de la siguiente forma:. w. El usuario escogerá la opción de cargar el archivo, con formato DIA v9.0, con el diagrama de clases, para crear el modelo orientado por objeto formal. La aplicación realizará la traslación del modelo orientado por objeto formal al modelo de datos relacional formal.. w. Finalmente, el sistema mostrará gráficamente el script de creación de tablas, a partir del modelo de datos relacional formal ya existente, con la opción de guardar el script en un archivo.. CRITERIOS DE ACEPTACIÓN Debido a que la interfaz es de ventanas, la interacción de la aplicación con el usuario final se realizará a través del teclado y del mouse.. 7.4. OPERACIÓN. IDENTIFICADOR:. NOMBRE:. 4.1. Operación. Descripción: Se dará la opción al usuario de poder abrir el archivo con el diagrama de clases y luego de guardar el script de creación de tablas en un archivo. CRITERIOS DE ACEPTACIÓN El usuario podrá realizar la creación de tablas a partir del archivo que contiene el script..

(39) ISC-2003-1-25. 7.5. 30. DESEMPEÑO. IDENTIFICADOR:. NOMBRE:. 5.1. Desempeño. Descripción: Se intentará optimizar la aplicación al máximo logrando tiempos de respuestas muy pequeños, se limitará la creación del modelo orientado por objetos, un tiempo de traslación entre modelos, y la generación de los scripts de creación de tablas. CRITERIOS DE ACEPTACIÓN. Se diseñarán pruebas detalladas que permitan validar el óptimo desempeño de la aplicación, ya sea por tiempos estimados por número de clases o tiempo global de ejecución.. 7.6. COMPATIBILIDAD. IDENTIFICADOR:. NOMBRE:. 6.1. Formato del archivo de entrada. Descripción: El archivo que contiene el diagrama de clases inicial debe estar en el formato que genera DIA v9.0. CRITERIOS DE ACEPTACIÓN. El archivo DIA v9.0 debe ser un diagrama de clases, y no otro modelo..

(40) ISC-2003-1-25. 31. IDENTIFICADOR:. NOMBRE:. 6.2. Formato del archivo de salida. Descripción: El archivo que se guarda con el script de generación de tablas al final de utilizar la aplicación será de texto plano.. El formato a utilizar será: w Una línea por cada definición de tablas w Dentro de la definición de la tabla una línea por definición de cada columna de la tala w Una línea por cada definición de llaves dentro de la definición de una tabla. w Entre cada definición de tabla una línea vacía. w Si es necesario, una línea por cada definición de índices.. Los scripts de creación de tablas se realizará con base al estándar SQL92, y dirigido a un Sistema Manejador de Bases de Datos Oracle8i. CRITERIOS DE ACEPTACIÓN. El script podrá ser ejecutado directamente sobre un sistema manejador de bases de datos Oracle8i, y se crearán las tablas que se describen en el script de creación de tablas..

(41) ISC-2003-1-25. 7.7. 32. ROBUSTEZ Y RECUPERACIÓN DE ERROR. IDENTIFICADOR:. NOMBRE:. 7.1. Manejo de errores. Descripción: En el momento en el que se generé un error durante la ejecución de la aplicación, la aplicación continuará su ejecución y mostrará al usuario por medio de una ventana gráfica el tipo de error que ocurrió, junto con una pequeña descripción del error. Existirán 3 tipos de errores principales: w El formato del archivo que contiene el diagrama de clases no tiene formato DIA. w No existe un diagrama orientado a objetos formal válido, para su traslación a un diagrama de datos relacional. w No existe un diagrama de datos relacional válido, para la generación de scripts de creación de tablas. CRITERIOS DE ACEPTACIÓN. Se mostrará una ventana con el error y su descripción, y la aplicación seguirá en su ejecución normal.. 7.8. MANTENIBILIDAD. IDENTIFICADOR:. NOMBRE:. 8.1. Estándares de documentación. Descripción: La metodología para el desarrollo de la aplicación será UML: La estructura interna de los archivos fuentes será documentada con Javadoc, para una mayor mantenibilidad. CRITERIOS DE ACEPTACIÓN. Se hará revisión periódica de los formatos de los documentos Javadoc, verificando su consistencia..

(42) ISC-2003-1-25. 33. IDENTIFICADOR:. NOMBRE:. 8.2. Capas de desarrollo. Descripción: La aplicación estará soportada por tres capas, una capa externa que es la de visualización, una capa con la lógica de la aplicación, y por último, una capa que se encarga del manejo con fuentes externas a la aplicación (archivos, bases de datos, etc.). CRITERIOS DE ACEPTACIÓN. w Para validar la capa de visualización se tendrá en cuenta si la aplicación muestra el diagrama de clases. w Para validar la capa de manejo de fuentes externas y la de lógica, primero la visualización del diagrama de clases, ya que con eso se verifica que se esta leyendo el archivo generado por DIA y además el modelo lógico para la carga del diagrama se ejecuta satisfactoriamente, y por último al momento de crear los scripts de creación de tablas se valida que el modelo está realizando la traslación de forma normal y la capa de fuentes externas esta creando el archivo de creación de tablas. w Igualmente, durante el ciclo de desarrollo se hará revisión de integración de capas.. 7.9. CONTROL DE ACCESO. IDENTIFICADOR:. NOMBRE:. 9.1. Control de acceso. Descripción: La aplicación no tendrá control de acceso de ningún tipo. CRITERIOS DE ACEPTACIÓN. El usuario podrá acceder a la ejecución de la aplicación si la aplicación es ejecutada sobre un sistema operativo windowsm, y además posee un JDK 1.4.1 o superior..

(43) ISC-2003-1-25. 34. 8 DEFINICIÓN DE LOS CASOS DE USO A continuación se describen clara y concisamente los casos de uso que definen las acciones que la aplicación debe realizar.. 8.1. DIAGRAMAS DE CASOS DE USO. FIGURA 5. DIAGRAMA DE CASO DE USO. 8.2. CASOS DE USO. Nombre Caso de Uso:. Traslación de un diagrama de clases expresado en UML a un modelo orientado a objetos formal. Iteración:. Filled El usuario al abrir en la aplicación un archivo con el diagrama de. Resumen:. clases, con formato de DIA v9.0, la aplicación traslada el diagrama de clases a un modelo orientado por objetos formal. Este caso de uso comienza cuando un usuario decide abrir el diagrama de clases en UML, que se encuentra en formato de DIA. Curso Eventos:. Básico v9.0. El sistema procede a abrir el archivo, y lee la información contenida en el archivo. Luego, realiza la transformación del diagrama de clases a un modelo orientado a objetos formal..

(44) ISC-2003-1-25. 35. modelo orientado a objetos formal. Por ultimo, grafica el diagrama de clases. Si no existe el archivo con el diagrama de clases se produce un Caminos. de error.. Excepción:. Si el formato que se intenta abrir no es el de DIA v9.0, se produce una excepción.. Puntos de Extensión: A solicitud del usuario. Triggers:. El archivo está en el formato que DIA v9.0 solicita, es decir es un. Suposiciones:. diagrama de clases válido. El archivo que contiene el diagrama de clases tiene el formato. Pre-condiciones:. generado por DIA v9.0. Se genera el modelo conceptual formal en la aplicación y se. Post- Condiciones:. grafica el diagrama de clases en la aplicación.. Nombre Caso de Uso:. Creación de un modelo de datos relacional formal a partir de un modelo orientado por objetos formal. Iteración:. Filled A petición de usuario la aplicación crea el modelo de datos. Resumen:. relacional formal a partir de la traslación. del modelo orientado. por objetos formal. Este caso de uso comienza cuando un usuario decide transformar el diagrama de orientado por objetos a un diagrama de objetos Curso Eventos:. Básico relacional. El sistema procede a tomar el modelo orientado a objetos formal, lo traslada a un modelo de datos relacional formal. Luego, la aplicación visualiza el diagrama de objetos relacional.. Caminos. de Si no se encuentra el modelo orientado por objetos formal se.

(45) ISC-2003-1-25. 36. Excepción:. genera una excepción.. Puntos de Extensión: A solicitud del Triggers:. usuario o cuando se invoque algún método de. ejecución directa de creación de scripts de creación de tablas al momento de realizar la lectura de un diagrama de clases.. Suposiciones:. Existe un modelo orientado por objetos formal válido.. Pre-condiciones:. La aplicación contiene un modelo orientado por objetos formal La generación de un modelo de datos. Post- Condiciones:. relacional formal y la. graficación de este modelo.. Nombre Caso de Uso:. Generación de los scripts de creación de tablas a partir de un modelo de datos relacional formal. Iteración:. Filled A petición de usuario la aplicación crea el modelo de datos. Resumen:. relacional formal a partir de la traslación del modelo de datos relacional formal. w Este caso de uso comienza cuando un usuario decide crear los scripts de creación de tablas, a partir del diagrama relacional. Curso. Básico. Eventos:. que se muestra en la aplicación. w El sistema procede a tomar el modelo de datos relacional formal, y crea el script de creación de tablas. w Y finalmente muestra el script en la aplicación. Caminos Excepción:. de Si no se encuentra el modelo de datos relacional se genera una excepción.. Puntos de Extensión: A solicitud del. usuario o cuando se invoque algún método de. ejecución directa de creación de scripts de creación de tablas al Triggers:. momento de realizar la ejecución directa de la creación de un diagrama de datos relacional formal o la lectura de un diagrama de clases.. Suposiciones:. Existe un modelo de datos relacional válido..

(46) ISC-2003-1-25. Pre-condiciones: Post- Condiciones:. 8.3. 37. La aplicación contiene un modelo de datos relacional formal La generación de un scripts de creación de tablas para una base de datos Oracle.. DIAGRAMA DE CLASES DE DISEÑO. A continuación se presenta el diagrama de diseño propuesto:. FIGURA 6. DIAGRAMA DE CLASE DE DISEÑO..

(47) ISC-2003-1-25. 8.4. 38. DIAGRAMAS DE SECUENCIA. 8.4.1 Creación del modelo orientado por objetos formal a partir de un diagrama de clases:. FIGURA 7. DIAGRAMA DE SECUENCIA PARA LA CREACIÓN DEL MODELO ORIENTADO POR OBJETOS..

(48) ISC-2003-1-25. 39. 8.4.2 Creación del diagrama de datos relacional formal a partir del diagrama orientado por objetos formal:. FIGURA 8. DIAGRAMA DE SECUENCIA DE LA CREACIÓN DEL DIAGRAMA DE DATOS RELACIONAL FORMAL A PARTIR DEL DIAGRAMA DE ORIENTADO POR OBJETOS FORMAL.. 8.4.5 Generación de los scripts de creación de tablas a partir de un modelo de datos relacional formal:. FIGURA 9. DIAGRAMA DE SECUENCIA PARA LA CREACIÓN DE LOS SCRIPT DE CREACIÓN DE TABLAS A PARTIR DE UN MODELO DE DATOS RELACIONAL FORMAL.

(49) ISC-2003-1-25. 40. 9 CONSIDERACIONES PARA EL USO DE LA APLICACIÓN A continuación se presentan las consideraciones que se deben tener en cuenta al momento de ejecutar la aplicación. Para ello, se definen las consideraciones iniciales, las cuales hacen referencia al formato de los archivos, a los formatos de las cadenas de las multiplicidades y nombres de los objetos en el diagrama de clases, y posteriormente un ejemplo de utilización de la aplicación.. 9.1. CONSIDERACIONES INICIALES. w El archivo generado por DIA debe estar comprimido con formato GZIP (esto lo realiza automáticamente DIA v9.0), y con extensión *.dia. Por ejemplo: compras.dia, prueba.dia, etc. w Los nombres de las clases y atributos en el diagrama de clases pueden contener espacios entre ellos, ya que la aplicación, basada en el estándar SQL92 reemplaza el carácter ‘ ‘ (espacio) por el carácter ‘_’. Por ejemplo: si se tiene una clase en el diagrama de clases llamada “el curso”, en el modelo de datos relacional se llamará “el_curso”. w La aplicación en ningún momento toma los nombre de los métodos definidos en el diagrama de clases. w Las multiplicidades deben ser definidas con el formato: [mult]..[mult], donde [mult] puede tomar cualquier valor numérico o el carácter ‘*’. Por ejemplo: 0..1 ó 1..*.. 9.2. CONSIDERACIONES PARA LO SCRIPTS DE CREACIÓN DE. TABLAS w Los tipos de datos de los atributos de clases en el diagrama de clases, tales como int y String, son trasladados a tipos de datos de tablas en la base de datos, como Integer y Varchar, respectivamente. En el caso de Oracle Integer es un tipo de dato con 38 bytes, y en el caso de Postgres de 8 bytes..

(50) ISC-2003-1-25. 9.3. 41. EJEMPLO DE UTILIZACIÓN DE LA APLICACIÓN. Al ejecutar la aplicación se muestra la siguiente ventana:. FIGURA 10. VENTANA INICIAL DE LA APLICACIÓN.. Luego, se escoge la opción de abrir, la cual permite abrir el archivo que contiene el diagrama de clases generado por DIA v9.0:. FIGURA 11. VENTANA PARA ABRIR EL DIAGRAMA DE CLASES.. Luego de realizar la lectura del diagrama de clases, se realizan una serie de pasos al interior de la aplicación, los cuales realizan la traslación del diagrama de clases a un modelo orientado por.

(51) ISC-2003-1-25. 42. objetos, del modelo orientado a objetos formal al modelo de datos relacional formal (Ver Anexo 1), y finalmente la generación de los scripts de creación de tablas a partir del modelo de datos relacional formal. Este es el resultado de la traslación del modelo de datos orientado por objetos al modelo de datos relacional y a su vez a un script de creación de tablas:. FIGURA 12. VENTANA CON EL SCRIPT DE CREA CIÓN DE TABLAS.. Finalmente se da la opción al usuario de guardar el script de creación de tablas en un archivo:. FIGURA 13. VENTANA PARA GUARDAR EL SCRIPT DE CREACIÓN DE TABLAS..

(52) ISC-2003-1-25. 9.4. 43. CONSIDERACIONES PARA FUTUROS DESARROLLOS. Debido al alcance que posee el ciclo de desarrollo de proyecto de grado, no fue posible realizar el desarrollo completo de todas las características que se consideraron deseables, para ser implementadas en la aplicación desarrollada en este proyecto de grado, por ello se mencionan algunos aspectos a tener en cuenta en el caso de que se decida continuar el desarrollo de la aplicación propuesta en este proyecto de grado: w Permitir la lectura de formatos adicionales de diagramas de clases, generados por otras aplicaciones, tales como Together, Poseidón, Visio, etc. w Adicionar un módulo de interfaz gráfica que permita visualizar el diagrama de clases que se quiere realizar la traslación. w Adicionar un módulo de interfaz gráfica que permita visualizar el diagrama de datos relacionado que genera la aplicación. Adicionalmente, desarrollar un módulo que permita realizar las modificaciones al diagrama de datos, y que el script de creación de tablas se modifique automáticamente. w Extender el rango de la sintaxis del script de generación de tablas, a otros sistemas manejadores de bases de datos, y/o que se implementen nuevas funcionalidades en la aplicación para el manejo de bases de datos..

(53) ISC-2003-1-25. 44. 10 CONCLUSIONES Se logró implementar una herramienta útil y práctica para el proceso de desarrollo de software, con la intención de disminuir el tiempo y aumentar la eficiencia de dicho proceso, mediante la generación de scripts de creación de tablas a partir de un diagrama de clases expresado en UML, creado a partir de DIA v9.0.. La aplicación permite al usuario escoger el archivo donde se encuentra la aplicación generado por DIA v9.0, realiza la traslación del diagrama de clases a un modelo orientado por objetos formal, y a su vez, a un modelo de datos relacional formal. Finalmente se obtiene un script de creación de tablas, que el usuario puede guardar en un archivo.. El script de creación de tablas generado por la aplicación está basado en el estándar SQL92, el cual permite que este mismo script pueda ser ejecutado por cualquier sistema manejador de bases de datos que haya sido desarrollado bajo el estándar SQL92, por ejemplo, oracle, postgres y mysql.. Para ello, se debieron tener algunas consideraciones y restricciones, las cuales obedecen a los tipos de datos que utilizan los diferentes sistemas manejadores de bases de datos, ya que todos poseen diferentes implementaciones de los tipos de datos básicos. Para los tipos de datos que se definen en el diagrama de clases como ”int” se utilizó “Integer”, y para el tipo de dato “String” se utilizó “Varchar”.. Inicialmente, al momento de implementar la creación automática de los scripts de creación de tablas se pensó que para el tipo de dato “Integer” en la base de datos se le debía definir el número de dígitos, por ejemplo Integer(10), Integer(20), pero según en el estándar SQL92, el tipo de dato “Integer” no se le debe definir el número de dígitos. Igualmente, se llegó a pensar que el tipo de dato “Varchar2” estaba definido en el estándar SQL92, pero ocurrió que este tipo de dato sólo está definido en el sistema manejador de bases de daos Oracle, razón por la cual se decidió utilizar “Varchar”..

(54) ISC-2003-1-25. 45. Para las tablas que poseen más de una columna en la definición de la llave primaria, por ejemplo: CONSTRAINT curso_pk PRIMARY KEY (curso_id, profesor_id). Y en otra tabla se define una llave foránea, que hace referencia a una de las columnas que hacen parte de la llave primaria, por ejemplo: CONSTRAINT tiene_fk FOREIGN KEY curso (curso_id). La columna curso_id debe definirse como UNIQUE para que pueda ser referenciada en la otra tabla, por ejemplo: curso_id INTEGER UNIQUE. Como resultado del proyecto de grado cursado, se desarrolló una aplicación que permite la creación de script de creación de tablas a partir de un diagrama de clases, expresado en UML y creado en DIA v9.0, la cual fue probada en los diferentes sistemas manejadores de bases de datos, que son Oracle, Postgres y Mysql, y en los diferentes sistemas operativos Windows 95, 98, 200 y XP..

(55) ISC-2003-1-25. 46. 11 BIBLIOGRAFÍA [1]. http://www.thoughtinc.com/index.html [2]. http://www.objectmatter.com/ [3]. http://jakarta.apache.org/ojb/ [4]. Mapping Object Oriented Models into Relational Models: a formal approach, Luis Rio y Pedro Ramos [5]. Larman, Craig. “UML y Patrones, Introducción al Análisis y diseño orientado a objetos”. Prentice Hall, Inc, Mexico, 1999. [6] http://www.lysator.liu.se/~alla/dia/dia.html.

(56) ISC-2003-1-25. 47. ANEXO 1. SECUENCIA DE EJECUCIÓN DE LA APLICACIÓN A continuación se presenta la secuencia de ejecución que realiza la aplicación dado un diagrama de clases, para la generación de scripts de creación de tablas.. FIGURA 14. DIAGRAMA DE CLASES EJEMPLO.. Secuencia:. Paso 1: Traslación de clases a tablas, y generación de las clases asociativas. Tanto por cada clase definida en el diagrama de clase como por cada asociación de muchos a muchos, se genera una tabla. Para el ejemplo: profesor ();.

(57) ISC-2003-1-25. 48. curso (); estudiante (); tiene ();. Paso 2: Traslación de los atributos de las clases a columnas de las tablas. Por cada atributo que posee la clase se crea un nueva columna en la tabla, y se intenta realizar la traslación de los tipos de datos del diagrama de clases a los tipos de datos de la base de datos. Si ningún tipo de dato es definido, se le asigna “int” por defecto, y se traslada a “Integer”.. profesor (nombre:VARCHAR(30), cedula:VARCHAR(30)); curso (departamento:INTEGER, cupo:INTEGER, asignados:INTEGER); estudiante (nombre:VARCHAR(30), codigo:VARCHAR(30), cedula:VARCHAR(30)); tiene ();. Paso 3: Creación de las llaves primarias de las tablas. Por cada una de las tablas se define una columna que será llave primaria de la tabla.. profesor (nombre:VARCHAR(30), cedula:VARCHAR(30), profesor_id:INTEGER PK); curso (departamento:INTEGER, cupo:INTEGER, asignados:INTEGER, curso_id:INTEGER PK); estudiante (nombre:VARCHAR(30), codigo:VARCHAR(30), cedula:VARCHAR(30), estudiante_id:INTEGER PK); tiene (tiene_id:INTEGER PK);. Paso 4: Generación de los atributos de las tablas asociativas. Para las tablas que son asociativas, se generan columnas adicionales de las tablas que se deben asociar. Además, se definen las llaves foráneas para cumplir con las relaciones asociativas.. profesor (nombre:VARCHAR(30), cedula:VARCHAR(30), profesor_id:INTEGER PK);.

Figure

Actualización...

Referencias

Actualización...