Académique Documents
Professionnel Documents
Culture Documents
Página i
Preparado por el Grupo Investigación Istar- Versión 1.0 – 12/03/2008
Ingeniería de Sistemas ISTAR – CIS1210IS05
CIS1210IS05
Persistencia transparente a BDOO (Bases de Datos Orientadas a Objetos) para pro-
gramadores de objetos.
Autor:
Jeisson Fabian Perez Rodriguez
Director
Julio Ernesto Carreño Vargas
Jurados del Trabajo de Grado
Alvaro Quintero
Maria Consuelo Frankin
Página web del Trabajo de Grado
http://pegasus.javeriana.edu.co/~CIS1210IS05
Página ii
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Aplicación Práctica
Rector Magnífico
Página iii
Preparado por el Grupo Investigación Istar- Versión 1.0 – 12/03/2008
Ingeniería de Sistemas ISTAR – CIS1210IS05
“La Universidad no se hace responsable de los conceptos emitidos por sus alumnos en sus
proyectos de grado. Sólo velará porque no se publique nada contrario al dogma y la moral
católica y porque no contengan ataques o polémicas puramente personales. Antes bien, que
se vean en ellos el anhelo de buscar la verdad y la Justicia”
Página iv
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Aplicación Práctica
AGRADECIMIENTOS
Agradezco de corazón a mi familia pero en especial a mi mamá por haber sido la promotora
durante estos años en la universidad, quien con su esfuerzo logro que yo pudiera estudiar en
esta universidad tan prestigiosa.
A todos mis compañeros, con los que compartí momentos agradables en esta etapa de mi
vida.
Al Ingeniero Julio Ernesto Carreño, por la colaboración prestada para el desarrollo de este
trabajo de grado.
Página v
Preparado por el Grupo Investigación Istar- Versión 1.0 – 12/03/2008
Ingeniería de Sistemas ISTAR – CIS1210IS05
CONTENIDO
CONTENIDO ............................................................................................................. VI
TABLA DE ILUSTRACIONES........................................................................................... X
INTRODUCCIÓN .......................................................................................................1
IV - RESULTADOS ...................................................................................................29
1. FORMULACIÓN Y SELECCIÓN .....................................................................................29
1.1 Análisis y definición de requerimientos....................................................................... 29
1.2 Selección y evaluación de componentes ...................................................................... 32
Página vi
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Aplicación Práctica
VI - REFERENCIAS .................................................................................................65
Página vii
Preparado por el Grupo Investigación Istar- Versión 1.0 – 12/03/2008
Ingeniería de Sistemas ISTAR – CIS1210IS05
ABSTRACT
Sometimes the object developers have the needle of persist objects they use in their applica-
tions, with the purpose of having records or saved data. But they need additional require-
ments such as learning new languages like “SQL” or complex management of possible per-
sistence tools.
This work presents a component (Graphic, API), responsible for managing the transparent
persistence to Object Oriented Databases.
RESUMEN
Los programadores de objetos, algunas veces, tienen la necesidad de persistir los objetos que
utilizan en sus aplicaciones, esto con el fin de tener registros o datos guardados. Pero necesi-
tan requisitos adicionales como el aprendizaje de nuevos lenguajes como “SQL” o el manejo
complejo de las herramientas de persistencia posibles.
Este trabajo de grado presenta un componente (Grafico, API), encargado de gestionar la per-
sistencia transparente a Bases de datos Orientadas a objetos.
Página viii
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Aplicación Práctica
RESUMEN EJECUTIVO
Este documento presenta los aspectos más importantes del trabajo de grado de ingeniería de
sistemas: “Persistencia Transparente a BDOO (Bases de Datos Orientadas a Objetos) para
programadores de objetos”.
Las aplicaciones Java que necesitan manejar datos los cuales deben perdurar, plantean un
escenario donde el usuario debe aprender dos tipos de lenguajes, el lenguaje Java, y el len-
guaje específico del motor de base de datos, esto además conlleva a que el usuario deba
aprender el modo de integración entre estos dos lenguajes teniendo en cuenta la forma de
traspasar los tipos de un lenguaje hacia otro [23].
Se busco suplir esta necesidad planteando una arquitectura basada en componentes que facili-
tara el acceso transparente a las bases de datos orientadas a objetos desde el lenguaje de pro-
gramación Java, el cual se cumplió con la arquitectura del componente Transper, resultado
final de este trabajo de grado.
Página ix
Preparado por el Grupo Investigación Istar- Versión 1.0 – 12/03/2008
Ingeniería de Sistemas ISTAR – CIS1210IS05
Tabla de Ilustraciones
Página x
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Aplicación Práctica
Tabla de tablas
Tabla 1: Cuadro comparativo tipo Bases de Datos [3][8] ....................................................... 13
Página xi
Preparado por el Grupo Investigación Istar- Versión 1.0 – 12/03/2008
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Aplicación Práctica
INTRODUCCIÓN
Este documento muestra el proceso de desarrollo del trabajo de grado: “Persistencia trans-
parente a BDOO (Bases de Datos Orientadas a Objetos) para programadores de obje-
tos”, donde se tuvo como finalidad la construcción de un componente de persistencia transpa-
rente para bases de datos orientadas a objetos, (Transper), que permitiera al usuario (progra-
mador), realizar operaciones de creación, lectura, actualización, y guardado de objetos sobre
este tipo de base de datos.
Este documento está dividido en cinco secciones, que tratan los siguientes temas:
La sección 1, “Descripción general del trabajo de grado”, contiene como primera instancia la
oportunidad o problemática que se encontró junto con sus antecedentes, en esta parte se inicia
en una descripción del contexto, luego la formulación del problema que se resolvió, para
proseguir con la justificación del proyecto. Luego se continúa con la descripción del proyec-
to, donde se expone una visión global junto con los objetivos (general y específicos) de este
proyecto, estos objetivos soportados, con las fases metodológicas planteadas.
La sección 3, “Desarrollo del trabajo”, muestra las actividades que se realizaron en cada fase
metodológica planteada, donde se aborda cada uno de los conceptos desde una perspectiva
general para llegar a una específica, que en este caso es la validación sobre el caso de estudio
planteado.
Página 1
En esta sección se encuentra una visión general de la arquitectura y el diseño planteados para
el desarrollo del componente, además la especificación del caso de estudio “AYLLU-AES”,
con el cual se realizo la respectiva validación.
La sección 4, “Resultados”, expone los resultados obtenidos en cada una de las fases plantea-
das, estructurada de forma tal que el contenido este generalmente descrito, destacando los
puntos fundamentales, que son manejados en profundidad dentro de los documentos anexos
de este Trabajo de Grado.
Página 2
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Aplicación Práctica
Existen varias herramientas que facilitan el proceso de persistencia entre objetos y bases de
datos, algunas de estas herramientas siguen en su proceso el patrón del mapeo Obje-
to/Relacional. Dentro de este patrón se facilita el mapeo de atributos entre una base de datos
relacional tradicional y el modelo de objetos de una aplicación [1].
Entre algunos de los problemas o desventajas que posee el modelo de base de datos objeto
relacional, se encuentra: la complejidad y el coste, modelo indexado del modelo relacional y
sobre todo se observa que los valores no son completamente orientados a objetos [2], [3].
Las aplicaciones Java que necesitan manejar datos que deben perdurar, plantean un escenario
donde los programadores están obligados a utilizar y conocer detalladamente diferentes técni-
cas de acceso e interfaces de programación para cada uno de los sistemas de datos empleados
[23]. Esto conlleva al aprendizaje de dos tipos de lenguajes para colocar la lógica del negocio
en una aplicación (El lenguaje Java y el lenguaje específico del motor de base de datos), por
otra parte el programador debe tener en cuenta que debe aprender el modo de integración
entre estos dos lenguajes sin que haya errores de tipo en los datos manejados en cada uno.
Esto implico el desarrollo de otro tipo de herramientas que facilitan este proceso en un méto-
do directo, en otras palabras, realizar la persistencia en bases de datos orientadas a objetos,
sin utilizar mapeos relacionales, además, con la condición de no generar la tabla en la base de
datos, sino que el objeto fuese guardado directamente dentro de esta. [1], [4].
En el rango de estas últimas herramientas se observa que no se ofrece una vista amigable de
manejo para el programador, esto conlleva a que el usuario que utiliza estas herramientas
deba aprender a manejarlas o deba tener conocimientos previos sobre el manejo de estas.
Página 3
1.3 Justificación
A pesar de que hay componentes que gestionan el acceso a las bases de datos orientadas a
objetos,
Al tener un componente intermedio entre los programadores y la base de datos, facilita a los
programadores tener disminución de su código, además el rendimiento en cuanto al tiempo de
la operaciones CRUD aumentase ya que las consultas a la base de datos pueden ser más rápi-
das.
Página 4
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Aplicación Práctica
Ante esta necesidad de persistencia de objetos planteada, y el poco conocimiento que el pro-
gramador de objetos tiene sobre el manejo de las BDOO (detalles de persistencia en la Base
de Datos), se propuso un componente que satisfaga de forma cabal estas necesidades.
Este componente se propuso también con el fin de que el programador de objetos no tuviera
la necesidad de aprender a manejar las operaciones básicas (Creación, Actualización, Borrado
y Lectura de objetos) que se practican en una base de datos.
Página 5
El componente (Gráfico, API) “Transper”, producto de este trabajo de grado, permitirá a los
programadores realizar la persistencia de objetos a bases de datos orientadas a objetos, espe-
cíficamente a una base de datos DB4O. Por medio de la parte Grafica, este componente so-
porta la gestión de operaciones básicas de una base de datos (Operaciones CRUD) sobre los
objetos que se gestionen en un proyecto de software, además soporta la generación de código
de estas operaciones como un plus; y por medio del API, se ofrece una serie de funciones que
ayudan a suplir la necesidad de persistencia para un programador de objetos.
Plantear una arquitectura basada en componentes que facilite el acceso transparente a las
bases de datos orientadas a objetos desde el lenguaje de programación JAVA.
Fase 3: Construcción.
Fase 4: Verificación.
Página 6
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Aplicación Práctica
El objetivo principal del Trabajo de grado fue plantear una arquitectura basada en componen-
tes, como se especifico en el punto 2.2 de esta sección, esto conllevo a utilizar un modelo del
ciclo de vida de CBD (Component-Based Development). Este es el segundo modelo presen-
tado en la sección del Marco Teórico, punto 2.1.8.4. A continuación se muestra dicho mode-
lo, donde cada una de sus etapas fue utilizada dentro del desarrollo del componente:
Cabe resaltar que dentro de cada una de las fases metodológicas propuestas para este trabajo
de grado se encuentra una o varias etapas del modelo iterativo, esto con el fin de soportar las
actividades propuestas desde un entorno de desarrollo de componentes, esto está estructurado
de la siguiente forma:
Fase 1: Formulación y selección: Para suplir esta fase se utilizó la metodología de investi-
gación descriptiva. En esta fase se realizó las etapas N° 1 y 2 del modelo iterativo, estas son:
Página 7
Fase 2: Creación de Solución: Para esta fase se utilizó la metodología de investigación des-
criptiva, las etapas del modelo iterativo asociadas a esta fase son:
Fase 4: Verificación: Para esta fase se utilizó la metodología de investigación junto con la
siguiente etapa del modelo iterativo:
Página 8
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Aplicación Práctica
II - MARCO TEÓRICO
1. Contextual
A continuación se ofrece un contexto global del caso de estudio que fue aplicado en la sec-
ción de verificación de este documento:
Ayllu-AES es un proyecto que está enmarcado dentro de los proyectos de investigación del
grupo SiDRE de la Pontificia Universidad Javeriana.
AES (Acrónimo de Agentes para Enriquecer Servicios), es un framework que adapta infor-
mación que puede ser usada por cualquier aplicación que necesita enriquecer servicios con el
propósito de recuperar información que mejor se ajuste a las necesidades, características y
contexto del usuario [19].
2. Conceptual
En esta sección se define los términos más relevantes que serán eje central de este documen-
to, dando así, el entendimiento, por parte del lector, de los conceptos utilizados en las diferen-
tes secciones.
Definición de:
Página 9
Bases de datos
o Bases de datos relacionales.
o Bases de datos Objeto/relacional.
o Bases de datos orientadas a objetos.
Ejemplo de bases de datos
FLOOT
Component-Based-Development (CBD).
o Definición
o Principios Básicos
o Niveles de un componente en CBD
o Ciclo de vida del CBD
o CBD en Java
Las bases de datos y la tecnología de bases de datos hoy en día son un componente esencial
de la vida cotidiana, hasta tal punto que no somos conscientes de estar usándolas. Estas tienen
mucha culpa del uso creciente de los computadores, se puede decir que las Bases de datos son
muy importantes ya que permiten el almacenamiento de grandes cantidades de información,
la recuperación rápida y flexible de información, la organización y reorganización de la in-
formación y la impresión y distribución de información en varias formas [2].
Una base de datos representa algún aspecto del mundo real, lo que en ocasiones se denomina
minimundo o universo de discurso (UoD, Universe of discourse) [2]. Las bases de datos se
diseñan, construyen y rellenan con datos para un propósito especifico, además son una colec-
ción de datos persistentes que son usados por aplicaciones de algunas compañías (comercial,
científica, técnica, u otro tipo de organización) [1].
Página 10
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Aplicación Práctica
Las bases de datos Relacionales (RDB – Relational Data-Base), están basadas en una funda-
ción formal, o teoría llamada modelo de Bases de Datos relacional (RDM – Relational Data-
Base Model) [1]. Este Modelo (RDM) representa a la base de datos como un conjunto de
relaciones. Informalmente cada una de estas relaciones se parece a una tabla de valores o, de
forma algo más extensa, a un fichero plano de registros [3].
Cuando una relación está pensada como una tabla de valores, cada fila representa una colec-
ción de valores relacionados. Por tanto, las bases de datos relacionales tienen 3 principios
fundamentales [1]:
Estructural: Los datos en la base de datos son percibidos por los usuarios como tablas
y nada más que tablas.
Integridad: Estas tablas satisfacen o cumplen ciertas restricciones.
Manipulación: Los operadores disponibles para el usuario para la manipulación de
esas tablas, son operadores que derivan tablas de tablas.
En este modelo relacional, una fila recibe el nombre de tupla, una cabecera de columna es un
atributo y el nombre de la tabla una relación.
Estas bases de datos están definidas por los modelos de Bases de Datos Relacional y Orienta-
da a Objetos. Los fabricantes de los Sistemas de Bases de Datos Relacionales eran conscien-
tes de la amenaza que generaba el Modelo de Bases de Datos Orientado a Objetos (OODBM)
sobre el tradicional Modelo de Bases de Datos relacional, y por dicha razón, ampliaron estas
Bases de Datos con la suficiente funcionalidad para cubrir las demandas de esas aplicaciones,
Página 11
y rechazaron los argumentos de quienes dicen que ese tipo de sistemas ampliados no tendrían
funcionalidad suficiente para poder tratar adecuadamente con aplicaciones tan complejas [3].
Las bases de Datos Orientadas a Objetos (OODB – Object Oriented), tienen sus orígenes en
los lenguajes de programación de objetos, donde las ideas básicas de los lenguajes son tam-
bién aplicadas en estas Bases de Datos [1]. Son consideradas la competencia directa de las
Bases de Datos Relacionales.
Esta Base de Datos está diseñada con respecto en el Modelo de Objetos. Este Modelo es un
modelo abstracto independiente del diseño, que se utiliza para comunicarse con sistemas
orientados a objetos compatibles con OMG (Object Management Group) [3]. Además sobre
este modelo están basados el lenguaje de definición de objetos y el lenguaje de consulta de
objetos.
Página 12
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Aplicación Práctica
Página 13
Para el proceso de pruebas del proyecto se hace necesario el uso de la siguiente metodología:
Esta metodología es una colección de técnicas de pruebas para verificar y validar software
orientado a objetos. Esto enmarcado en el trabajo de grado, se ve reflejado en las pruebas que
Página 14
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Aplicación Práctica
La prueba verifica que el ítem que se está probando, cuando se dan las
Prueba de Caja-Negra
entradas apropiadas, produce los resultados esperados.
Prueba de Valores- Es la prueba de situaciones extremas o inusuales que el ítem debe ser
Frontera capaz de manejar.
Página 15
Página 16
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Aplicación Práctica
2.1.7.1 Definición
Especificaciones externas.
Código Ejecutable.
Código de Validación.
De la definición anterior se puede derivar uno de los beneficios que hay al utilizar CBD, este
es que un componente al relacionarse con otros componentes no necesita ser recompilado
para funcionar exitosamente.
Página 17
Como los componentes son independientes, estos no deben interferir con otros.
Las implementaciones de los componentes están ocultas para el usuario.
La comunicación entre componentes es a través de interfaces bien definidas.
Las plataformas de componentes son compartidas para reducir el costo de desarrollo.
Un componente está formado por los siguientes niveles (Estos niveles están adaptados a partir
del concepto de un componente de negocios [15]):
Página 18
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Aplicación Práctica
CBD tiene varios tipos de modelos de “life-cycle”, entre los más reconocidos se encuentra
“Y-Model” y el “Modelo Iterativo”, a continuación se especifica cada uno:
Página 19
El modelo “Y” ha sido propuesto como una alternativa viable para hacer frente a la reutiliza-
ción de software durante la producción de software basado en componentes. La creación de
software se caracteriza por el cambio y la inestabilidad, de esta forma, la representación es-
quemática del modelo “Y” considera la superposición y la iteración cuando sea apropiado.
La siguiente tabla detalla cada una de las fases del Modelo “Y” [17]:
“Framewor- Un “framework” puede ser definido como una estructura genérica que especi-
king” fica un esqueleto para la producción de software en una aplicación de dominio
determinada. Este proceso debe identificar los componentes y percibir las
Página 20
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Aplicación Práctica
relaciones más significativas entre ellos. Esta fase puede ahorrar mucho tiem-
po puesto que la definición del framework puede acercar el desarrollo a otros
similares y a componentes que pueden aumentar la productividad. La cons-
trucción del sistema a partir del “framework” es mucho más beneficiosa y
rápida que empezar sin una idea clara de esta estructura.
Archivar El desarrollo del sistema no sólo debe utilizar componentes ya hechos, tam-
bién debe incluir una etapa en donde se realiza un análisis de cuáles de los
componentes que se desarrollaron para este sistema pueden ser generalizados
para una reutilización potencial. En esta fase, se deben categorizar, documen-
tar y almacenar aquellos componentes que están pensados para ser reutiliza-
dos. Para lograr que este almacenamiento realmente sea útil, puede ser más
beneficioso si es organizado en “frameworks” según el tipo de componente y
su funcionalidad.
Página 21
Pruebas Una vez que los componentes están listos y completamente implementados, la
fase de pruebas debe incluir pruebas en solitario y junto al sistema completo.
Existen variadas técnicas que pueden utilizarse, tales como pruebas de caja
blanca, de caja negra, inspección de código, pruebas formales. Una vez que
los componentes han sido probados, es necesario también asegurar que el
código utilizado para definir su interacción funciona correctamente. Después
de que todo esto ha sido aprobado, debe existir una verificación de que el
componente y sus relaciones cumplen con la funcionalidad esperada y obtie-
nen los resultados definidos como legítimos. Dependiendo del perfil del sis-
tema se pueden realizar pruebas de desempeño, de aceptación, de calidad, de
instalación y de seguridad.
Mantenimiento La vida del sistema de software no termina cuando se hace la entrega al clien-
te. Los cambios y los nuevos requerimientos pueden aparecer pronto, esta fase
debe garantizar que cuando estos casos se presenten, la adaptabilidad del sis-
tema sea la suficiente y la extensibilidad permita esta flexibilidad.
Página 22
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Aplicación Práctica
Etapa Descripción
Esta etapa debe identificar y describir los requerimientos que deben satisfa-
cer el sistema. Esta actividad usualmente contiene tres tareas: la primera de
Análisis y defini- ellas se encarga de la recolección de requerimientos y la definición de los
ción de requeri- límites del sistema; la segunda, consiste en la definición de una infraestruc-
mientos tura que permita la colaboración ente componentes y la tercera es la defini-
ción de requerimientos de componentes para su posterior selección y desa-
rrollo.
Selección y eva- Esta fase debe especificar los componentes que serán utilizados y la funcio-
luación de com- nalidad de cada uno de ellos. Deben especificarse las interfaces y estudiar e
ponentes investigar los componentes que podrían ser reutilizados y su integración.
Página 23
Java es una de las plataformas que soporta el desarrollo basado de componentes. Esto es por-
que con esta plataforma se puede estructurar cada componente independiente de otros, y
Página 24
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Aplicación Práctica
además se puede realizar una estructura de integración entre varios componentes desarrolla-
dos para dar como resultado un componente final integrado.
Java tiene características que lo diferencian de otras plataformas, y que benefician y facilitan
el desarrollo basado en componentes, algunas de estas son [10]:
Independencia de plataforma
Carga Dinámica
CCM – Corba Component Model: Es un modelo de componentes del lado del ser-
vidor, para crear y desplegar aplicaciones CORBA. Es muy similar a EJB ya que uti-
liza los patrones de diseño y esto facilita su uso, lo que permite una gran cantidad de
código generable [12].
Página 25
Fractal tiene como objetivo principal reducir los costos de desarrollo, despliegue y
mantenimiento de sistemas informáticos en general y proyectos de forma ObjectWeb
en particular [14].
Página 26
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Aplicación Práctica
1. Formulación y selección
Respondiendo al primer objetivo especifico propuesto, en esta fase se realizó el análisis de los
requerimientos funcionales y no funcionales, así como la selección de los componentes auxi-
liares que podrían servir para la implementación del componente “Transper”, producto final
de este trabajo de grado.
2. Creación de Solución
Para el cumplimiento del objetivo N° 2, el cual está relacionado con esta fase, se realizó el
diseño de la arquitectura del componente “Transper”, así como el documento con la especifi-
cación de los diagramas arquitecturales (Diagramas de casos de uso, de componentes, Im-
plementación y Lógico) que soportan la implementación de este componente en la siguiente
fase.
3. Construcción
Página 27
4. Verificación
Esta fase tenía asociado el objetivo específico N° 4, para suplir este objetivo se realizó la
especificación del caso de estudio de “Ayllu” y las pruebas con este caso de estudio, además
se realizó el análisis de los resultados de estas pruebas.
Página 28
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Aplicación Práctica
IV - RESULTADOS
1. Formulación y selección
En esta sección se define los resultados obtenidos para la fase N° 1 planteada para el trabajo
de grado. Se comienza exponiendo los resultados sobre el análisis y definición de requeri-
mientos, para luego continuar con los resultados de la selección de componentes.
A continuación se muestra un diagrama junto con una tabla donde se especifica los requeri-
mientos funcionales:
Página 29
REQ01: Transper deberá permitir importar todas las clases que se encuentren en un proyecto
java, esto para realizar la persistencia en la BDOO.
REQ02: Transper deberá permitir crear instancias de objetos sobre las clases importadas,
estas instancias se utilizaran para realizar la persistencia en la BDOO.
REQ04: Transper deberá generar reporte de Log en archivo plano de errores que se generen
en tiempo de ejecución.
REQ05: Transper deberá generar Log de auditoría en archivo plano por cada consulta
CRUD realizada a la BDOO.
Página 30
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Aplicación Práctica
REQ07: Transper deberá permitir la ejecución de alguna de las operaciones CRUD con Ob-
jetos en la BDOO.
REQ08: Transper soportara la construcción de consultas tipo QBE a una BDOO para cada
una de las operaciones CRUD.
REQN02: Transper debe presentar mensajes de error que permitan al usuario identificar el
tipo de error.
Página 31
REQN03: Transper debe brindar una interfaz grafica de usuario de fácil manejo.
REQN04: Transper deberá estar completamente documentado, cada uno de los subcompo-
nentes de software que forman parte de la solución propuesta deberán estar debidamente
documentados tanto en el código fuente como en los manuales de usuario.
REQN05: Transper deberá ser lo suficientemente robusto para poder controlar las excepcio-
nes y posibles errores de cualquier tipo que puedan presentarse en algún proceso por factores
internos o externos.
REQN06: Transper debe poder ejecutarse bajo cualquier plataforma de sistemas operativos
que soporten tecnología Java
REQN07: Transper deberá tener manejo de logs y auditoria para el registro de las consultas
hechas a la base de datos.
En esta etapa se realizó la selección de los componentes que podrían complementar la fun-
cionalidad de Transper.
La siguiente tabla muestra los componentes más importantes que fueron consultados, además
se muestra los seleccionados, estos últimos resaltados en color azul:
JGraphX Esta es una librería Java de código fuente abierto para la visua-
lización y diseño de gráficos.
Página 32
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Aplicación Práctica
Swing: Fue seleccionado ya que esta soportado en el lenguaje Java, y tiene tanto documenta-
ción como tutoriales de uso en internet. Además para la implementación se tiene una gran
experiencia utilizando este componente.
2. Creación de solución
En esta sección se define los resultados obtenidos para la fase N° 2 planteada para el trabajo
de grado. Se debe tener en cuenta que esto abarca el diseño de la arquitectura planteada desde
un punto de vista global, incluyendo los siguientes diagramas (Contexto Arquitectónico, Ca-
sos de Uso, Lógico e Implementación), el anexo “Documento Component Based Develop-
ment” ofrece un detalle completo de la arquitectura planteada.
2.1 Diseño
Página 33
Logging: Este componente está encargado del completo manejo de logs, los cuales muestran
el comportamiento de las funcionalidades más relevantes del Sistema Total.
db4o: Base de datos Orientada a Objetos seleccionada para persistir los objetos que el usuario
desee.
Página 34
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Aplicación Práctica
Este diagrama muestra los casos de uso que fueron planteados para Transper, se ofrece una
explicación general de cada uno de los casos de uso.
A continuación se ofrece una especificación general de cada uno de los casos de uso expues-
tos en el anterior Diagrama de Casos de Uso.
Página 35
El criterio para definir los casos de uso arquitecturalmente significantes, se definió con base
al número de relaciones que tiene el caso de uso con los demás casos de uso, a continuación
se muestra la tabla con los datos generados a partir del diagrama de Casos de Uso expuesto
anteriormente:
Página 36
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Aplicación Práctica
Realizar operaciones 4
CRUD (Actualizar Objetos, Crear Obje-
tos, Eliminar Objetos, Leer Obje-
tos).
Editar Objetos 0
Generar Log 0
En esta parte de la sección 2 se ofrece los diagramas dinámicos y secuenciales que componen
la parte lógica del componente, estos diagramas pertenecen a los casos de uso arquitectural-
mente significantes, que fueron seleccionados de los casos de uso propuestos en el numeral
2.1.2 Diagrama de Casos de Uso, de la presente sección.
Diagrama Dinámico:
Página 37
Diagrama Estático:
Página 38
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Aplicación Práctica
Ejecutar Consulta
Diagrama Dinámico:
Diagrama Estático:
Página 39
En esta parte se ofrece un diagrama de implementación que muestra las diferentes capas que
se utilizaron para la realización del componente, partiendo desde la capa de presentación,
luego continuando con la capa lógica y por último con la capa de persisntencia.
Página 40
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Aplicación Práctica
Este diagrama contiene las capas de Presentación, Lógica y Persistencia, en donde cada una
tiene una responsabilidad diferente, a continuación se muestra una explicación global sobre
cada una de estas:
Capa Presentación:
Página 41
Capa Lógica:
Para esta capa se tiene los subcomponentes que brindan la lógica de Transper, lógica de las
diferentes funcionalidades que el usuario puede realizar. Por otra parte también se encuentra
la lógica para realizar los registros de Logging sobre las consultas que sean generadas y reali-
zadas a la base de datos.
Capa de Persistencia:
En esta capa se encuentra la lógica para generar la persistencia en la BDOO. Los subcompo-
nentes de esta capa se encargan tanto de recibir los diferentes parámetros para realizar la con-
sulta como de realizar la persistencia,-aplicando los diferentes mecanismos de persistencia
con objetos (QBE, SODA)-, a la BDOO db4o.
3. Construcción
En esta sección se define los resultados obtenidos para la fase N° 3 planteada para el trabajo
de grado. Se inicia con los resultados referentes a la implementación de los componentes
adicionales que suplieran las funcionalidades de Transper, propuestas en el punto 1.1 de la
sección “Resultados”; para terminar con la integración de estos componentes implementados
y los componentes externos seleccionados, y tener como resultado final a Transper.
3.1 Implementación
Página 42
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Aplicación Práctica
Como se explicó en el punto 2.1 de esta sección, este componente está encargado de la com-
pleta funcionalidad de los logs.
3.2 Integración
En esta parte del proceso, haciendo referencia a la metodología FLOOT, expuesta en el punto
2.1.6 de la sección “Marco Teórico”, luego de finalizar la integración de todos los componen-
Página 43
tes, se realizo pruebas de integración que consistió en verificar que todo el componente fun-
cionaba correctamente.
4. Verificación
En esta sección se define los resultados obtenidos para la fase N° 4 planteada para el trabajo
de grado. Se comienza con la especificación del caso de estudio propuesto para validar
Transper, luego se procede con los resultados y análisis de las pruebas realizadas sobre este
caso de estudio y sobre el componente en general.
En el caso de estudio del proyecto Ayllu-AES, cuya definición y contexto global esta especi-
ficado en el punto 1 de la sección “Marco Teórico”, se tiene la necesidad de persistir objetos
en bases de datos. Actualmente la base de datos que se está utilizando es una base de datos
Relacional, llamada “postgres”.
En esta etapa de la sección de verificación y validación se muestra los escenarios que se utili-
zaron para realizar las pruebas y obtener los resultados expuestos en la siguiente etapa Vali-
dación del Componente Transper.
Luego de un análisis realizado sobre estos dos proyectos se obtuvo como resultado los obje-
tos que se persisten en tablas en la base de datos, para cada uno de ellos se muestra una sec-
ción del código implementado con el fin de utilizar datos estadísticos en la siguiente etapa,
estos objetos fueron:
Página 44
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Aplicación Práctica
Página 45
Además se obtuvo los archivos que gestionan la persistencia a la base de datos, estos archivos
fueron:
Página 46
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Aplicación Práctica
Y por último, en los archivos anteriores se obtuvo los métodos de persistencia implementa-
dos, de los cuales se muestra el código de implementación para utilizar datos estadísticos en
la validación de resultados, para dar como resultado:
Página 47
Página 48
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Aplicación Práctica
Página 49
Cabe aclarar que también se encontró métodos que no estaban implementados, por dicho
motivo no se tienen en cuenta para las pruebas, estos métodos fueron:
persist
Luego de seleccionar y analizar los proyectos a utilizar, se procedió a realizar las respectivas
pruebas de verificación y validación con el caso de estudio.
En primer lugar, para realizar estas pruebas, se realizo un proyecto nuevo llamado
“AES_EjemploOVA_Transper”, que contenía solamente los archivos necesarios para realizar
persistencia a la base de datos, archivos que fueron tomados del proyecto
“AES_EjemploOVA”, esto con el fin de comparar resultados entre un proyecto y otro.
Página 50
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Aplicación Práctica
La ilustración 9 muestra la comparación entre los dos proyectos utilizando el archivo Perfil-
DispositivoJpaController, y haciendo referencia al número de líneas que se necesito para
suplir la funcionalidad de persistencia sobre cada uno de los métodos. Se puede observar que
al utilizar el componente Transper, se obtiene una reducción de casi el 70% en líneas de
código para consultas específicas, pero así mismo se obtiene un aumento de casi el 60% en
líneas de código para consultas generales.
Página 51
Así mismo, la ilustración 10 muestra la misma comparación anterior, pero esta vez utilizando
el archivo PerfilEstudianteJpaController. Se puede observar que se obtiene resultados pareci-
dos a los de la anterior grafica, estos son: una reducción de más del 70% para consultas espe-
cíficas, y un aumento del 60% para consultas generales.
La ilustración 11 muestra la comparación de estos proyectos, pero esta vez haciendo referen-
cia al número de anotaciones necesarias para cumplir con los requisitos de persistir el objeto
en su respectiva base de datos. Esta comparación da como resultado que al utilizar Transper,
Página 52
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Aplicación Práctica
se puede obtener una disminución de casi el 92% de las anotaciones utilizadas en perfilDis-
positivo y de casi el 95% de las anotaciones utilizadas en perfilEstudiante.
Se debe mencionar que al realizar las pruebas con Transper, se registro dos tiempos por cada
consulta, el primero hace relación al tiempo gastado en consultar los objetos a una base de
datos local donde se proporciona solamente el nombre de la base de datos, y el segundo hace
referencia al tiempo gastado en consultar los objetos a una base de datos servidor donde se
proporciona la dirección remota, el puerto por donde escucha la base de datos, el usuario, y la
contraseña.
Página 53
A continuación se expone los resultados obtenidos para los dos objetos (PerfilEstudiante y
PerfilDispositivo), todos los resultados de esta prueba están medidos en milisegundos.
La tabla 10 expone los resultados obtenidos al realizar la consulta por Nombre dispositivo.
La tabla 12 muestra los resultados para la consulta listarDispositivos, la cual consulta todos
los registros de la base de datos que sean dispositivos.
En esta parte se debe mencionar que la columna N° 1 muestra el número de registros agrega-
dos a la base de datos, antes de realizar esta consulta.
Página 54
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Aplicación Práctica
La tabla 13 abarca los resultados obtenidos al realizar la consulta por Nombre Estudiante.
Como se menciono con la tabla 12, esta tabla contiene los registros de la consulta listarEstu-
diantes, que se encarga de realizar la consulta de todos los registros de tipo Estudiante en la
base de datos.
Página 55
Página 56
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Aplicación Práctica
Las ilustraciones 15, 16 y 17 reflejan el mismo comportamiento que las anteriores ilustracio-
nes, por tal motivo no se explica estos resultados.
Página 57
A continuación se procede con las pruebas sobre las funciones de persistir, eliminar y actuali-
zar de Transper, comparándolo con funciones de prueba implementadas que utilizan la persis-
tencia hacia una base de datos relacional.
Como primera instancia se tiene los resultados para la función de persistir, la cual consiste en
guardar los objetos hacia la base de datos. La tabla 15 muestra estos resultados.
PERSIST
Modelo de Base de Modelo de Base de datos
Número
datos Relacional Orientada a Objetos (t/ms)
Registros
(t/ms) Local Servidor
1 1558 222 773
10 2222 181 858
20 2779 275 1011
30 3839 357 1206
40 4078 496 1381
50 4898 550 1703
60 5571 673 1556
70 6148 738 1646
80 6410 806 1831
90 7267 962 1975
100 7458 1057 2370
200 13547 2367 3633
Página 58
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Aplicación Práctica
Además se puede observar que el tiempo gastado para la función de transper que realiza la
persistencia hacia una base de datos local es muy parecido al tiempo gastado por la función
de este mismo componente que realiza la persistencia a una base de datos servidor.
La tabla 17 muestra los resultados para la función de eliminación hacia las bases de datos
relacional y orientada a objetos.
DELETE
Página 59
En la ilustración 19 se puede observar que el tiempo gastado en la función eliminar sobre una
base de datos relacional es mucho mayor sobre la función eliminar de Transper.
Además se puede observar que el tiempo entre la función de Transper hacia una base de datos
local no cambia mucho al tiempo gastado de la función de Transper hacia una base de datos
servidor.
La tabla 18 muestra los resultados para la función de actualización hacia las bases de datos
relacional y orientada a objetos.
Página 60
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Aplicación Práctica
UPDATE
Modelo de Base Modelo de Base de datos Orien-
de datos Relacio- tada a Objetos
nal Local Servidor
1736 120 256
Asimismo se puede observar que el tiempo entre la función de Transper hacia una base de
datos servidor duplica el tiempo gastado de la función de Transper hacia una base de datos
servidor.
Página 61
4.1.3 Manuales
Se debe resaltar que en la fase N° 4, también se obtuvo como resultado los manuales de insta-
lación “Manual de instalación Transper” y guía de usuario “Manual de Usuario Transper”,
que comprenden la instalación y correcto manejo de Transper, esto se realizo con el fin de
suplir el requerimiento no funcional REQN04, expuesto en el punto 1.2 de esta sección.
Página 62
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Aplicación Práctica
1. Conclusiones
Los objetivos expuestos al inicio de Trabajo de grado se cumplieron, dando como re-
sultado el componente Transper.
El componente Transper pudo ser completamente aplicado en el caso de estudio Ay-
llu-AES, proyecto por el cual nació la creación de este Trabajo de grado.
Partiendo de los resultados obtenidos en las pruebas, se puede deducir que Transper,
hecho para una base de datos orientada a objetos, es eficiente para los programadores
en términos de líneas de código, a comparación de un componente hecho para una
base de datos relacional.
De estos resultados obtenidos, también se deduce que Transper puede llegar a ser de-
ficiente o de bajo rendimiento cuando los datos que se gestionan en la base de datos
son demasiados y se requiera realizar una consulta general.
Por último y no menos importante, se deduce de estos resultados, que con respecto a
funciones de persistir, eliminar o actualizar, Transper es muy eficiente a comparación
de persistir, eliminar y actualizar hacia una base de datos relacional.
Estas conclusiones pueden ser un motivo importante para el programador a la hora de
seleccionar el tipo de base de datos.
2. Recomendaciones
Para el desarrollo de componentes se debe tener en cuenta factores importantes, como el
tiempo otorgado al proyecto, el manejo de los de riesgos propuestos y el tratamiento y los
ajustes que puedan ser necesarios a la hora de afrontar un retraso en el cronograma.
Es recomendable tratar de mantener una comunicación constante con las personas encargadas
del caso de estudio propuesto, esto con el fin de resolver dudas y ofrecer sugerencias para los
que desarrollan el proyecto.
Página 63
3. Trabajos Futuros
Este trabajo de grado, así como con el caso de estudio puede ser parte de proyectos donde se
necesite persistir objetos.
La continuación del proyecto para que este soporte otro tipo de base de datos orientadas a
objetos, hace que esta sea una posible mejora y por tanto un proyecto.
Página 64
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Aplicación Práctica
VI - REFERENCIAS
[1] C. J. Date. (2000). AN INTRODUCTION TO DATABASE SYSTEMS. Massachusetts.
Menlo Park, California. Harlow, England Don Mills.
[6] P. Kruchten. (2001). The Rational Unified Process An Introduction, Addison Wes-ley.
[9] Gamma E, Helm R., Johnson R., and Vlissides J. Design Patterns: Elements of Reusable
Object-Oriented Software. Addison Wesley, 1994.
Página 65
[16] Gamma E, Helm R., Johnson R., and Vlissides J. Design Patterns: Elements of Reusable
Object-Oriented Software. Addison Wesley, 1994.
[17] Componente de software libre para la limpieza de datos en Data Mining. Trabajo de
Grado, Ingeniería de Sistemas. Pontificia Universidad Javeriana.
[18] L.F. Capretz . Y: A New Component-Based Software Life Cycle Model. London, Onta-
rio. 2005.
[21] E. F. Codd. (1970). A Relational Model of Data for Large Shared Data Banks. IBM Re-
search Laboratory, San Jose, California.
[23] J. M. Castillo. Persistencia de Objetos, JDO solución Java. Recurso Web. Disponible en:
http://dis.um.es/~jmolina/Persistencia%20de%20Objeto%20JDO.pdf Consultado por última
vez: 15 de Julio de 2012
Página 66
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Aplicación Práctica
VII - ANEXOS
Anexo 1. Post-Mortem
Anexo 2. Documento de Component-Based Development
Anexo 4. Archivo .zip que contiene los archivos que soportan las
pruebas realizadas.
Página 67