Desarrollo-de-un-framework-de-mapeo-de-objetos-a-bases-de-datos-relacionales-ORM-utilizando-Java-y-XML

Vista previa del material en texto

U N I V E R S I D A D N A C I O N A L 
A U T Ó N O M A D E M É X I C O 
 
FACULTAD DE ESTUDIOS SUPERIORES 
ACATLÁN 
 
 
Desarrollo de un framework de mapeo de objetos a bases 
 de datos relacionales 
(ORM) utilizando Java y XML. 
 
T E S I S 
 
PARA OBTENER EL TITULO DE: 
 
LICENCIADO EN MATEMÁTICAS APLICADAS 
Y COMPUTACIÓN 
 
 
P R E S E N T A 
 
GUILLERMO ELEAZAR CABRERA BERNAL 
 
Asesor: Licenciado Jaime Vergara Prado 
 
 
 
Fecha: Agosto 2009 
 
UNAM – Dirección General de Bibliotecas 
Tesis Digitales 
Restricciones de uso 
 
DERECHOS RESERVADOS © 
PROHIBIDA SU REPRODUCCIÓN TOTAL O PARCIAL 
 
Todo el material contenido en esta tesis esta protegido por la Ley Federal 
del Derecho de Autor (LFDA) de los Estados Unidos Mexicanos (México). 
El uso de imágenes, fragmentos de videos, y demás material que sea 
objeto de protección de los derechos de autor, será exclusivamente para 
fines educativos e informativos y deberá citar la fuente donde la obtuvo 
mencionando el autor o autores. Cualquier uso distinto como el lucro, 
reproducción, edición o modificación, será perseguido y sancionado por el 
respectivo titular de los Derechos de Autor. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Agradezco al gran arquitecto del universo: por el camino que me ha 
indicado para llegar a este momento, por mis padres de los que siempre 
estoy orgulloso y mis hermanas que son mis mejores amigas y mi 
adoración. 
 
Dedico este trabajo a mis padres que 
siempre me acompañan. 
 
UNIVERSIDAD NACIONAL AUTÓNOMA DE MÉXICO 
Campus Acatlán 
 
Tesis de licenciatura en Matemáticas Aplicadas y Computación 
 1 
 
CONTENIDO. 
 
INTRODUCCION. ....................................................................... ¡ERROR! MARCADOR NO DEFINIDO.
CAPITULO 1. CONCEPTOS BÁSICOS. .................................... ¡ERROR! MARCADOR NO DEFINIDO.
1.1 INTRODUCCIÓN. ............................................................................. ¡ERROR! MARCADOR NO DEFINIDO.
1.2 DEFINICIÓN DE FRAMEWORK. ......................................................... ¡ERROR! MARCADOR NO DEFINIDO.
1.3 LENGUAJE DE PROGRAMACIÓN JAVA. ............................................. ¡ERROR! MARCADOR NO DEFINIDO.
1.4 LENGUAJE DE REPRESENTACIÓN XML. ........................................... ¡ERROR! MARCADOR NO DEFINIDO.
1.5 BASES DE DATOS ENTIDAD-RELACIÓN. ............................................ ¡ERROR! MARCADOR NO DEFINIDO.
1.6 LENGUAJE UNIFICADO DE MODELADO UML. ................................... ¡ERROR! MARCADOR NO DEFINIDO.
1.6.1 Vistas. ............................................................................................ ¡Error! Marcador no definido.
1.6.2 Diagramas. .................................................................................... ¡Error! Marcador no definido.
1.7 PATRONES DE DISEÑO. ................................................................... ¡ERROR! MARCADOR NO DEFINIDO.
1.8 MAPEO DE OBJETOS A BASES DE DATOS ENTIDAD - RELACIÓN. ........ ¡ERROR! MARCADOR NO DEFINIDO.
CAPITULO 2. FASE DE ANÁLISIS. .......................................... ¡ERROR! MARCADOR NO DEFINIDO.
2.1 INTRODUCCIÓN. ............................................................................. ¡ERROR! MARCADOR NO DEFINIDO.
2.2 CASOS DE USO. .............................................................................. ¡ERROR! MARCADOR NO DEFINIDO.
2.2.1 Realización de los casos de uso del paquete de componentes de acceso de base de datos y 
ejecución de transacciones. ..................................................................... ¡Error! Marcador no definido.
2.2.2 Realizaciones de casos de uso del paquete de componentes ORM. ... ¡Error! Marcador no definido.
2.2.3 Inventario de clases de análisis por paquete. .................................. ¡Error! Marcador no definido.
CAPITULO 3. FASE DE DISEÑO .............................................. ¡ERROR! MARCADOR NO DEFINIDO.
3.1 INTRODUCCIÓN .............................................................................. ¡ERROR! MARCADOR NO DEFINIDO.
3.2 ARQUITECTURA CONCEPTUAL DEL FRAMEWORK. ............................ ¡ERROR! MARCADOR NO DEFINIDO.
3.3 MODELO DE DISEÑO DEL DOCUMENTO DE MAPEO XML ................... ¡ERROR! MARCADOR NO DEFINIDO.
3.4 REALIZACIONES DE CASOS DE USO DEL PAQUETE DE COMPONENTES DE ACCESO DE BASE DE DATOS Y 
EJECUCIÓN DE TRANSACCIONES. .......................................................... ¡ERROR! MARCADOR NO DEFINIDO.
3.4 REALIZACIONES DE CASOS DE USO DEL PAQUETE DE COMPONENTES DE ACCESO DE BASE DE DATOS Y 
EJECUCIÓN DE TRANSACCIONES. .......................................................... ¡ERROR! MARCADOR NO DEFINIDO.
3.5 REALIZACIONES DE CASOS DE USO DEL PAQUETE DE COMPONENTES ORM.
 
 ....... ¡ERROR! MARCADOR NO 
DEFINIDO.
3.6 INVENTARIO DE CLASE DE DISEÑO POR PAQUETE. ............................ ¡ERROR! MARCADOR NO DEFINIDO.
CAPITULO 4. FASE DE CONSTRUCCIÓN Y PRUEBAS. ...... ¡ERROR! MARCADOR NO DEFINIDO.
4.1 INTRODUCCIÓN. ............................................................................. ¡ERROR! MARCADOR NO DEFINIDO.
4.1 ARQUITECTURA DE DESARROLLO Y FÍSICA DEL FRAMEWORK. .......... ¡ERROR! MARCADOR NO DEFINIDO.
4.2 INVENTARIO DE CLASES POR PAQUETE. ........................................... ¡ERROR! MARCADOR NO DEFINIDO.
4.3 CASOS DE PRUEBA. ........................................................................ ¡ERROR! MARCADOR NO DEFINIDO.
4.4 EJEMPLO DE IMPLEMENTACIÓN. ...................................................... ¡ERROR! MARCADOR NO DEFINIDO.
4.5 ANÁLISIS DE INFORMACIÓN. ........................................................... ¡ERROR! MARCADOR NO DEFINIDO.
CONCLUSIONES:................................................................................................................................ ... 90 
BIBLIOGRAFÍA. ......................................................................... ¡ERROR! MARCADOR NO DEFINIDO.
GLOSARIO. ................................................................................. ¡ERROR! MARCADOR NO DEFINIDO.
 
UNIVERSIDAD NACIONAL AUTÓNOMA DE MÉXICO 
Campus Acatlán 
 
Tesis de licenciatura en Matemáticas Aplicadas y Computación 
 
2 
 
INTRODUCCION. 
 
El presente trabajo está enfocado a la creación de un framework que contribuya a optimizar tiempo y mejorar 
de calidad en la infraestructura de software de proyectos, particularmente en sistemas que tienen como base 
arquitectónica el uso de la plataforma Java versión 1.3 o mayor en combinación con el uso de alguno de los 
siguientes motores de base de datos relacionales: MySQL versión 4.0 o superior, INFORMIX versión 7.3 o 
mayor o SQL Server versión 6.0 o mayor. 
 
El desarrollo de sistemas de información se compone de diferentes áreas de conocimiento tales como 
levantamiento de requerimientos, análisis y diseño orientado a objetos, metodologías de desarrollo, 
conocimientos técnicos de hardware y software dependiendo de la arquitectura a implantar y evidentemente 
lenguajes de programación. Adicionalmente, en la industria se han estado definiendo de hace tiempo a la 
fecha estándares mundiales para homogenizar y estabilizar la creación de productos de software para las 
diferentes tecnologías, ejemplos de tales estándares en el tiempo son la definición de C ANSI, SQL ANSI, 
JAVA, UML, J2EE, RUP, Microsoft .NET, AJAS, JavaScript, HTML, BPEL, XPDL, BPMN, etc. 
 
Así mismo existen organizaciones encargadas de conciliar, consolidar y publicar dichos estándares (IEEE, 
ANSI, OMG, ISO, CMMI, OASIS y W3C) que establecen las formas concretas de plasmar los productos 
generados para las áreas de conocimiento mencionadas, esto evidentemente enfocado a la búsqueda de 
homogeneizar, medir y controlar los tiempos necesarios de desarrollo de los sistemas así como simplificar el 
mantenimiento de los mismos, pudiendo así tener proyectos de desarrollo más grandes y ambiciosos; 
Proyectos en Internet o Intranet donde participende 50 a 500 personas, donde el beneficio al usuario final y 
responsabilidad y riesgo de éxito de las empresas o instituciones participantes es mayor. Ejemplos de estos 
sistemas en nuestro país en la actualidad, pueden ser los relacionados con el sector gobierno (Secretaría de 
Hacienda, IMSS, Secretaria de Gobernación), los cuales mediante la ley de transparencia hacen disponibles, 
sus bases de licitación en Internet. Otro ejemplo de este tipo de sistemas son los ubicados en el sector 
bancario donde ya no es necesario el papel para fichas de depósito, o retiro. Todos estos sistemas deben 
atender a millones de usuarios, asegurando la disponibilidad, exactitud y seguridad de los movimientos 
ejecutados, para la completa satisfacción de sus clientes. 
 
Para que las empresas de desarrollo de software, puedan permanecer en la competencia por el mercado del 
tipo de proyectos mencionados, es necesario contar con una infraestructura administrativa, hardware, 
software y recursos humanos especializada, dependiendo de la tecnología y necesidad del usuario. 
 
Los siguientes capítulos tienen como objetivo, guiar al lector a través de las diferentes fases del proceso de 
desarrollo del framework. El diagrama de componentes de la figura I, muestra la ubicación del framework a 
desarrollar dentro de la arquitectura de un sistema. 
 
 
 
 
Figura I, Diagrama de conceptual de 
componentes donde participa el 
framework. 
 
 
 
 
 
 
 
 
UNIVERSIDAD NACIONAL AUTÓNOMA DE MÉXICO 
Campus Acatlán 
 
Tesis de licenciatura en Matemáticas Aplicadas y Computación 
 
3 
 
Como se puede observar la capa del framework está ubicada entre la base de datos y la capa de reglas de 
negocio, por lo tanto sus usuarios son componentes de negocio de algún sistema, El presente trabajo utiliza 
como metodología de desarrollo el Proceso Unificado de Desarrollo de software, lo cual significa que el 
desarrollo del framework esta dirigido por la definición de casos de uso y la arquitectura. Es muy importante 
aclarar al lector que dada la ubicación y naturaleza del framework, el modelado de la fase análisis de los 
componentes participantes, será a muy bajo nivel, es decir, el negocio a modelar en los casos de uso en la fase 
de análisis está descrita en términos y definiciones de software, dado que es el contexto de negocio requerido. 
 
El capítulo uno describe brevemente las disciplinas que sustentan los conceptos del mapeo de objetos 
relacionales (Object Relational Mapping ORM), indicando su relevancia en la construcción del framework. El 
capítulo dos presenta la vista de casos de uso de la definición del framework, el capítulo tres, presenta la vista 
de lógica o modelo de diseño del framework, y por ultimo el capítulo 4, presenta la arquitectura física del 
sistema y sus relaciones en clases de código fuente Java. 
 
Finalmente se presentan las conclusiones, es importante aclarar que el presente trabajo no es una guía de 
cómo realizar un análisis, diseño o construcción de un sistema, por lo cual el lector debe tener conocimientos 
básicos de estos temas, de igual manera tampoco se pretende enseñar a programar utilizando Java o XML. 
UNIVERSIDAD NACIONAL AUTÓNOMA DE MÉXICO 
Campus Acatlán 
 
Tesis de licenciatura en Matemáticas Aplicadas y Computación 
 
4 
 
CAPITULO 1. Conceptos básicos. 
 
 
 
1.1 Introducción. 
 
El presente capítulo tiene como meta inducir de forma general al lector en las áreas principales parte de la 
arquitectura del framework. Las cuales son: lenguaje Java, lenguaje XML, bases de datos relacionales, 
UML, Patrones de diseño y técnicas de mapeo de objetos a modelo entidad-relación. La figura 1.1 
muestra la ubicación de soporte e importancia de cada una de las disciplinas. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Como se puede ver en la figura 1.1, UML es un pilar de conocimiento vertical que apoya a la definición y 
modelado de las áreas del lado derecho, mientras que las debajo del rectángulo con el nombre framework 
ORM son, en orden de aparición de abajo hacia arriba, las que dan soporte horizontal al desarrollo. 
 
1.2 Definición de framework. 
 
Según Ivar Jacobson, Grady Booch y James Rumbaugh autores del libro del Proceso Unificado de 
desarrollo de software, creadores de UML y de las metodologías mas representativas para el análisis y 
diseño orientado a objetos, el término de framework en la industria del software corresponde a una 
micro-arquitectura que proporciona una plantilla o templete incompleto para sistemas de un determinado 
contexto, el cual está compuesto por conjuntos de componentes relacionados. Por ejemplo: Java es un 
framework que permite crear programas independientes de la plataforma de hardware a través de la 
máquina virtual, en español, framework se traduce como marco de trabajo. 
 
La figura 1.2 muestra de manera simple el marco de trabajo de Java, el cual permite desarrollar código 
fuente de programación independiente del sistema operativo. Básicamente el marco de trabajo consiste en 
la creación de librerías y componentes de ejecución nativos en el sistemas operativo, las cuales son 
accedidas por el marco de trabajo de java (Maquina Virtual) el cual interpreta el programa conforme al 
sistema operativo en uso, así, el programador no se preocupa de estas actividades y utiliza las mismas 
sentencias de programación sin importar la plataforma de ejecución, en otras palabras la creación de 
objeto ventana en java crea una ventana en Windows, MAC, Linux o Uníx Solaris de manera 
transparente dependiendo de donde se ejecute el programa y con la maquina virtual adecuada instalada. 
La siguiente sección da más detalle Java. 
Figura 1.1 Diagrama que representa las áreas de conocimiento del framework a 
desarrollar. 
 
 
 
 
 
 
UNIVERSIDAD NACIONAL AUTÓNOMA DE MÉXICO 
Campus Acatlán 
 
Tesis de licenciatura en Matemáticas Aplicadas y Computación 
 
5 
 
 
 
 
 
 
 
 
 
 
 
 
 
1.3 Lenguaje de programación Java. 
 
El lenguaje de programación Java es utilizado para la implementación del framework. Las características 
principales por las cuales se trabaja con esta lenguaje obedecen básicamente a la portabilidad de código, 
es decir, los programas escritos en dicho lenguaje con el concepto de escribe una vez, ejecuta donde sea; 
adicionalmente Java* posee de forma intrínseca el uso de hilos* de ejecución y control de los mismos, así 
como un API* para el acceso a base de datos relacionales, JDBC*
• Interfaces, clases y objetos. 
, además de todas las ventajas de los 
lenguajes orientados a objetos, Finalmente la portabilidad de Java hace posible que los frameworks 
implementados en este lenguaje, puedan participar en diferentes tipos de arquitecturas, desde aplicaciones 
Web, hasta aplicaciones de estación de trabajo o incluso en celulares, todo por el mismo precio de 
codificación del programa. Los siguientes párrafos describen de forma rápida los conceptos más 
importantes del lenguaje. 
 
 
Los principales componentes de construcción de java son: 
 
 Clases: Son los entidades de información y comportamiento que implementan propiedades 
(atributos) y las acciones (métodos) que ejecutan los objetos. Una clase puede tanto 
implementar métodos de una interfaz así como implementar los propios o heredarlos de otra 
clase. 
 Propiedades: Son atributos que definen características atómicas de la clase, por ejemplo 
una clase Persona puede tener una propiedad llamada edad 
 Métodos: Son operaciones o acciones que puede realizar una clase. Continuando con el 
ejemplo de la clase Persona, una operación o método factible para una Persona puede ser 
dormir. 
 Objeto: Un objeto es una instancia de clase; es una clase en tiempo de ejecución de 
programa. Encapsula un estado, que es definido por los valores de las propiedades del 
mismo, los cuales pueden ser alterados mediante la modificación de las propiedades o 
mediante la ejecución de alguno de los métodos existentes.* Ver sección de glosario y para información www.javasoft.com 
Figura 1.2 Diagrama conceptual del relación entre componentes de 
la plataforma de tiempo de ejecución java 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
UNIVERSIDAD NACIONAL AUTÓNOMA DE MÉXICO 
Campus Acatlán 
 
Tesis de licenciatura en Matemáticas Aplicadas y Computación 
 
6 
 Interfaz: Una interfaz solamente define tipos de atributos, y métodos, es decir una interfaz 
no puede tener instancias y ni sentencias de programación en sus métodos. 
 
• Paquetes. 
 
La definición de paquetes es un mecanismo de ámbito de nombres para clase e interfaces en java. El 
ámbito de nombres alcanza los siguientes resultados: 
 
 Se agrupan clases e interfaces juntas 
 Se permite que una clase o interfaz tenga el mismo nombre en diferentes ámbitos, es decir, 
en diferentes paquetes y pueden ser distinguidas por el nombre completo o calificado del 
ámbito. 
 
• Objetos en tiempo de ejecución. 
 
Los objetos en tiempo de ejecución son instancias de clase. En el caso de Java, un objeto siempre esta 
asociado a una máquina virtual Java, que aloja la memoria donde un objeto mantiene su estado y ejecuta 
el código byte-code que le representa. 
 
Una máquina virtual puede ejecutar uno o más objetos. Las máquinas virtuales pueden ser implementadas 
para diferentes dispositivos de hardware (PC, servidores, celulares, etc.) como procesos del sistema 
operativo. 
 
La ejecución del programa Java sigue el flujo de llamados entre métodos de clase y los retornos de 
manera secuencial de los mismos, o por medio de un hilo de ejecución (thread)*, alternativamente Java 
permite a cada programa, la creación y control de sus propios hilos de ejecución e incluso a través de 
algunas librerías la creación de instancias de objetos entre máquinas virtuales, la figura 1.31
 
, esquematiza 
el uso de diferentes hilos de ejecución, así como la existencia de varios objetos en la misma; finalmente 
también refleja la posibilidad de llamado a otras instancias de objetos a otros equipos. 
 
1.4 Lenguaje de representación XML. 
 
El lenguaje XML (Extensible Markup Language) representa un importante paso en la representación de 
datos. Por lo general para la creación de archivos de configuración de almacenamiento de datos, se había 
recurrido a archivos de texto que utilizaban como separador de campos al carácter coma, el carácter pipe 
o algún otro sin estándar alguno a seguir. 
 
 
* Ver sección de glosario 
1 La imagen pertenece al libro de Java Programming with CORBA, nombrado en la bibliografía 
Figura 1.3, Objetos Java en tiempo de 
ejecución 
UNIVERSIDAD NACIONAL AUTÓNOMA DE MÉXICO 
Campus Acatlán 
 
Tesis de licenciatura en Matemáticas Aplicadas y Computación 
 
7 
XML resuelve este problema definiendo una manera estándar de representar datos, una manera estándar 
para identificar los datos con su tipo, y una forma estándar de describir la estructura. XML es muy 
simple, de leer y entender el ser visto. Para mayor claridad a continuación se indican algunas de las cosas 
que XML no es: 
 
 XML no es el reemplazo de HTML. Sin embargo existe una versión XML compatible con 
HTML, XML no define cómo representar datos en un navegador. 
 XML no es una cura para todos los tipos de formatos, varios sectores de la industria siguen 
tratando de llegar a acuerdos sobre ello. 
 XML no es un lenguaje de programación, XML permite describir datos, pero no permite 
describir cómo los datos serán procesados. 
 
 
El uso de XML como parte de la solución al framework ORM, obedece a que se requiere guardar en 
algún formato estándar, la definición de los mapeos de objetos a tablas de base de datos; esto se ve con 
mayor claridad en la sección 1.5 y 1.8 del presente capítulo. 
 
• Estructura estándar de un documento XML. 
 
La estructura de un documento XML se compone de un encabezado, y elementos, de los cuales uno debe 
ser raíz de los demás y dentro de él pueden haber más que tienen o no atributos; todo elemento incluye un 
tag de apertura <elemento> y uno de cierre </elemento>. El siguiente ejemplo muestra la estructura de 
un documento XML que realiza el mapeo de una clase java con nombre calificado 
com.sigmatao.unitTest.entidad.ClliSysDAO a una tabla clli_sys 
 
 
1. <?xml version="1.0" encoding="ISO-8859-1"?> 
2. <!-- Archivo de configuracion de clases O/R --> 
 
3. <descriptores-clase> 
4. <clase nombre="com.sigmatao.unitTest.entidad.ClliSysDAO" tabla="clli_sys"> 
5. <atributo> 
6. <cmp-pk>true</cmp-pk> 
7. <cmp-clase>TipoSis</cmp-clase> 
8. <cmp-bd>tipo_sis</cmp-bd> 
9. <cmp-tipo>INTEGER</cmp-tipo> 
10. <cmp-requerido>true</cmp-requerido> 
11. <nulo>-2147483648</nulo> 
12. <default></default> 
13. </atributo> 
14. <atributo> 
15. <cmp-clase>TipoCodif</cmp-clase> 
16. <cmp-bd>tipo_codif</cmp-bd> 
17. <cmp-tipo>INTEGER</cmp-tipo> 
18. <cmp-requerido>false</cmp-requerido> 
19. <nulo>-2147483648</nulo> 
20. </atributo> 
21. <atributo> 
22. <cmp-clase>Observaciones</cmp-clase> 
23. <cmp-bd>observaciones</cmp-bd> 
24. <cmp-tipo>VARCHAR</cmp-tipo> 
25. <cmp-requerido>false</cmp-requerido> 
26. <nulo>nulo</nulo> 
27. </atributo> 
28. <atributo> 
29. <cmp-clase>CveFun</cmp-clase> 
30. <cmp-bd>cve_fun</cmp-bd> 
31. <cmp-tipo>INTEGER</cmp-tipo> 
32. <cmp-requerido>false</cmp-requerido> 
33. <nulo>-2147483648</nulo> 
34. </atributo> 
35. </clase> 
36. </descriptores-clase> 
UNIVERSIDAD NACIONAL AUTÓNOMA DE MÉXICO 
Campus Acatlán 
 
Tesis de licenciatura en Matemáticas Aplicadas y Computación 
 
8 
 
El elemento clase de la línea 4 posee dos atributos uno se llama nombre el cual almacena el nombre 
calificado de la clase de mapeo y otro llamado tabla tiene el nombre de la tabla asociada a la clase. 
 
1.5 Bases de datos entidad-relación. 
 
El objetivo principal del presente documento es lograr mejorar la productividad en la construcción del 
acceso, modificación y consulta de bases de datos relacionales a través del mapeo de clases a tablas, así 
que en esta sección describiremos brevemente en qué consiste una base de datos relacional y de que 
maneras puede ser explotada. 
 
Una base de datos relacional es como su nombre lo indica, un repositorio de información relacionada; la 
manera de estructurar el repositorio consiste en definir mediante un análisis y diseño de base de datos, las 
entidades, atributos y relaciones que deben existir para almacenar cierta información de negocio. A 
continuación se describen los componentes principales de la base de datos. 
 
• Entidad: Una entidad de base de datos o tabla es un concepto del negocio del cual se debe almacenar 
información; por lo general son sustantivos, en la descripción del caso de uso y cuando se tiene un 
modelo de objetos, las clases de análisis por lo general terminan siendo también entidades de base de 
datos. Por ejemplo en un sistema de nómina seguramente existe la tabla y la clase Empleado. 
• Atributos: Los atributos son las características inherentes a cada entidad, al igual que en las 
entidades, en un modelo de objetos por lo general las propiedades encontradas para las clases se 
convierten en los atributos de las entidades, Continuando con el ejemplo la entidad Empleado, ésta 
seguramente tiene las características o atributos: nombre, dirección, puesto, departamento y salario. 
• Relaciones: Las relaciones son la manera de modelar las asociaciones existentes entre las diferentes 
entidades, aquí la única posible relación con el modelo de objetos es la cardinalidad de la relación y 
nada más; La cardinalidad de la relación de una entidad con otra, puede ser cualquiera de las 
siguientes: 
 
 Uno a uno: Una relación de este tipo significa que cada registro2
 Uno a muchos: Esta relación representa quecada registro de la entidad C, puede estar 
asociada a uno o varios registros de la entidad D. Por ejemplo, una organización puede tener 
uno o varios departamentos. 
 de la entidad A esta 
asociado a uno y sólo un registro de la entidad B. Por ejemplo, un empleado puede estar 
asociado sólo a un departamento de una organización. 
 Muchos a Muchos: Esta relación es la más compleja de todas en el modelado de bases de 
datos relacionales, y representa que cada registro de una entidad D, puede estar asociado a 
muchos registros de la entidad F, y que la entidad F a su vez también tiene la característica 
de que cada unos de sus registros puede estas asociado a uno o muchos, registros de la 
entidad D. Por ejemplo Un empleado puede tener que desarrollar una o más actividades en 
su trabajo y una actividad puede se realizada por uno o mas empleados. 
 
Como es de suponerse, el modelo de base de datos en análisis sólo se describe con conceptos de negocio 
de manera que es un documento que apoya la comunicación con el usuario final siendo un indicador de 
compresión del negocio. En la fase de diseño, cada entidad y sus atributos es convertida a tablas con 
campos y estos tienen tipos de datos en el contexto del software. Como el lector puede intuir, el mapeo de 
objetos a tablas es bastante simple en concepto, sin embargo su implementación en software es más 
compleja, como se ve en la sección 1.8 del presente capítulo. 
 
La manera de explotar y afectar la información de una base de datos relacional, es por estándar a través 
del uso del lenguaje estructurado de consulta, SQL (Structure Query Language), este lenguaje dio pie a 
que los programas desarrollados pudiesen ser independientes de la base de datos donde se construyeron 
 
2 Una registro es un conjunto de valores asociados a los atributos de una entidad, por ejemplo en la tabla Empleado pueden existir muchos registros con la información de muchas 
personas 
UNIVERSIDAD NACIONAL AUTÓNOMA DE MÉXICO 
Campus Acatlán 
 
Tesis de licenciatura en Matemáticas Aplicadas y Computación 
 
9 
simplemente utilizando el estándar mundial; es decir un programa en C con SQL ANSI puede funcionar 
utilizando la base de datos MySQL, Oracle, Informix o SQL Server3
1.6 Lenguaje unificado de modelado UML. 
. 
 
Con la aparición de la tecnología cliente/servidor, Microsoft liberó ODBC (Open DataBase Connectivity) 
con la cual desde cualquier lenguaje de programación que se pueda ejecutar en la plataforma Microsoft 
Windows u otro sistema operativo que soporte librerías ODBC se puede conectar y realizar sentencias 
SQL para explotar la información de una base de datos. Evidentemente Sun Microsystems no tardo en 
reaccionar y liberó las librerías JDBC (Java DataBase Connectivity) con las cuales un programa puede 
conectarse y explotar una base de datos a través de SQL. Dado que Java es independiente de la 
plataforma, entonces los programas escritos en Java con JDBC y SQL ANSI son independientes de la 
plataforma de hardware y del motor de base de datos. 
 
 
El lenguaje unificado de modelado (UML por sus siglas en ingles) tiene como meta ser utilizado como 
herramienta para la representación de negocios de sistemas de software que tienen de premisa utilizar la 
implementación de algún lenguaje orientado a objetos; en teoría modela cualquier construcción que 
posea una estructura estática y dinámica. En orden de mantener estás amplias capacidades, el lenguaje 
está definido para ser extensible y suficientemente general para permitir el modelado de sistemas 
diversos, evitando la complejidad y especialización 
 
Esta sección pretende hacer una rápida introducción a UML, con la intención de esclarecer y 
homogeneizar conceptos con respecto a los diferentes artefactos4
 Vistas: Las vistas muestran diferentes aspectos del sistema a ser modelado, una vista no es un 
diagrama, sino más bien una abstracción, que consiste de un número determinado de diagramas. 
Sólo a través de la definición de un numero de vistas es posible mostrar un aspecto particular 
del sistema y se puede ver un panorama completo de lo que se construirá. 
 del lenguaje, los cuales son ocupados 
en el presente trabajo. Los artefactos a describir son: 
 
 
 Diagramas: Los diagramas son las gráficas de describen el contenido de una vista. UML5
 
 tiene 
nueve diferentes tipos de diagramas que se utilizan en combinación para proveer todas las 
vistas del sistema. 
1.6.1 Vistas. 
 
Modelar un sistema complejo es una tarea exhaustiva, de manera ideal, es descrito en un solo diagrama 
que muestra ambiguamente el panorama completo de su estructura, lo cual lo hace fácil de comunicar y 
comprender. Sin embargo, esto es usualmente imposible. Un solo diagrama no puede capturar toda la 
información necesaria para describir un sistema. La descripción por lo general es realizada por diferentes 
aspectos: funcionales (estructura estática e interacciones dinámicas), no funcionales (rendimiento, 
escalabilidad, despliegue, etc.) u organizacionales (organización del, trabajo, mapa de módulos de 
codificación, etc.). Por lo tanto, un sistema es descrito por un número de vistas, donde cada vista 
representa una proyección de la descripción completa, mostrando un aspecto particular cada vez. 
 
 
 
 
 
 
3 Proveedores de motores de bases de datos relacionales 
4 Un artefacto es una pieza de trabajo tangible creada por alguno de los roles participantes en el desarrollo del software 
5 Para mas información ver www.uml.org 
UNIVERSIDAD NACIONAL AUTÓNOMA DE MÉXICO 
Campus Acatlán 
 
Tesis de licenciatura en Matemáticas Aplicadas y Computación 
 
10 
Vista de casos de uso. 
 
La vista de casos de uso describe el funcionamiento del sistema a desarrollar encontrando los actores y 
casos de uso que interactúan entre sí en el sistema, los actores pueden ser distintos perfiles de usuarios 
(administradores, ventas, contadores, etc.) otro sistema o cualquier entidad externa al mismo. Parte del 
objetivo de los artefactos de esta vista es permitir una interacción del equipo de desarrollo con el cliente 
final mucho mas eficaz, los productos generados en esta vista son: descripciones de casos de uso y 
diagramas de casos de uso, los cuales son usados, por los analistas orientados a objetos para hacer los 
que se conoce en el Proceso Unificado de Desarrollo de software como realizaciones de casos de uso, lo 
cual consiste en crear los diagramas de clases de análisis y diagramas de secuencia de análisis para uno 
de los casos de uso encontrados, esto a partir de su descripción, lo más importante, de esta vista son las 
descripciones, las cuales plasman el alcance funcional del sistema. Como ya se menciono en párrafos 
anteriores cada descripción hecha para el trabajo actual será en un nivel muy técnico dado el contexto 
donde se ubica el framework es dentro del sistema, por lo que, los evidentes actores del framework serán 
las clases java que lo utilicen. 
 
De manera muy simple la descripción de un caso de uso es el diálogo sostenido entre un actor y el 
sistema, para ejecutar una operación atómica, cada descripción debe contener al menos los siguientes 
puntos: 
 
 Nombre de caso de uso: Es el nombre que identifica la transacción de negocio a describir, por 
ejemplo “Registra contribuyente”, siempre debe indica con un verbo en tercera persona. 
 Objetivo: Es la meta que da razón de ser a la existencia del caso de uso. 
 Precondiciones: Son las actividades o insumos necesarios para que se pueda ejecutar el caso de uso. 
 Curso Básico: Esta sección describe el dialogo entre el actor y el sistema para el flujo de éxito más 
común, solo existe uno por descripción y normalmente es conocido como el “Happy Path”. Por 
ejemplo: “Registra persona física” 
 Curso Alterno Esta sección describe el dialogo entre el actor y el sistema para flujos alternos más 
específicos dependiendo un actoro ciertas precondiciones, (pueden existir varios por descripción). 
Por ejemplo: “Registra persona moral”. 
 Cursos de excepción: Esta sección describe el dialogo entre al actor y el sistema para cuando se 
presentan inconsistencias, errores o problemas en el curso básico o alterno, por ejemplo: “Persona 
física ya registrada en otra entidad federativa”. 
 Poscondiciones: Es el estado final del sistema al termino de la ejecución de caso de uso. 
 
 A partir de esta descripción se encuentran las clase candidatas iniciales para el sistema y las operaciones 
de las mismas. 
 
Finalmente ésta vista es la base y guía de todas las demás. 
 
Vista lógica. 
 
La vista lógica describe cómo se proveerá la funcionalidad del sistema en términos de hardware y 
software, está puramente enfocada a diseñadores orientados objetos y desarrolladores. En contraste con 
la vista de casos de uso, la vista lógica ve hacia dentro del sistema, describiendo la estructura estática y 
dinámica del mismo. Esta vista, como se menciono en la sección anterior es conducida por los casos de 
uso, es decir por las realizaciones de análisis de la vista de casos de uso, de manera más concreta por los 
diagramas de clase y secuencia de cada caso de uso los cuales sirven ahora como entrada para la 
realización de los casos de uso en diseño, así ésta vista redefine o detalla en el contexto de construcción, 
la estructura estática y dinámica de cada caso de uso, La estructura estática es descrita mediante 
diagramas de clases y la estructura dinámica se describe mediante diagramas de estados, secuencia, 
colaboración o actividades. 
 
 
 
UNIVERSIDAD NACIONAL AUTÓNOMA DE MÉXICO 
Campus Acatlán 
 
Tesis de licenciatura en Matemáticas Aplicadas y Computación 
 
11 
 
Vista de componentes. 
 
Cada una de las clases encontradas en la vista lógica a partir de las realizaciones de diseño se traducirán 
finalmente en algún componente de hardware o software, por ejemplo una librería compartida, un 
archivo ejecutable, o un documento dinámico. Estos componentes se agrupan en módulos por tener 
objetivos similares o pertenecer a la misma solución. La vista de componentes es una descripción de los 
módulos implementados y sus dependencias. Es principalmente para desarrolladores y es representada 
por el diagrama de componentes. 
 
Vista de despliegue. 
 
Finalmente la vista de despliegue muestra las ubicaciones físicas del sistema, es decir indica donde 
residirá cada módulo o componente desarrollado del sistema en equipos tales como computadoras o 
dispositivos (a los cuales se les conoce en UML como nodos) y como se comunican unos con otros. La 
vista de despliegue es para desarrolladores, integradores e ingenieros de pruebas, y está representada por 
el diagrama de despliegue. De manera concreta, es un mapa que muestra cómo los componentes son 
posicionados en la arquitectura física del sistema. 
1.6.2 Diagramas. 
 
Los diagramas son representaciones gráficas que modelan aspectos o conceptos del sistema. Como se 
comentó en las anteriores secciones cada vista posee un conjunto de diagramas que tienen la meta de 
modelar los aspectos relevantes de cada fase para la construcción de cada caso de uso. 
 
Diagramas de casos de uso. 
 
Un diagrama de casos de uso modela un número de actores externos al sistema y su interrelación, ver 
figura 1.4. Dependiendo de la complejidad del sistema se pueden tener diagramas de casos de uso para 
cada módulo o grupos de casos de uso asociados, de manera que se pueden ver las dependencias entre 
ellos y las diferentes perspectivas de los mismos dependiendo de si es usado por más de un actor. 
 
 
 
 
Figura 1.4 diagrama de casos de uso de una aseguradora. 
 
 
 
 
 
UNIVERSIDAD NACIONAL AUTÓNOMA DE MÉXICO 
Campus Acatlán 
 
Tesis de licenciatura en Matemáticas Aplicadas y Computación 
 
12 
Diagramas de clases. 
 
Un diagrama de clases muestra la estructura estática de las clases de un sistema o una realización de un 
caso de uso, y representan las cosas que son manejadas por el sistema. Las clases se pueden relacionar 
unas con otras de diferentes maneras, por asociación (conectadas una con otra), dependencia (una clases 
depende o usa otra clase), especialización (una clase es una especialización de otra clase) o por paquete 
(agrupación de las clases como una unidad). Todas éstas relaciones pueden ser representadas en 
diagramas de clases en términos de propiedades y métodos. El diagrama es considerado estático en el 
sentido de que la estructura descrita es siempre válida en cualquier momento del tiempo de ejecución del 
sistema. Este diagrama tiene cierta semejanza con un diagrama Entidad – Relación. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Diagramas de estados. 
 
Un diagrama de estados es típicamente un complemento a la descripción de una clase. Muestra todos los 
estados posibles que los objetos de una clase pueden tener, y qué eventos provocan los cambios de 
estado (ver figura 1.6). Un evento puede ser disparado por otro objeto que le envía un mensaje – por 
ejemplo, indicando que un tiempo especifico se ha alcanzado- o que alguna condición ha sido 
completada: Un cambio de estado es conocido con el término de transición. Una transición puede 
además tener una acción asociada que especifica que debe ser realizada como consecuencia de la 
transición. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Figura 1.5, diagrama de clases de un inventario. 
Figura 1.6, diagrama de 
estados de un elevador. 
 
 
 
 
 
 
 
 
 
 
UNIVERSIDAD NACIONAL AUTÓNOMA DE MÉXICO 
Campus Acatlán 
 
Tesis de licenciatura en Matemáticas Aplicadas y Computación 
 
13 
 
Los diagramas de estados no son realizados para todas las clases, sólo para aquéllas que tienen un 
número bien definido de estados y donde el comportamiento de las clases es afectado y cambiado por 
diferentes estados. 
 
Diagramas de secuencia. 
 
Un diagrama de secuencia muestra la colaboración dinámica entre un determinado número de objetos, 
como se muestra en la figura 1.7; el aspecto más importante de este tipo de diagramas es modelar la 
secuencia de mensajes enviados entre objetos, cada mensaje simboliza el llamado a un método de una 
clase a otra, representando una foto del comportamiento en tiempo de ejecución del sistema o de la 
realización de un caso de uso. En un diagrama de secuencia se representan por rectángulos con líneas 
verticales en la parte inferior y el tiempo de ejecución transcurre de arriba hacia abajo. Los mensajes de 
envío o llamados métodos son representados por líneas con puntas de flecha, entre las líneas verticales 
de los objetos. La especificación del tiempo y los comentarios se indican en texto el margen del 
diagrama. 
 
 
 
 
 
 
 
 
 
Diagramas de componentes. 
 
Un diagrama de componentes muestra la estructura física del código en términos de piezas de código. Un 
componente puede ser un archivo fuente compilado, un archivo binario, o una librería ejecutable. 
Permitiendo un mapeo de la vista lógica a la vista de componentes. La dependencia entre componentes es 
representada por flechas, permitiendo identificar qué componentes son afectados por otros. Los 
componentes también pueden ser representados por cualquiera de las interfaces que exponen, tales como 
la interfaces de componentes OLE/COM6 o JavaBeans7
 
 
 
 
 
 
, además los componentes pueden ser agrupados 
en paquetes conforme a su propósito u objetivo. 
 
 
 
6 Librerías compartidas de sistemas operativos Microsoft, para la definición de OLE y COM, ver la sección glosario 
7 Librearías compartidas para aplicaciones con interfaz grafica en Java 
Figura 1.7, diagrama de 
secuencia de un servidor 
de impresión. 
Figura 1.8, diagrama de 
componentes de una pantalla, 
construida con C++. 
 
UNIVERSIDAD NACIONAL AUTÓNOMA DE MÉXICO 
Campus Acatlán 
 
Tesis de licenciatura en Matemáticas Aplicadas y Computación 
 
14 
 
Diagramas de deployment.El diagrama de deployment o despliegue representa la arquitectura física de hardware y software del 
sistema, se pueden modelar las computadoras y dispositivos (nodos) actuales, incluyendo las conexiones 
que tienen entre ellos; se puede además representar el tipo de comunicación a utilizar en estas 
conexiones. Dentro de los nodos, se pueden incluir los componentes ejecutables y objetos alojados, para 
mostrar las unidades de software que se ejecutan en cada uno. 
 
Como se comentó previamente, el diagrama de deployment representa la vista de deployment, que 
describe la arquitectura física de un sistema; esto es lejano de la descripción funcional en la vista de caso 
de uso. Sin embargo, con un modelo bien definido, es posible navegar todo el camino de un nodo de la 
arquitectura del sistema hacia sus componentes y de ahí a sus clases, interacciones y finalmente casos de 
uso8
 
 
 
 
 
 
 
 
 
 
 
 
 
 
. 
 
1.7 Patrones de diseño. 
 
Hasta el momento se ha hablado acerca de los dos pilares de conocimiento del framework ORM: 
Lenguaje Java y XML, también se ha descrito y explicado el lenguaje unificado de modelado UML. Esta 
sección aterriza los conceptos planteados hasta el momento, es decir combina los conceptos de la 
programación orientada a objetos y cómo modelarla a través de UML representando patrones que dan 
solución a un problema en específico. El propósito de los patrones de diseño es recopilar la experiencia 
en el diseño orientado a objetos, para que otros puedan reutilizar estas soluciones, generando de esta 
manera un conjunto de soluciones hechas por gente experimentada, ya probadas en otros sistemas. 
 
Los patrones de diseño ayudan a escoger alternativas de modelado en la fase de diseño y otorgan 
cualidades que hacen al sistema reutilizable y eliminan las alternativas que lo comprometen. Los patrones 
de diseño pueden también mejorar la documentación y el mantenimiento de los sistemas existentes 
proveyendo una especificación explícita de clases e interacciones entre objetos, así como su 
funcionamiento implícito. En otras palabras, los patrones ayudan a realizar diseños de una manera 
correcta y rápida. 
 
 
 
 
 
8 A esto se le conoce en el Proceso Unificado de Desarrollo de software como traza 
Figura 1.9, diagrama de deployment de una aplicación cliente, servidor, tres capas (cliente, 
midleware y base de datos). 
 
 
 
 
 
 
 
 
 
 
 
UNIVERSIDAD NACIONAL AUTÓNOMA DE MÉXICO 
Campus Acatlán 
 
Tesis de licenciatura en Matemáticas Aplicadas y Computación 
 
15 
 
 
 
Definición. 
 
La definición de Chistopher Alexander, arquitecto de la industria de la construcción, de un patrón de 
diseño es: “Cada patrón describe un problema el cual aparece una y otra vez en nuestro ambiente, y se 
describe el núcleo de la solución a dicho problema, el cual es un camino para utilizar esa solución 
millones de veces, sin tener que resolverlo una y otra vez”9
 Nombre del patrón: éste puede describir el problema del diseño, su solución, y sus consecuencias en 
una o dos palabras, Nombrar un patrón incrementa inmediatamente el vocabulario de diseño. Esto 
nos permite diseñar a un alto nivel de abstracción, de manera que se tiene un vocabulario de 
patrones, y con ello se puede hablar con los colaboradores del proyecto, como si se tratase de algún 
deporte. 
. Como es de esperarse, Alexander se refería a 
patrones en construcciones y ciudades. Sin embargo también existen diferentes catálogos de patrones que 
ayudan a la industria del software; por ejemplo, existen catálogos de patrones de soluciones de análisis 
para negocios específicos, de programación, de modelos de base de datos Entidad-Relación y 
evidentemente para la fase de diseño y arquitectura de sistemas. El framework ORM tiene como base 
varios patrones de diseño que lo ayudan a ser entendible, extensible y reutilizable. 
 
Características. 
 
En general un patrón de diseño tiene cuatro elementos esenciales: 
 
 Problema: describe cuándo aplicar un patrón, explica el problema y su contexto. Debe de describir 
un problema de diseño en específico. Algunas veces el problema incluirá una lista de condiciones 
que deben conocerse antes de su uso para que tenga sentido su aplicación. 
 Solución: describe los elementos que dan forma al diseño, sus relaciones, responsabilidades y 
colaboraciones entre clases. La solución no describe un diseño en particular o una implementación 
en concreto, dado que un patrón es una plantilla que puede ser aplicada, en diferentes situaciones, en 
lugar de ello, el patrón provee una descripción abstracta de un problema de diseño con el 
agrupamiento de ciertos elementos que pueden resolverlo. 
 Consecuencias: son los resultados y los márgenes de factibilidad de aplicar un patrón. A pesar de 
que las consecuencias son raramente mencionadas cuando se describen decisiones de diseño, son 
críticas para evaluar alternativas de diseño y para entender el costo-beneficio de aplicar un patrón10
 
En resumen, los patrones son descripciones de objetos y clases intercomunicadas, que se adaptan para 
resolver un problema de diseño en un contexto particular. 
 
. 
Catálogo de patrones GoF. 
 
Existen muchos y muy diversos catálogos de patrones de diseño (por ejemplo el catálogo de patrones 
J2EE de Sun Microsystems), sin embargo todos los catálogos que el autor del presente trabajo conoce 
hacen referencia base al catálogo de patrones GoF. La palabra GoF corresponde a la contracción en inglés 
de Gang of Four (banda de los cuatro) nombre se le dio al primer grupo de diseñadores que crearon 
catálogos de patrones de diseño apegados a la tecnología de la programación orientada a objetos, el 
presente trabajo esta sustentado en el diseño de varios de los patrones de este catálogo. 
 
 
 
 
 
9 Definición descrita en el libro de Erick Gamma, Desing Patterns y reusable objects 
10 Para mayor información se puede consultar dirección www.patterndigest.com 
UNIVERSIDAD NACIONAL AUTÓNOMA DE MÉXICO 
Campus Acatlán 
 
Tesis de licenciatura en Matemáticas Aplicadas y Computación 
 
16 
 
Categorías de patrones de diseño del catálogo GoF. 
 
La siguiente es una lista de las categorías establecidas por el catálogo de patrones de diseño de GoF: 
 
 Patrones de creación- Muestran la guía de cómo crear objetos cuando sus creaciones requieren 
tomar decisiones. Estas decisiones normalmente serán resueltas dinámicamente decidiendo sobre 
que tipos de instancias de clases crear o sobre qué objetos se delegan responsabilidades (ver 
tabla 1.1). 
 Patrones estructurales - Describen la forma en que diferentes tipos de objetos pueden ser 
organizados para trabajar unos con otros (ver tabla 1.2). 
 Patrones de comportamiento- Se utilizan para organizar, manejar y combinar comportamientos 
(ver tabla 1.3). 
 
Lista de patrones de diseño GoF. 
 
La siguiente lista es una referencia parcial por categoría de los patrones GoF. 
 
Tabla 1.1, Patrones de creación. 
Nombre Descripción 
Abstract 
Factory 
 
Proporciona una interfaz para crear familias de objetos relacionados o 
dependientes sin especificar su clase concreta. 
Builder Permite a un objeto construir otro más complejo especificando sólo su tipo y 
contenido. 
Factory Method Define una interfaz para crear un objeto, dejando a las subclases decidir el tipo 
específico. 
Prototype Permite a un objeto crear instancias personalizadas sin conocer su clase exacta o 
los detalles de cómo crearlos. 
Singleton Garantiza que solamente se crea una instancia de la clase y provee un punto de 
acceso global a él. 
 
 Tabla 1.2, Patrones de estructura. 
Nombre Descripción 
Adapter 
 
Convierte la interfaz que ofrece una clase en otra esperada por los clientes. 
Bridge Desacopla una abstracción de su implementación y les permite variar 
independientemente. 
Composite Permite construir objetos complejosmediante composición recursiva de objetos 
similares. 
Decorator Extiende la funcionalidad de un objeto dinámicamente de tal modo que es 
transparente a sus clientes. 
Facade Simplifica los accesos a un conjunto de objetos relacionados proporcionando un 
objeto de comunicación. 
Flyweight Usa la compartición para dar soporte a un gran número de objetos de grano fino de 
forma eficiente. 
Proxy Proporciona un objeto con el que controlamos el acceso a otro objeto. 
 
 Tabla 1.3, Patrones de comportamiento. 
Nombre Descripción 
Chain of 
Responsability 
Evita el acoplamiento entre quien envía una petición y el receptor de la 
misma. 
Command Encapsula una petición de un comando como un objeto. 
Interpreter Dado un lenguaje, define una representación para su gramática y permite 
UNIVERSIDAD NACIONAL AUTÓNOMA DE MÉXICO 
Campus Acatlán 
 
Tesis de licenciatura en Matemáticas Aplicadas y Computación 
 
17 
Nombre Descripción 
interpretar sus sentencias. 
Iterator Acceso secuencial a los elementos de una colección. 
Mediator Define una comunicación simplificada entre clases. 
Memento Captura y restaura un estado interno de un objeto. 
Observer Una forma de notificar cambios a diferentes clases dependientes. 
State Modifica el comportamiento de un objeto cuando su estado interno cambia. 
Strategy Define una familia de algoritmos, encapsula cada uno y los hace 
intercambiables. 
Template Method Define un esqueleto de un algoritmo y delega partes concretas del mismo a 
las subclases 
Visitor Representa una operación que será realizada sobre los elementos de una 
estructura de objetos, permitiendo definir nuevas operaciones sin cambiar 
las clases de los elementos sobre los que opera. 
 
 
1.8 Mapeo de objetos a bases de datos Entidad - Relación. 
 
Esta sección es la culminación de la combinación de los conocimientos en el modelado de bases de datos 
relaciones, modelado orientado a objetos, programación en lenguajes orientados a objetos, patrones de 
diseño y UML de la figura 1.1, los cuales dan como resultado las técnicas que se mencionan aquí. 
 
El rol del DBA. 
La figura 1.10, indica que el rol que juega un DBA, cuando se está utilizando mapeo de objetos a 
relaciones y tablas, se centra en tres actividades: 
1. Mapeo (Mapping): La meta básica es determinar la estrategia efectiva para llevar a cabo la 
persistencia de objetos que representan las tablas. 
2. Implementar el mapeo (Implementing mappings): Consiste en crear los componentes necesarios 
de mapeo, tales como descriptores XML que tienen la información del mapeo entre las clases y 
las tablas los cuales deben ser mantenidos ante los posibles cambios. 
3. Realizar afinación (Performance tuning): Consiste en afinar el rendimiento de la 
implementación. 
Algo interesante de la figura 1.10, es que el DBA y los desarrolladores de la aplicación trabajan en 
conjunto en las tres actividades. Trabajando en conjunto se conduce al éxito del desarrollo de software de 
manera ágil. La realización de la afinación no es parte del alcance del presente documento por lo que no 
será comentada. 
 
 
 
 
 
Figura 1.10, Relación en la construcción de un 
sistema entre el DBA y un programador 
 
 
 
UNIVERSIDAD NACIONAL AUTÓNOMA DE MÉXICO 
Campus Acatlán 
 
Tesis de licenciatura en Matemáticas Aplicadas y Computación 
 
18 
 
Cuando se aprende a realizar el mapeo de objetos a bases de datos relacionales, el lugar para empezar de 
forma inmediata es con las propiedades de las clases. Una propiedad tiene una representación con cero o 
más columnas de una tabla en una base de datos relacional, no todas las propiedades son persistentes11
 
 y 
algunos son datos calculados, por ejemplo el promedio de un alumno no es almacenado en base de datos, 
más bien se almacenan las calificaciones. 
La manera más sencilla de realizar el mapeo es entre propiedades de clase y campos de tablas uno a uno, 
conservando las mismas características en tipos y longitudes, por ejemplo una propiedad java.lang.String 
contra un campo VARCHAR. 
La figura 1.11, representa a un diagrama de clases UML y el modelo físico de datos, ambos diagramas 
muestran un subconjunto de un modelo de dominio de un sistema general de ordenes, como se puede ver 
la propiedad DateFulfilled de la clase Order mapea a la columna dataFulFilled de la tabla Order y que 
la propiedad numberOrdered de la clase OrderItem mapea a la columna NumberOrdered de la tabla 
OrderItem. 
Mapeo meta-data 
 
La tabla 1.4, muestra los datos representando los mapeos de propiedades para persistir la información de 
las clases Order y OrderItem de la figura 1.11, Esta tabla es conocida como meta-data y este concepto es 
crítico para la funcionalidad de los framework de persistencia, los cuales son una estrategia de 
encapsulado que puede agilizar las técnicas de base de datos. 
 
 Tabla 1.4, Mapeo propiedad – columna de un sistema de órdenes. 
Propiedad Columna 
Order.orderID Order.OrderID 
Order.dateOrdered Order.DateOrdered 
Order.dateFulfilled Order.DateFulfilled 
 
11 Termino utilizado en la industria del software para indicar que algo debe ser perdurable, perdurable en base de datos, sistema operativo, etc. 
Figura 1.11, Mapeo de clases a tablas de un diagrama de clases UML a un 
físico de base de datos 
UNIVERSIDAD NACIONAL AUTÓNOMA DE MÉXICO 
Campus Acatlán 
 
Tesis de licenciatura en Matemáticas Aplicadas y Computación 
 
19 
Propiedad Columna 
Order.getTotalTax() Order.Tax 
Order.subtotalBeforeTax Order.SubtotalBeforeTax 
Order.shipTo.personID Order.ShipToContactID 
Order.billTo.personID Order.BillToContactID 
Order.lastUpdate Order.LastUpdate 
OrderItem.ordered OrderItem.OrderID 
Order.orderItems.position(orderItem) OrderItem.ItemSequence 
OrderItem.item.number OrderItem.ItemNo 
OrderItem.numberOrdered OrderItem.NumberOrdered 
OrderItem.lastUpdate OrderItem.LastUpdate 
 
Mapeo de estructuras de herencia 
 
Las base de datos relacionales no soportan propiamente la herencia, esto provoca forzar el mapeo de 
estructura de herencia dentro del esquema de objetos a un esquema de base de datos. 
El concepto de herencia da un giro interesante cuando se trata de guardar objetos dentro de una base 
de datos relacional. Y la pregunta que resalta es ¿cómo se puede organizar a los atributos heredados 
dentro del modelo?. Para contestar esta pregunta existen las siguientes técnicas: 
• Mapeo de cada jerarquía12
• Mapeo de cada clase concreta
 completa de una clase en una sola tabla – Siguiendo esta 
estrategia se almacena todos los atributos de las clases en una sola tabla. 
12
• Mapeo de cada clase a su propia tabla – Siguiendo esta estrategia, se crea una tabla por 
clase, con una columna por atributo de clase de negocio y cualquier información de 
identificación necesaria. 
 a su propia tabla – Con este esquema una tabla es creada 
por cada clase concreta, cada tabla incluye los atributos de ella y los de sus derivadas. 
• Mapeo de las clases dentro de una estructura de tabla general – Esta estrategia es para 
realizar el mapeo de estructuras de herencia en una base de datos relacional; es un enfoque 
dirigido por meta-datos para el mapeo de las clases con sus tablas respectivas. 
La tabla 1.5 muestra las ventajas y desventajas de cada técnica. 
 
 
 
 
12 Ver glosario. 
UNIVERSIDAD NACIONAL AUTÓNOMA DE MÉXICO 
Campus Acatlán 
 
Tesis de licenciatura en Matemáticas Aplicadas y Computación 
 
20 
 
 Tabla 1.5, Tabla de ventajas y desventajas en el mapeo. 
Estrategia Ventajas Desventajas Cuando usar 
Una tabla 
por jerarquía 
- Enfoque sencillo 
- Fácil de agregar nuevas 
clases, sólo se requiere 
agregar nuevas columnas para 
los datos adicionales. 
- Soporta polimorfismo 
simplemente cambiando los 
tipos del registro. 
- El acceso a la base de datos 
el rápido, dado quelos datos 
están en una tabla. 
- La realización de reportes es 
muy simple, dato que los datos 
se encuentran en una sola 
tabla. 
- La dependencia dentro de 
la jerarquía de clases se 
incrementa, dado que todas 
las clases están asociadas a 
una sola tabla. Un cambio 
en una clase puede afectar 
a la tabla única que a su 
vez impactará a las demás 
clases en la jerarquía. 
- Espacio potencial 
desperdiciado en la base de 
datos. 
- La tabla puede crecer 
rápidamente en jerarquías. 
Ésta es una buena 
estrategia para 
jerarquías simples o 
poco profundas, 
donde es poco el 
traslape entre tipos 
dentro de la 
jerarquía. 
Una tabla 
por clase 
concreta 
- La realización de reportes, 
dado que todos los datos 
necesarios están almacenados, 
accediendo por una sola clase 
y una sola tabla. 
- Buen rendimiento para 
acceso a un solo objeto de 
datos. 
- Cuando se modifica una 
clase, se necesita modificar 
su tabla asociada y todas 
las subclases involucradas. 
- Es difícil de mantener 
múltiples roles y continuar 
manteniendo la integridad 
de los datos. 
Cuando el cambio de 
tipos o traslapes entre 
los tipos es raro. 
Una tabla 
por clase 
- Fácil de entender, dado que 
se tiene un mapeo uno a uno. 
- Soporta polimorfismo, 
solamente se tienen registros 
de la tabla apropiada para cada 
clase. 
- Las súper clases son fáciles 
de modificar y añadir nuevas 
subclases que solamente 
modifican una tabla. 
- El tamaño de los datos crece 
en proporción al crecimiento 
del numero de objetos. 
 
- Hay muchas tablas en la 
base de datos, una por 
clase. 
- Potencialmente toma más 
tiempo realizar consultas, 
dado que se tienen que 
acceder a múltiples tablas; 
este problema se puede 
evitar, si se diseña 
correctamente la base de 
datos. 
- La generación de reportes 
es difícil, dado que se 
tienen que acceder a 
diferentes tablas o crear 
vistas para las consultas 
deseadas. 
Cuando hay un 
traslape significativo 
entre tipos o cuando 
el cambio de tipos es 
común. 
 
 
UNIVERSIDAD NACIONAL AUTÓNOMA DE MÉXICO 
Campus Acatlán 
 
Tesis de licenciatura en Matemáticas Aplicadas y Computación 
 
21 
 Tabla 1.2, Tabla de ventajas y desventajas en el mapeo, Continuación. 
Estrategia Ventajas Desventajas Cuando usar 
Esquema 
genérico 
- Es una ventaja cuando se 
desea encapsular la base de 
datos mediante un framework 
de persistencia. 
- Se pueden extender para 
proveer un meta-data que 
soporte un amplio rango de 
tipos de mapeo, incluyendo 
mapeo de relaciones. De 
manera rápida es el inicio de 
motor de mapeo de datos 
ORM. 
- Técnicas muy avanzadas 
que pueden dificultar su 
implantación al principio. 
- Sólo funciona para 
pequeñas cantidades de 
información, porque se 
necesita acceder a 
múltiples tablas para crear 
un solo objeto de mapeo. 
- Se necesita al menos un 
administrador que 
mantenga la información 
del meta-data. 
- La generación de reportes 
puede ser muy compleja 
dado que se requiere 
acceder a múltiples 
registros. 
Para aplicaciones 
complejas con 
cantidades pequeñas 
de información, o 
para aplicaciones 
donde el acceso a 
datos no es muy 
común o bien puede 
cargar caches13. 
 
Mapeo de relaciones de objetos. 
 
En adición a las características de mapeo de propiedades y mapeo de herencia, se necesita entender los 
conceptos de mapeo de relaciones. Hay tres tipos de relaciones entre objetos para realizar el mapeo: 
asociación, agregación y composición. 
 
Tipos de relaciones. 
Hay tres categorías de relaciones entre objetos que se necesitan conocer para el mapeo. La primera 
categoría es basa en la multiplicidad tal y como se menciono a la sección de base de datos e incluye tres 
tipos: 
• Relaciones Uno a Uno - Ésta es una relación donde el máximo de cada una de las multiplicidades 
involucradas es uno. Un ejemplo de esta relación es la definida entre Employee y Position de la 
figura 1.13. 
• Relaciones uno a muchos – También conocida como la relación de muchos a uno, esto ocurre cuando 
una de la multiplicidades es uno y la otra es mayor que uno. Un ejemplo de esta relación es la 
definida entre Employee y Division en la figura 1.13. 
• Relaciones de muchos a muchos - Ésta es una relación donde el máximo de ambas multiplicidades 
son mayor a uno. Un ejemplo de esta relación es la definida en la relación entre Employee y Task en 
la figura 1.13. 
 
 
 
13 Término utilizado en la industria del software para indicar que se almacena en memoria cierta información. 
UNIVERSIDAD NACIONAL AUTÓNOMA DE MÉXICO 
Campus Acatlán 
 
Tesis de licenciatura en Matemáticas Aplicadas y Computación 
 
22 
 
La segunda categoría esta basada en la dirección y contiene dos tipos, relaciones uni-direccionales y 
relaciones bi-direccionales: 
• Relación uni-direccional - Una relación uni-direccional es cuando un objeto conoce acerca de 
otro(s) con los que está relacionado pero los otros objetos no conocen al objeto original. Un ejemplo 
de esta relación es entre Employee y Position en la figura de abajo. 
• Relación bi-direccional - Una relación bi-direccional existe cuando los objetos involucrados en ella 
se conocen mutuamente. Un ejemplo de esta relación esta definida entre Employee y Division en la 
figura de abajo. 
 
Todos los conceptos presentados en este capitulo son la base para las fases de análisis, diseño y construcción 
de la implementación del framework ORM del presente trabajo. 
 
 
 
Figura 1.13 Diagrama de clases de una empresa la cual tiene las clases Posición, 
Empleado, actividad y división. 
UNIVERSIDAD NACIONAL AUTÓNOMA DE MÉXICO 
Campus Acatlán 
 
Tesis de licenciatura en Matemáticas Aplicadas y Computación 
 
23 
CAPITULO 2. Fase de análisis. 
 
2.1 Introducción. 
 
El objetivo del capitulo es definir el alcance del framework a desarrollar, a través de las descripciones de 
los casos de uso de desarrollo, las cuales parten de las áreas del conocimiento mencionadas en el capitulo 
uno. Cada descripción de caso de uso es realizado a través de: diagrama de casos de uso, diagramas de 
clases; diagramas de secuencia y/o diagramas de estados para encontrar las clases de análisis que serán 
base del framework. Como se mencionó en el capítulo anterior, en el Proceso Unificado de Desarrollo de 
Software, la palabra realizar significa, tomar una descripción de caso de uso y encontrar las clases de 
análisis asociadas a través de los diagramas ya mencionados. Por lo tanto se presentan inicialmente los 
grupos existentes de casos de uso llamados paquetes y para cada uno se muestra su realización. Para los 
diferentes artefactos (casos de uso, diagramas, etc.), se utiliza la siguiente nomenclatura en prefijos: CU 
en casos de uso y sus descripciones, DCU para diagramas de casos de uso, DSA y DCA para diagramas 
de secuencia de análisis y diagramas de clases de análisis, DSD y DCD para diagramas de secuencia y 
clases de diseño respectivamente, finalmente DED, DC, DD para diagramas de estados diseño, diagramas 
de componentes y diagramas de deployment. 
 
2.2 Casos de uso. 
 
Paquetes de análisis. 
 
Los paquetes2
• Componentes de acceso de base de datos y control de transacciones – Este paquete contiene las 
clases relacionadas con la abstracción del API JDBC para simplificación de su uso y el control de 
transacciones del mismo. 
 definidos a continuación tienen dos objetivos, el primero agrupa clases del framework que 
hacen uso del API JDBC, el segundo agrupa las clases de mapeo ORM, que explotan las clases del 
primer paquete para automatizar la construcción de sentencias SQL y controlar el uso de los componentes 
generales de acceso de base de datos y control de transacciones. 
 
La arquitectura del framework está dividida entonces en: 
 
 
• Componentes ORM (Object Relacional Mapping)– Paquete que contiene los componentes de mapeo 
ORM del framework 
 
Actores 
 
Para la realización de la vista de casosde uso, parte de los artefactos de análisis a encontrar son los 
actores14
 
14 Ver glosario. 
. Los actores como se menciona en el capítulo uno, sección UML, son entidades externas al 
sistema, las cuales interactúan con los casos de uso definidos. En el presente trabajo sólo existe un actor, 
el cual al igual que las descripciones de caso de uso, tiene que ver con el contexto donde se encuentra el 
framework: 
 
Clase Java - Este actor representa a cualquier clase Java que hace uso de las clases del framework. 
UNIVERSIDAD NACIONAL AUTÓNOMA DE MÉXICO 
Campus Acatlán 
 
Tesis de licenciatura en Matemáticas Aplicadas y Computación 
 
24 
 
 Casos de uso por paquete 
 
Las siguientes tablas, listan los casos de uso por paquete de análisis. Cada uno de ellos está descrito para 
el uso de JDBC o Tomcat 4.1.12 Datasource, para acceso a bases de datos. 
 
 
Tabla 2.1, Casos de uso del paquete de Componentes de acceso de base de datos y control de transacciones. 
Nombre Descripción 
CU_Abrir conexión de base 
de datos 
Realiza la apertura de una conexión de base de datos por conexión directa 
JDBC o por un Datasource. 
CU_Afectar información de 
base de datos 
Realiza el manejo de los movimientos de actualización, inserción o 
eliminación de información de la base de datos en aplicaciones. 
CU_Cerrar conexión de 
base de datos 
Realiza el cierre de una conexión de base de datos en aplicaciones ya se 
de una conexión directa vía JDBC o por un conexión de Datasource. 
CU_Consultar información 
de base de datos 
Realiza el manejo de las consultas hacia listas dinámicas por conjuntos de 
resultados de JDBC o en colecciones de objetos específicos Java desde la 
conexión de base de datos en aplicaciones. 
CU_Controlar conexión de 
base de datos 
Realiza el control de la apertura, uso y cierre de una conexión de base de 
datos en aplicaciones. 
CU_Controlar 
transacciones de base de 
datos 
Realiza el control de la apertura, commit o rollback de transacciones 
planas y anidadas de base de datos en aplicaciones. 
 
 Tabla 2.2, Casos del uso del paquete Componentes ORM 
Nombre Descripción 
CU_Actualizar información Realiza actualizaciones por llave primaria sobre una entidad de base de 
datos a través de un javaBean entidad que tiene una correspondencia 
campo a campo con la misma 
CU_Consultar información Realiza consultas completas o filtradas sobre una entidad de base de datos 
a través de una instancia de un| javaBean de entidad que tiene una 
correspondencia campo a campo con la misma 
CU_Eliminar información Realiza eliminaciones por llave primaria o por filtro sobre una entidad de 
base de datos a través de un javaBean entidad que tiene una 
correspondencia campo a campo con la misma 
CU_Insertar información Realiza inserciones sobre una entidad de base de datos a través de un 
javaBean entidad que tiene una correspondencia campo a campo con la 
misma 
CU_Mapeo de tabla de base 
de datos a clase javaBean 
entidad 
Realiza el mapeo de una tabla de base de datos sobre una entidad de una 
instancia de un javaBean de entidad 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
UNIVERSIDAD NACIONAL AUTÓNOMA DE MÉXICO 
Campus Acatlán 
 
Tesis de licenciatura en Matemáticas Aplicadas y Computación 
 
25 
Diagramas de casos de uso 
 
Las figuras 2.1 y 2.2, son diagramas de casos de uso que representan las relaciones existentes entre los 
mismos por paquete. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Figura 2.1, Diagrama de casos de uso del paquete de componentes de acceso de base de datos y 
ejecución de transacciones. 
Figura 2.2, Diagrama de casos de uso del paquete de componentes ORM. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
UNIVERSIDAD NACIONAL AUTÓNOMA DE MÉXICO 
Campus Acatlán 
 
Tesis de licenciatura en Matemáticas Aplicadas y Computación 
 
26 
 
2.2.1 Realización de los casos de uso del paquete de componentes de acceso 
de base de datos y ejecución de transacciones. 
 
La presente sección muestra las descripciones de cada uno de los casos de uso del paquete de análisis de 
componentes de acceso de base de datos y ejecución de transacciones, junto con sus diagramas de 
realización (diagramas de secuencia y clases). Los diagramas de secuencia en la fase de análisis son el 
flujo de actividades a realizar por el sistema expresado a través de mensajes entre el actor y las clases. El 
diagrama de clases simplemente indica las relaciones entre las clases encontradas. Por lo tanto cada 
actividad que es comentada mientras dialoga el actor con el sistema en la descripción de caso de uso, 
debe estar reflejada en la realización de sus diagramas de secuencia, dependiendo las características del 
caso de uso, la realización puede necesitar uno o varios diagramas de secuencia de análisis. 
 
Requerimientos Generales del paquete. 
 
Conexiones. 
 
El framework debe soportar el uso de conexiones directas de base de datos o a través de fuentes de datos 
(Datasource) es decir, para obtener una conexión de base de datos a través del API JDBC debe ocupar 
cualquiera de las siguientes formas: 
 
Conexión directa JDBC – Este tipo de conexión obtiene un canal exclusivo de comunicación con la base 
de datos, es decir, este tipo de conexión crea un enlace con la base de datos por cada instancia del 
programa en ejecución. 
 
Conexión JDBC por fuente de datos (Datasource) – Este tipo de conexión obtiene un canal exclusivo 
temporal de comunicación con la base de datos, es decir, este tipo de conexión obtiene un canal de 
acceso a base de datos a través de un componente que |controla y administra el número de conexiones 
disponibles y así tener control del acceso y demanda del número total de conexiones para la aplicación, 
es decir, este esquema permite agilizar el uso de las conexiones reales a utilizar, e incrementa el 
rendimiento de los programas ya que el tiempo invertido en obtener conexiones directas menos eficiente. 
 
Comportamiento general del uso de conexiones y transacciones de base de datos. 
 
El diagrama de secuencia de la figura 2.3, representa el comportamiento del framework a construir 
cuando diferentes instancias de objetos necesitan utilizar una conexión de base de datos. El diagrama 
muestra como la instancia Z crea una conexión de base de datos y en su ejecución, hace uso de la 
instancia X a través de la llamada al método XXX, el cual también crea una conexión de base de datos, 
ambos métodos en las instancias Z y X cierran la conexión de base de datos utilizada, el objetivo del 
framework en este punto es hacer que la instancia de la conexión de base de datos en Z y X sea la misma 
de manera transparente evitando así el uso excesivo de conexiones y finalmente conservar la integridad 
de dicha conexión permitiendo cerrar solo la conexión a la instancia creadora de la misma, en el caso de 
la figura 2.3, el creador de la conexión es instancia Z, esto sí y solo sí las conexiones pertenecen a la 
misma base de datos de lo contrario existirán dos creadores de conexión y el framework mantendrá de 
igual manera su integridad. 
 
 
 
 
 
 
 
 
UNIVERSIDAD NACIONAL AUTÓNOMA DE MÉXICO 
Campus Acatlán 
 
Tesis de licenciatura en Matemáticas Aplicadas y Computación 
 
27 
El diagrama de secuencia de la figura 2.4, representa el comportamiento del framework a construir 
cuando diferentes instancias de objetos crean transacciones y las inician, consolidando o deshaciendo la 
misma. El diagrama muestra cómo la instancia Z crea una transacción y en el transcurso de la secuencia 
la instancia Z, hace uso de la instancia Y a través de llamar al método XXX el cual también crea una 
transacción ambos métodos en las instancias Z e Y controlan sus transacciones. El objetivo del 
framework en este punto es hacer que cada una de las transacciones anidadasen la secuencia den como 
resultado una sola coordinada por la transacción mas exterior en el caso del diagrama la transacción 
controlada por la instancia X, esto sí y solo si las transacciones pertenecen a la misma base de datos. 
 
 sd DSA_Escenario de transacciones anidadas
Base de datosInstancia Y :Clase Java
«worker»
Instancia X :Clase Java
«worker»
Instancia Z :Clase Java
«worker»
:Clase Java
«worker»
La clasa java, crea una 
instancia de la clase X, y 
abre la transaccion principal
Transacción 
anidada nivel 2
( BD1 - Hilo1 )
Transacción 
anidada nivel 2 
( BD 1 - Hilo 1 )
Incio transaccion 
principal nivel 1 
(BD1 - Hilo1)
Terminar transaccion principal 
nivel 1 (BD 1 - Hilo 1)
Name: DSA_Escenario de transacciones anidadas
Author: Guillermo Cabrera Bernal
Version: 1.0
Created: 08/07/2003 12:00:00 a.m.
Updated: 21/08/2003 12:00:00 a.m.
<<Instanciación X>>
<< Lllamada al metodo XXX >>
<< Abre Transaccion >>
<< Instanciacion Z >>
<< Llamada al metodo ZZZ >>
<< Abre Transaccion >>
<< Sentencia SQL >>
<< Se hace commit o rollback >>
<< Instanciacion Y >>
<< Llamada al metodo YYY >> << Abre Transaccion >>
<< Sentencia SQL >>
<< Se hace commit o rollback >>
<< Se hace commit o rollback >>
 
Figura 2.3, Escenario de reutilización de conexiones. 
Figura 2.4, Escenario de control de transacciones anidadas. 
UNIVERSIDAD NACIONAL AUTÓNOMA DE MÉXICO 
Campus Acatlán 
 
Tesis de licenciatura en Matemáticas Aplicadas y Computación 
 
28 
 
 
Cada descripción de caso de uso del presente paquete considera el uso de los dos escenarios de 
obtención de conexión y los escenarios de uso de la conexión y transacciones en un hilo de ejecución y 
estas características serán heredadas al paquete de componentes ORM. 
 
 
Descripción del caso de uso “CU_Controlar conexión de base de datos”. 
 
Objetivo 
El caso de uso tiene como objetivo el control de la apertura, uso y cierre de una conexión de base de 
datos en aplicaciones utilizando JDBC o Tomcat 4.1.12 Datasource para acceso a bases de datos 
Tipo Concreto Abstracto 
 
Actores 
• Clase Java 
 
Precondiciones 
Se debe conocer la información de la base de datos a utilizar (Conforme al driver de cada provedor). 
 
• Nombre de la base de datos. 
• IP o nombre del servidor donde esta el RDBMS de base de datos. 
• Servidor de instancia a utilizar. 
• Puerto de acceso. 
• Driver del JDBC. 
 
Relaciones 
Nombre del Caso de Uso Tipo de Relación 
CU_Abrir conexión de base de datos <include> 
CU_Cerrar conexión de base de datos <include> 
 
Curso básico 
 
1. Una clase java solicita una conexión de base de datos indicando el nombre de la base de datos a la 
que se quiere el acceso. 
2. El servicio de conexiones por hilo intenta abrir la conexión, para el hilo de ejecución actual (ver caso 
de uso CU_Abrir conexión de base de datos). 
3. Si el servicio de conexiones por hilo pudo obtener la conexión se le asigna a la clase java que la 
solicito. 
3.1. La clase java puede hacer uso de la conexión, ejecutando sentencias SQL, para realizar altas, 
cambios y consulta de registros y tablas, así como las transacciones (ver casos de uso 
CU_Consultar Información de base de datos, CU_Afectar información de base de datos y 
CU_Controlar Transacciones de base datos). 
3.2. La clase Java puede solicitar al servicio de conexiones por hilo cerrar la conexión del hilo de 
ejecución actual independientemente si tiene una conexión JDBC o por Datasource (ver caso de 
uso CU_Cerrar conexión de base de datos). 
4. Termina caso de uso. 
 
Curso alterno 
NO APLICA 
 
Curso de excepción 
NO APLICA 
UNIVERSIDAD NACIONAL AUTÓNOMA DE MÉXICO 
Campus Acatlán 
 
Tesis de licenciatura en Matemáticas Aplicadas y Computación 
 
29 
 
 
Poscondiciones 
La clase java obtuvo, utilizó y liberó una conexión de base de datos 
 
Diagramas de clase y secuencia. 
 
Las figuras 2.5 y 2.6, son los diagramas de clase y secuencia de la descripción del caso de uso. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Figura 2.5, Diagrama de clases que muestra la relación estática para el control de la apertura, 
uso y cierre de una conexión de base de datos en aplicaciones utilizando JDBC o Tomcat 
4.1.12 Datasource para acceso a bases de datos, para mayor claridad en este diagrama se 
representan los componentes de conexión relacionados. 
Figura 2.6, Diagrama de secuencia que muestra el comportamiento entre objetos para el 
control de la apertura, uso y cierre de una conexión de base de datos en aplicaciones 
utilizando JDBC o Tomcat 4.1.12 Datasource para acceso a bases de datos. 
UNIVERSIDAD NACIONAL AUTÓNOMA DE MÉXICO 
Campus Acatlán 
 
Tesis de licenciatura en Matemáticas Aplicadas y Computación 
 
30 
 
Descripción del caso de uso “CU_Abrir conexión de base de datos”. 
 
Objetivo 
El caso de uso tiene como objetivo abrir una conexión de base de datos en aplicaciones utilizando 
JDBC o Tomcat 4.1.12 Datasource para acceso a bases de datos 
Tipo Concreto Abstracto 
 
Actor 
• Clase Java 
 
Precondiciones 
 
El caso de uso sólo puede ser iniciado a partir del caso de uso CU_Controlar de conexiones de base 
de datos. 
 
Relaciones 
Nombre del Caso de Uso Tipo de Relación 
No aplica No aplica 
 
Curso básico 
 
1. El curso básico inicia cuando una clase java solicita al control de conexiones una conexión de base 
de datos. 
2. Si la clase java no indica el nombre de la base de datos a utilizar y en el control de conexiones ya 
existe una conexión para el hilo de ejecución actual, como consecuencia de la creación de 
conexiones anidadas entre métodos de diferentes instancias de clase en el mismo hilo de ejecución 
(ver: Figura 2.3). 
2.1. El control de conexiones devuelve la conexión existente a la clase java que la solicitó. 
2.2. El control de conexiones registra a la clase java solicitante no es creadora de la conexión en el 
control de conexiones. 
2.3. Si no se puede realizar la obtención de la conexión, se emite el mensaje de excepción 
relacionado de la base de datos o de la clase. 
2.4. De lo contrario, se termina el curso básico del caso de uso. 
3. Si la clase java indica el nombre la base de datos a utilizar y existe en el control de conexiones una 
conexión a la misma base de datos solicitada en el hilo de ejecución actual, como consecuencia de la 
creación de conexiones anidadas entre métodos de diferentes instancias de clase en el mismo hilo de 
ejecución (ver: Figura 2.3). 
3.1. El control de conexiones devuelve la conexión existente a la clase java que la solicito. 
3.2. El control de conexiones registra que la clase java solicitante no es la creadora de la conexión 
en el control de conexiones. 
3.3. Si no se puede realizar la obtención de la conexión se emite el mensaje de excepción 
relacionado de la base de datos o de la clase. 
3.4. De lo contrario, se termina el curso básico del caso de uso. 
4. Si la clase java no indica el nombre de base de datos a utilizar. 
4.1. El control de conexiones busca en la configuración la primer definición de base de datos para la 
aplicación y obtiene el nombre correspondiente. 
4.2. Si no existe información definida para base en la configuración. 
4.2.1. Ir a cursos de excepción Error de configuración ninguna base de datos. 
4.3. De lo contrario. 
4.3.1. El control de conexiones toma al nombre definido en la configuración como el nombre 
de base de datos indicado por la clase java. 
UNIVERSIDAD NACIONAL AUTÓNOMA DE MÉXICO 
Campus Acatlán 
 
Tesis de licenciatura en Matemáticas Aplicadas y Computación 
 
31 
5. Si el control de conexiones está configurado para obtener conexiones vía JDBC y se conoce la base 
de datos solicitada. 
5.1. El control de conexiones obtiene la información de driver, usuario, contraseña y URL a utilizar