Vous êtes sur la page 1sur 81

CIS1210IS05

Persistencia transparente a BDOO (Bases de Datos Orientadas a Objetos) para programa-


dores de objetos.

Jeisson Fabian Perez Rodriguez

PONTIFICIA UNIVERSIDAD JAVERIANA


FACULTAD DE INGENIERIA
CARRERA DE INGENIERIA DE SISTEMAS
BOGOTÁ, D.C.
2012
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Aplicación Práctica

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

MEMORIA DEL TRABAJO DE GRADO REALIZADO PARA CUMPLIR UNO


DE LOS REQUISITOS PARA OPTAR AL TITULO DE INGENIERO DE
SISTEMAS

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

PONTIFICIA UNIVERSIDAD JAVERIANA


FACULTAD DE INGENIERIA
CARRERA DE INGENIERIA DE SISTEMAS
BOGOTÁ, D.C.
Julio, 2012

Página ii
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Aplicación Práctica

PONTIFICIA UNIVERSIDAD JAVERIANA


FACULTAD DE INGENIERIA
CARRERA DE INGENIERIA DE SISTEMAS

Rector Magnífico

Joaquín Emilio Sánchez García S.J.

Decano Académico Facultad de Ingeniería

Ingeniero Luis David Prieto Martínez

Decano del Medio Universitario Facultad de Ingeniería

Padre Sergio Bernal Restrepo S.J.

Director de la Carrera de Ingeniería de Sistemas

Ingeniero Germán Alberto Chavarro Flórez

Director Departamento de Ingeniería de Sistemas

Ingeniero César Julio Bustacara Medina

Página iii
Preparado por el Grupo Investigación Istar- Versión 1.0 – 12/03/2008
Ingeniería de Sistemas ISTAR – CIS1210IS05

Artículo 23 de la Resolución No. 1 de Junio de 1946

“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

TABLA DE TABLAS ....................................................................................................... XI

INTRODUCCIÓN .......................................................................................................1

I - DESCRIPCION GENERAL DEL TRABAJO DE GRADO................................3


1. OPORTUNIDAD, PROBLEMÁTICA, ANTECEDENTES......................................................3
1.1 Descripción del contexto ............................................................................................... 3
1.2 Formulación del problema que se resolvió ................................................................... 4
1.3 Justificación................................................................................................................... 4
1.4 Impacto Esperado.......................................................................................................... 5
2. DESCRIPCIÓN DEL PROYECTO .....................................................................................6
2.1 Visión global.................................................................................................................. 6
2.2 Objetivo general ............................................................................................................ 6
2.3 Fases Metodológicas o conjunto de objetivos específicos ............................................ 6
2.4 Método que se propuso para satisfacer cada fase metodológica .................................. 7

II - MARCO TEÓRICO ..............................................................................................9


1. CONTEXTUAL ..............................................................................................................9
2. CONCEPTUAL ..............................................................................................................9
2.1 Fundamentos y conceptos relevantes para el proyecto. ................................................ 9

III – DESARROLLO DEL TRABAJO ....................................................................27


1. FORMULACIÓN Y SELECCIÓN .....................................................................................27
2. CREACIÓN DE SOLUCIÓN ...........................................................................................27
3. CONSTRUCCIÓN.........................................................................................................27
4. VERIFICACIÓN ...........................................................................................................28

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

2. CREACIÓN DE SOLUCIÓN ...........................................................................................33


2.1 Diseño.......................................................................................................................... 33
3. CONSTRUCCIÓN.........................................................................................................42
3.1 Implementación ........................................................................................................... 42
3.2 Integración .................................................................................................................. 43
4. VERIFICACIÓN ...........................................................................................................44
4.1 Verificación y Validación ............................................................................................ 44

V – CONCLUSIONES, RECOMENDACIONES Y TRABAJOS FUTUROS .....63


1. CONCLUSIONES .........................................................................................................63
2. RECOMENDACIONES ..................................................................................................63
3. TRABAJOS FUTUROS..................................................................................................64

VI - REFERENCIAS .................................................................................................65

VII - ANEXOS ............................................................................................................67


ANEXO 1. POST-MORTEM .............................................................................................67
ANEXO 2. DOCUMENTO DE COMPONENT-BASED DEVELOPMENT .................................67
ANEXO 3. DOCUMENTO ESPECIFICACIÓN DE REQUERIMIENTOS ....................................67
ANEXO 4. ARCHIVO .ZIP QUE CONTIENE LOS ARCHIVOS QUE SOPORTAN LAS PRUEBAS
REALIZADAS. .................................................................................................................67

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.

Después de plantear la arquitectura y realizar la respectiva implementación del componente,


se procedió a realizar la verificación y validación, donde se tuvo como eje principal el caso de
estudio planteado “Ayllu-AES”, finalizando con el análisis de los resultados obtenidos, donde
se concluyo que es viable utilizar Transper en aplicaciones donde no se maneje un gran can-
tidad de datos, y se necesiten pocas líneas de código para implementar su respectiva persis-
tencia.

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

Ilustración 1: Interacción Componente, Usuario, Base de datos. ............................................. 4

Ilustración 2: Modelo Iterativo de CBD ................................................................................... 7

Ilustración 3: Ciclo de Vida de Floot [7] ................................................................................ 16

Ilustración 4: Niveles de un componente CBD ....................................................................... 18

Ilustración 5: Interacciones entre cada nivel de un componente CBD ................................... 19

Ilustración 6 Ciclo de vida Modelo "Y" de CBD.................................................................... 20

Ilustración 7: Ciclo de vida Modelo Iterativo de CBD ........................................................... 23

Ilustración 8: Diagrama de Contexto Arquitectónico ............................................................. 34

Ilustración 9: Esfuerzo número de líneas PerfilDispositivoJpaController .............................. 52

Ilustración 10: Esfuerzo número de líneas PerfilEstudianteJpaController.............................. 52

Ilustración 11: Esfuerzo en número de anotaciones necesarias para persistir......................... 53

Ilustración 12: Consultar por Id Dispositivo ........................................................................... 56

Ilustración 13: Consulta por Nombre Dispositivo .................................................................. 56

Ilustración 14: Consultar Todo perfilDispositivos .................................................................. 57

Ilustración 15: Consulta por Nombre Estudiante .................................................................... 57

Ilustración 16: Consulta por Id Estudiante.............................................................................. 57

Ilustración 17: Consulta todo Estudiantes ............................................................................... 58

Ilustración 18: Pruebas sobre la función persistir ................................................................... 59

Ilustración 19: Pruebas sobre la función de eliminación ........................................................ 60

Ilustración 20: Pruebas sobre la función de actualización ...................................................... 61

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

Tabla 2: Tipos de bases de datos............................................................................................. 14

Tabla 3: Técnicas de prueba FLOOT [7] ................................................................................ 16

Tabla 4: Fases del Modelo "Y" [17] ....................................................................................... 22

Tabla 5: Etapas del Modelo Iterativo [17] .............................................................................. 24

Tabla 6: Tabla de Requerimientos Funcionales ...................................................................... 31

Tabla 7: Tabla de Requerimientos No Funcionales ................................................................ 32

Tabla 8: Tabla con los componentes consultados ................................................................... 33

Tabla 9: Prueba de Esfuerzo Número de líneas y Anotaciones .............................................. 51

Tabla 10: Resultado Consulta por Nombre Dispositivo ......................................................... 54

Tabla 11: Resultado Consulta por Id Dispositivo ................................................................... 54

Tabla 12: Resultado Consultar todo Dispositivos ................................................................... 54

Tabla 13: Resultado Consulta por Nombre Estudiante ........................................................... 55

Tabla 14: Resultado Consulta por Id Estudiante ..................................................................... 55

Tabla 15: Resultado Consultar todo Estudiante ...................................................................... 55

Tabla 16: Resultados función de persistir objetos .................................................................. 59

Tabla 17: Resultados función eliminación .............................................................................. 60

Tabla 18: Resultados función actualizar ................................................................................. 61

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.

Como primera instancia se realizo un proceso de investigación de diferentes componentes


que suplieran esta necesidad de persistencia. El análisis desarrollado determino la importan-
cia de este trabajo de grado como un aporte para los programadores de objetos que tengan la
necesidad de persistir los datos que utilizan en sus aplicaciones.

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 2, “Marco Teórico”, muestra los conceptos fundamentales y necesarios para el


entendimiento de los documentos expuestos en el trabajo de grado, todo esto dentro de los
marcos contextual y conceptual.

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

Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008


Ingeniería de Sistemas ISTAR – CIS1210IS05

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.

La sección 5, “Conclusiones, Recomendaciones y Trabajos futuros”, muestra las conclusiones


y experiencias del proceso desarrollado en este trabajo de grado, las recomendaciones que se
deben tener para los trabajos a futuro que se puedan desarrollar sobre este proyecto.

Página 2
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Aplicación Práctica

I - DESCRIPCION GENERAL DEL TRABAJO DE GRADO

1. Oportunidad, Problemática, Antecedentes

1.1 Descripción del contexto

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

Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008


Ingeniería de Sistemas ISTAR – CIS1210IS05

1.2 Formulación del problema que se resolvió

¿Cómo ofrecer a un programador de objetos, acceso persistente y transparente a las bases de


datos orientadas a objetos?

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.

Ilustración 1: Interacción Componente, Usuario, Base de datos.

Como se muestra en la ilustración anterior con el componente intermedio entre el programa-


dor y la base de datos, el programador ya no tendrá que conocer el lenguaje de la base de
datos ni el de la aplicación que gestiona esta base de datos, ya que el componente debería
permitir gestionar los objetos de la base de datos y mostrárselos al usuario de manera tanto
grafica como en texto plano.

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.

1.4 Impacto Esperado

El presente proyecto tuvo como finalidad:

 Disminuir tiempos en programación cuando se requiera utilizar las bases de datos


orientadas a objetos, ya que, a comparación del tiempo utilizado para aprender a ma-
nejar una base de datos relacional, el usuario no necesita gastar mucho en la utiliza-
ción de esta herramienta propuesta.
 Para los proyectos en la Universidad donde se necesite persistencia transparente de
objetos, tener una reducción en tiempo de aprendizaje sobre nuevas herramientas de
ayuda, y un aumento en términos de productividad, entre el usuario y el componente,
ya que, el usuario no debe gastar muchas líneas de código en sus aplicaciones para
suplir la necesidad de persistencia, esto es porque se reduce hasta en un 90% el costo
de desarrollo de persistencia [22].

El impacto a Corto, mediano y largo plazo, dentro de la Universidad, es:

Corto Plazo: Ofrecer a pequeños proyectos de grupos de investigación universitarios una


forma de persistir transparentemente objetos en caso de necesitarse

Mediano y Largo Plazo: Vincular el proyecto con grandes proyectos de la Universidad,


donde se maneje esta necesidad de persistencia.

Página 5

Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008


Ingeniería de Sistemas ISTAR – CIS1210IS05

2. Descripción del Proyecto

2.1 Visión global

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.

2.2 Objetivo general

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.

2.3 Fases Metodológicas o conjunto de objetivos específicos


 Fase 1: Formulación y selección.

Esta fase contiene el objetivo específico N° 1.

o Objetivo 1: Formular los requerimientos funcionales y no funcionales del


componente.

 Fase 2: Creación Solución.

Para esta fase se tiene el objetivo específico N° 2.

o Objetivo 2: diseñar las capas arquitecturales del componente.

 Fase 3: Construcción.

Esta fase tiene el objetivo específico N° 3.

o Objetivo 3: Construir el componente basado en la arquitectura planteada.

 Fase 4: Verificación.

Página 6
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Aplicación Práctica

Esta fase contiene el objetivo específico N° 4.

o Objetivo 4: Verificar la funcionalidad del componente sobre un aplicativo


que tenga las necesidades de persistencia que se reflejan en el componente,
en este caso el aplicativo es el proyecto AYLLU-AES.

2.4 Método que se propuso para satisfacer cada fase metodológica

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:

Ilustración 2: Modelo Iterativo de CBD

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

Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008


Ingeniería de Sistemas ISTAR – CIS1210IS05

 Análisis y definición de requerimientos: Se identificaron los requerimientos que de-


bían satisfacer el componente.
 Selección y evaluación de componentes: Se seleccionaron los componentes junto con
su funcionalidad que podría servir para el desarrollo de Transper.

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:

 Diseño: Se realizó el diseño de la arquitectura de Transper junto con el documento


donde se especifica los diagramas arquitecturales definidos para Transper.

Fase 3: Construcción: En esta fase se utilizó la metodología de investigación y la de Pro-


gramación Orientada a Objetos, las etapas del modelo iterativo asociadas a esta fase son:

 Implementación: Se realizó la implementación de componentes que cumplieran los


requisitos y funcionalidades propuestas.
 Integración: Se realizó la integración de los componentes planteados junto con los
desarrollados para la construcción del Transper.

Fase 4: Verificación: Para esta fase se utilizó la metodología de investigación junto con la
siguiente etapa del modelo iterativo:

 Verificación y validación: Transper fue verificado y validado, donde se determinó si


este cumple con los requerimientos definidos en la primera etapa, además se compro-
bó que este componente funcionara correctamente, y por último se validó con el caso
de estudio del proyecto AYLLU AES.

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:

El grupo de investigación SIDRe (Acrónimo de Sistemas de Información, Sistemas Distribui-


dos y Redes) del departamento de Ingeniería de Sistemas de la Pontificia Universidad Jave-
riana, trabaja en proyectos e investigaciones relacionadas con las áreas de Sistemas Distribui-
dos y Redes, además realiza actividades científicas y académicas que permiten apropiar y
ampliar el conocimiento y las tecnologías para el estudio, desarrollo y aplicación de sistemas
informáticos con un enfoque distribuido [24].

Ayllu-AES es un proyecto que está enmarcado dentro de los proyectos de investigación del
grupo SiDRE de la Pontificia Universidad Javeriana.

Ayllu es una plataforma de cooperación mediada por agentes, aplicada en un contexto de E-


learning Colaborativo [20].

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.

2.1 Fundamentos y conceptos relevantes para el proyecto.

Definición de:

Página 9

Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008


Ingeniería de Sistemas ISTAR – CIS1210IS05

 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

2.1.1 Bases de datos

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].

Un sistema de bases de datos es básicamente un sistema de mantenimiento de registros


computarizado, este puede ser considerado como un archivador electrónico. De la misma
forma también es un repositorio, o contenedor para una colección de archivo de datos compu-
tarizados [1]. Este facilita los procesos de definición, construcción, manipulación y comparti-
ción de bases de datos entre varios usuarios y aplicaciones [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 se pueden clasificar en:

 Bases de Datos Relacionales (RDB).


 Bases de Datos Objeto/Relacional (ORDB).
 Bases de Datos Orientadas a Objetos (OODB).

2.1.2 Bases de Datos Relacionales (RDB)

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.

2.1.3 Bases de Datos Objeto/Relacional (ORDB)

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

Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008


Ingeniería de Sistemas ISTAR – CIS1210IS05

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].

2.1.4 Bases de Datos Orientadas a Objetos (OODB)

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.

Ahora, aumentando el nivel de abstracción es incuestionablemente un objetivo digno, y el


paradigma de objetos ha tenido mucho éxito en el cumplimiento de ese objetivo en el campo
de los lenguajes de programación [4].

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

2.1.5 Cuadro Comparativo y Ejemplos

Tabla 1: Cuadro comparativo tipo Bases de Datos [3] [8]

En la siguiente tabla se colocan algunos ejemplos de estos tipos de bases de datos:

Tipos de Bases de Datos

Tipo Nombre Descripción

Crear Bases de Datos y programas para


Access
controlar y administrar la información.

Base de Datos relacional desarrollada por


Microsoft SQL Server
Relacional Microsoft.

Se ejecuta como un servidor proveyendo


MySQL a los multiusuarios acceso a numerosas
bases de datos.

Página 13

Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008


Ingeniería de Sistemas ISTAR – CIS1210IS05

Base de datos Relacional desarrollada


SQLBase
por Gutpa Technologies.

Base de Datos Relacional, producida por


Oracle DataBase
Oracle Company.

Base de Datos Relacional, producida por


Oracle DataBase
Oracle Company.

Combina diferentes tipos de sistemas de


OpenLink Virtuoso
bases de datos en uno solo.
Object/Relacional
Base de Datos Objeto Relacional que
PostgreSQL está disponible para diferentes platafor-
mas.

Base de Datos Relacional desarrollada


IBM informix
por IBM.

Base de Datos creada para técnicas orien-


ObjectStore
tadas a objetos.

Base de Datos de objetos creada para


ObjectDB
Java.

Versant Object Databa- Base de Datos de objetos clasificada de


se grado Empresarial.
Object Oriented
Base de Datos Orientada a Objetos, para
Zope Object DataBase
persistirlos en Python.

Base de Datos Orientada a Objetos de


Perst
tipo Open Source.

Motor de base de datos orientada a obje-


DB4O
tos, (DataBase for Objects).
Tabla 2: Tipos de bases de datos

Para el proceso de pruebas del proyecto se hace necesario el uso de la siguiente metodología:

2.1.6 FLOOT (The Full Life Cycle Object-Oriented Testing)

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

se utilizaron para verificar y validar el componente desarrollado. A continuación se aborda


algunas de las técnicas más importantes que utiliza esta metodología:

Técnica FLOOT Descripción

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.

Es el acto de validar que un componente funciona tal como está defini-


Prueba de Componente
do.

Consiste en realizar pruebas para verificar que un gran conjunto de


Prueba de Integración
partes del software funcionan juntas.

Consiste en realizar pruebas para verificar que un método (función


Prueba de Método
miembro) funciona tal como está definido.

Consiste en realizar pruebas para verificar la capacidad de trabajo de la


Prueba de Rendimiento aplicación, donde se tenga que exponer a esta a trabajar un 100% de su
capacidad.

Una técnica de aseguramiento de la calidad en la cual el diseño de tu


aplicación es revisado de forma exhaustiva por un grupo de tus compa-
Revisión Técnica ñeros. Una revisión típicamente se enfoca en la precisión, calidad, faci-
lidad de uso y completitud. A este proceso usualmente se le llama reco-
rrido, inspección, o revisión de compañeros.

Consiste en probar la interfaz de usuario para garantizar que cumple los


Prueba de Interfaz de
estándares y requerimientos definidos. Usualmente se refiere a la prue-
Usuario
ba de interfaz de usuario gráfica.

Página 15

Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008


Ingeniería de Sistemas ISTAR – CIS1210IS05

Consiste en realizar pruebas para verificar que líneas específicas de


Prueba de Caja-Blanca código funcionan tal como está definido. También se le conoce como
prueba de caja-transparente.

Tabla 3: Técnicas de prueba FLOOT [7]

A continuación se detalla una ilustración del ciclo de vida de FLOOT:

Ilustración 3: Ciclo de Vida de Floot [7]


2.1.7 Component-Based-Development (CBD)

Esta forma de programación es la que se utilizo en el desarrollo de Transper, a continuación


se muestra su teoría.

El desarrollo basado en componentes, (CBD, por sus siglas en Ingles Component-based-


Development), es la forma más prometedora para controlar el alto costo y la gran compleji-
dad que se presenta en sistemas de información de negocios [15]. Este desarrollo tiene como
objetivo principal la reutilización de software existente, para de esta forma mejorar la calidad
y rendimiento del software.

Página 16
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Aplicación Práctica

2.1.7.1 Definición

Un componente, el cual es el centro de CBD, es una unidad independiente de despliegue, una


unidad para la composición de terceros, y no tiene estado persistente [9]. En otras palabras, el
componente puede ser fácilmente separado de su ambiente o de otros componentes, y puede
ser colocado junto con otros componentes, dependiendo de las necesidades.

Un componente contiene los siguientes elementos [9]:

 Una lista de interfaces que son provistas para el entorno.

 Una lista de interfaces que son requeridas del entorno.

 Especificaciones externas.

 Código Ejecutable.

 Código de Validación.

 Diseño (Documentos y código fuente)

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.

Otros beneficios de CBD son:

 Es un proceso de desarrollo que está orientado a la reutilización.


 Permite desarrollo autónomo por partes
 Cubre todo el ciclo de vida de un software.
 Un CBD maduro reducirá fuertemente el tiempo en el mercado (time-to-market) de
un desarrollo de software.
 Generación de estándares en los componentes para facilitar la integración entre ellos.
 Generación de componentes independientes para proveer servicios especificados por
sus interfaces.
 Como los componentes son independientes se genera pruebas independientes por
cada componente para luego probar el sistema completo [17].

Página 17

Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008


Ingeniería de Sistemas ISTAR – CIS1210IS05

2.1.7.2 Principios Básicos

CBD está basado en unos principios de diseño de software:

 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.

2.1.7.3 Niveles de un Componente en CBD

Un componente está formado por los siguientes niveles (Estos niveles están adaptados a partir
del concepto de un componente de negocios [15]):

Ilustración 4: Niveles de un componente CBD

 User Tier: Este es el encargado de toda la comunicación entre el componente y el


usuario. Es responsabilidad de u-tier implementar y ejecutar los paneles y controles
de la interfaz de usuario del componente.
 Workspace Tier: Este soporta el nivel de usuario (user Tier), implementa la lógica
de negocio local (toda la lógica de negocio requerida únicamente para soportar el
nivel de usuario, y que no necesite tener acceso a los recursos a nivel interno),
además es responsable de interactuar con “Enterprise Tier”, para acceder a recursos
internos y así soportar las necesidades del usuario del componente.
 Enterprise Tier: Representa el núcleo del componente, ya que se encarga de procesar

Página 18
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Aplicación Práctica

las peticiones recibidas por el usuario, implementa reglas de negocio, validaciones.


 Resource Tier: Se encarga de manejar el acceso a datos compartidos como por
ejemplo el acceso a las bases de datos, también se encarga del acceso a datos que se
encuentren en internet o en carpetas compartidas. La comunicación entre los datos y
el “Enterprise Tier” se realiza en este nivel para ocultar y separar, tanto como sea
posible, aspectos de persistencia sobre aspectos del core del negocio.

Las interacciones entre cada nivel se muestran en la siguiente figura:

Ilustración 5: Interacciones entre cada nivel de un componente CBD

2.1.7.4 CBD Ciclo de Vida

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:

I. Modelo Y [17, 18]

Página 19

Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008


Ingeniería de Sistemas ISTAR – CIS1210IS05

Ilustración 6 Ciclo de vida Modelo "Y" de CBD

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]:

Etapa Actividad Principal

Ingeniería de Es definido como el proceso de analizar el dominio de la aplicación para iden-


Dominio tificar las entidades del mundo real involucradas en el proceso y sus relacio-
nes y reflejarlas en el sistema. Con esta creación de un modelo abstracto de la
aplicación del mundo real se puede hacer un estudio preliminar de componen-
tes que podrían ser reutilizados para el desarrollo del problema.

“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.

Ensamblar Esta fase se concentra en la selección de una colección de componentes reuti-


lizables o “frameworks” específicos. Existen varios mecanismos para la reuti-
lización; uno de ellos es la composición que consiste en la construcción de
software a partir de una pieza autocontenida, o en el desarrollo orientado a
objetos mediante la generalización y herencia.

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.

Análisis del La fase de análisis de sistema se enfoca en la identificación de los componen-


sistema tes de alto nivel del mundo real de la aplicación, del estudio de las constantes,
los requerimientos y el desempeño esperado. El artefacto resultado de esta
fase es una descripción gráfica o textual de lo que se requiere y los principales
elementos que se necesitan para satisfacer la funcionalidad.

Diseño del Es un proceso exploratorio en donde se debe describir lo que compondrá el


sistema sistema, a tal nivel de detalle, que sea posible traducirlo a lenguaje de pro-
gramación. Esto incluye la descripción de los componentes que se usarán, los
que se implementarán y su interacción. Esta es una de las fases en donde ocu-

Página 21

Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008


Ingeniería de Sistemas ISTAR – CIS1210IS05

rren la mayor cantidad de iteraciones del proceso completo, puesto que el


refinamiento del diseño es un factor clave para lograr una implementación
correcta.

Implementa- La fase de implementación se caracteriza por la traducción del modelo de


ción diseño en lenguaje de programación. En esta fase, las tareas más complejas
son la programación de los componentes con las estructuras y algoritmos
definidos para proveer toda la funcionalidad requerida. Así mismo se deben
tener en cuenta, los componentes que fueron pensados para la reutilización, y
su necesidad de ser mucho más robustos y adaptables.

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.

Entrega El sistema es presentado al cliente, y el cliente es capacitado para el uso del


sistema y se le hace entrega de la documentación y manuales del software.

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.

Tabla 4: Fases del Modelo "Y" [17]

Página 22
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Aplicación Práctica

II. Modelo Iterativo [15, 17]

Ilustración 7: Ciclo de vida Modelo Iterativo de CBD

El principal objetivo de este modelo es la reutilización de componentes para el desarrollo del


sistema total [17], con base en las iteraciones constantes sobre las etapas que este modelo
contiene, la siguiente tabla muestra una explicación de cada una de las etapas de este modelo
basado en componentes [17]:

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

Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008


Ingeniería de Sistemas ISTAR – CIS1210IS05

La fase de diseño además de incluir la definición del sistema y de la arqui-


tectura, incluye el modelo de componentes, su colaboración e interacción.
Diseño
Esta actividad debe ser dinámica y evolutiva hasta conseguir la combina-
ción más apropiada de componentes para la construcción del sistema.

La implementación del componente consiste en el “código pegamento” que


Implementación se encargará del ensamblaje de los componentes y el desarrollo de aquellos
nuevos.

La integración es la unión de los componentes implementados y selecciona-


dos para la constitución del sistema. Este proceso podrá necesitar la adapta-
ción de algunos componentes para satisfacer los requerimientos y pruebas
Integración
tanto del sistema como de la unión de los componentes, puesto que no es
posible prever todos los comportamientos posibles de los componentes al
ser ensamblados.

El sistema debe ser verificado y validado. La verificación se encarga de


Verificación y determinar si el sistema y cada componente cumplen con los requerimientos
Validación definidos en la primera etapa. La validación se encarga de comprobar que el
componente y el sistema funcionan correctamente.

En esta etapa debe garantizarse que actualizaciones de los componentes o


Operación y reemplazos de ellos no afecten el sistema en general y sólo mantenga la
mantenimiento funcionalidad para la que fue diseñado. El mantenimiento del sistema se
hará de manera más sencilla por la modularidad del sistema.

Tabla 5: Etapas del Modelo Iterativo [17]

2.1.7.5 CBD en Java

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

 Seguridad con respecto a los tipos.

 Presencia en dispositivos móviles.

Al ser una plataforma independiente, se garantiza que el componente desarrollado va a ser


independiente de otras plataformas.

Algunos de los más importantes componentes que actualmente se encuentran desarrollados en


Java son:

 EJB – Enterprise Java Beans: Es la arquitectura de componentes en el lado del ser-


vidor para una plataforma Java EE, permite el desarrollo rápido y sencillo de aplica-
ciones distribuidas, transaccionales, seguras y portátiles basadas en tecnología Java
[11].

 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].

 SOFA 2: Es un sistema de componentes que emplea componentes compuestos jerár-


quicamente. Proporciona las siguientes características: ADL (Advanced Distributed
Learning) basado en el diseño; Especificación de comportamientos basados en proto-
colos de especificación; Conectores generados automáticamente que apoyan la distri-
bución uniforme y transparente de las aplicaciones; Entorno distribuido de ejecución
con la actualización dinámica de los componentes [13].

Página 25

Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008


Ingeniería de Sistemas ISTAR – CIS1210IS05

 Fractal: Es un modelo de componentes (modular, extensible y lenguaje de progra-


mación agnóstico) que se puede utilizar para diseñar, implementar, desplegar y re-
configurar los sistemas y aplicaciones desde sistemas operativos para plataformas
middleware e interfaces gráficas de usuario.

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

III – DESARROLLO DEL TRABAJO

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.

Los resultados se enuncian en el punto N° 1 de la sección de Resultados.

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.

Los resultados se enuncian en el punto N° 2 de la sección de Resultados.

3. Construcción

Teniendo el documento en el cual se especifico los diagramas arquitecturales y la especifica-


ción de los requerimientos, se procedió a la construcción (implementación) del componente
“Transper”.

Para esto, utilizando la arquitectura planteada, se realizó la implementación de los componen-


tes que cumplieran con los requerimientos propuestos, y por último la integración de cada
uno de estos componentes con los componentes auxiliares para que dieran como resultado el
componente “Transper”.

Los resultados se enuncian en el punto N° 3 de la sección de Resultados.

Página 27

Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008


Ingeniería de Sistemas ISTAR – CIS1210IS05

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.

Utilizando como referencia la metodología FLOOT expuesta en el punto 2.1.6 de la sección


“Marco Teórico”, se propuso las pruebas para la validación de Transper. Estas pruebas con-
sistían en validar los siguientes aspectos:

 Esfuerzo en código: Enmarcado en las pruebas de Caja Blanca de la metodología


FLOOT, esta prueba propendió en verificar el esfuerzo en líneas de código para utili-
zar el componente Transper, comparándolo con el número de líneas de código actual
en el caso de estudio, utilizadas para la persistencia.
 Rendimiento: Tomando como eje principal las pruebas de Rendimiento y del Com-
ponente de la metodología FLOOT, se planteo esta prueba, donde utilizando tiempos
de respuesta entre el componente Transper y el caso de estudio, se comparó con los
tiempos de respuesta de la persistencia actual del caso de estudio, dando como resul-
tado el rendimiento en tiempo de ejecución del componente desarrollado Transper.
Además de las pruebas realizadas sobre el caso de estudio, se realizo pruebas de las
funciones persistir, eliminar y actualizar que se puede utilizar sobre Transper, dando
como resultado una comparación entre estas funciones y funciones de persistencia
donde se necesite una base de datos relacional.

Los resultados se enuncian en el punto N° 4 de la sección de Resultados.

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.

1.1 Análisis y definición de requerimientos

En esta etapa de análisis se realizó la especificación de los requerimientos tanto funcionales


como no funcionales que el componente debía satisfacer. Se debe aclarar que esta especifica-
ción es global, por tanto solamente se definió en forma textual cada uno de los requerimien-
tos, en el anexo “especificaciónRequerimientos.xlsx” se puede ver un detalle completo de
cada uno.

A continuación se muestra un diagrama junto con una tabla donde se especifica los requeri-
mientos funcionales:

Página 29

Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008


Ingeniería de Sistemas ISTAR – CIS1210IS05

Ilustración 8: Diagrama de Requerimientos Funcionales

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.

REQ03: Transper deberá permitir la visualización de los resultados que se obtuvieron en la


ejecución de la consulta de cualquiera de las operaciones CRUD 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

REQ06: Transper permitirá la persistencia de forma transparente en objetos sobre la


BDOOdb4o.

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.

Tabla 6: Tabla de Requerimientos Funcionales

El siguiente diagrama junto con la tabla definen los requerimientos no funcionales:

Ilustración 9: Diagrama de requerimientos no funcionales

REQN01: Transper debe estar en capacidad de permitir en el futuro el desarrollo de nuevas


funcionalidades, modificar o eliminar funcionalidades después de su construcción y puesta
en marcha inicial.

REQN02: Transper debe presentar mensajes de error que permitan al usuario identificar el
tipo de error.

Página 31

Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008


Ingeniería de Sistemas ISTAR – CIS1210IS05

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.

REQN08: La funcionalidad de Transper debe estar implementada bajo lenguaje Java.

Tabla 7: Tabla de Requerimientos No Funcionales

1.2 Selección y evaluación de componentes

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

BlueJ Es un entorno de desarrollo integrado para el lenguaje de pro-


gramación Java.

Swing Biblioteca grafica para Java.

Altova UModel Herramienta de modelado basada en UML.

Novosoft Framework de metadata basado en UML

Tabla 8: Tabla con los componentes consultados

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

2.1.1 Diagrama de contexto Arquitectónico

En este diagrama se resalta el contexto de Transper planteado, en el cual se muestra la inter-


acción entre los subcomponentes internos y los entes externos a este.

Página 33

Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008


Ingeniería de Sistemas ISTAR – CIS1210IS05

Ilustración 10: Diagrama de Contexto Arquitectónico

A continuación se ofrece una explicación global de cada componente seleccionado:

Transper: Encargado de gestionar las peticiones que se generen en el componente Personal-


Graph, enviar las solicitudes de generación de logs al componente Logging en la gestión de
las peticiones y errores que surjan, y por último realizar la comunicación con la BDOO para
la gestión de las peticiones.

PersonalGraph: Este componente proporciona toda la presentación de Transper que se


muestra al usuario.

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

Usuario: Actor encargado de utilizar Transper, teniendo la necesidad de persistir objetos


transparentemente a la BDOO.

2.1.2 Diagrama de Casos de Uso

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.

Ilustración 11: Diagrama de 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.

- Realizar Operaciones CRUD: Se realiza cualquiera de las 4 operaciones CRUD


(Create, Read, Update, Delete), sobre el componente final

Página 35

Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008


Ingeniería de Sistemas ISTAR – CIS1210IS05

o Actualizar Objetos: Se realiza la operación de actualizar un objeto, previa-


mente consultado en la base de datos.
o Crear Objetos: Se realiza la operación de crear objetos para posteriormente
guardarlos en la base de datos.
o Eliminar Objetos: Se realiza la operación de eliminar un objeto, que pre-
viamente es consultado, en la base de datos
o Leer Objetos: Se realiza la operación de leer objetos de la base de datos, es-
te Caso de uso en particular esta suplido en el caso de uso Ejecutar Consulta.
- Editar Objetos: Se realiza la edición de objetos que se encuentran en la base de da-
tos, esto con previa consulta de este objeto.
- Generar Log: Se realiza la generación de logs en los archivos planos.
- Ejecutar Consulta: Se realiza la operación de ejecución de una consulta hacia la ba-
se de datos.
o Consultar por Ejemplo: Se realiza la consulta de tipo Ejemplo, donde se
pasa como parámetro un ejemplo de objetos a consultar.
o Consultar por Id: Se realiza la consulta de tipo Id, donde se pasa como pa-
rámetro un objeto que contiene el Id.
o Consultar por Clase: Se realiza la consulta de tipo Clase, donde se pasa
como parámetro una clase.
o Consultar por Rango: Se realiza la consulta de tipo Rango, donde se pasa
como parámetro un rango del número x al número y.
o Consultar Todo: Se realiza la consulta de tipo Todo, que consulta todos los
objetos existentes de la base de datos.
- Conectar a Base de datos: Se realiza la conexión a la base de datos, esta conexión
puede ser local, o en un servidor.

Casos de uso Arquitecturalmente Significantes:

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

Nombre Caso de Uso Número de Relaciones


(Casos de uso Asociados)

Realizar operaciones 4
CRUD (Actualizar Objetos, Crear Obje-
tos, Eliminar Objetos, Leer Obje-
tos).

Editar Objetos 0

Generar Log 0

Ejecutar Consulta 5 (Consultar por Ejemplo, Con-


sultar por Id, Consultar Todo,
Consultar por Rango, Consultar
por Clase).

Tabla 9: Tabla Casos de Uso


2.1.3 Diagrama Lógico

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.

Realizar Operaciones CRUD:

En estos diagramas se ofrece el comportamiento de la funcionalidad de realizar las operacio-


nes CRUD sobre la base de datos.

 Diagrama Dinámico:

Página 37

Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008


Ingeniería de Sistemas ISTAR – CIS1210IS05

Ilustración 12: Diagrama dinámico Realizar operaciones CRUD

 Diagrama Estático:

Ilustración 13: Diagrama estático Realizar operaciones CRUD

Página 38
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Aplicación Práctica

Ejecutar Consulta

En estos diagramas se ofrece el comportamiento sobre la funcionalidad de ejecutar los dife-


rentes tipos de consulta sobre la base de datos.

 Diagrama Dinámico:

Ilustración 14: Diagrama dinámico Ejecutar consultas

 Diagrama Estático:

Página 39

Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008


Ingeniería de Sistemas ISTAR – CIS1210IS05

Ilustración 15: Diagrama estático Ejecutar Consultas

2.1.4 Diagrama de Implementación

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

Ilustración 16: Diagrama de Implementación

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:

En la capa de presentación se encuentra los subcomponentes principales para la utilización de


Transper por parte del usuario. Por tal razón, estos subcomponentes están encargados tanto
de recibir los datos que el usuario configure y envíe, así como de generar y mostrar la res-
puesta al usuario.

Página 41

Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008


Ingeniería de Sistemas ISTAR – CIS1210IS05

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

Con el fin de cumplir los requerimientos no funcionales REQN06 y REQN08 planteados en


el punto 1.1 de la sección “Resultados”, la implementación de todos estos componentes está
hecha en Java, esto se puede verificar en el momento de ejecución de Transper, ya que se
necesita tener tecnología Java para poder utilizarlo.

En esta etapa se desarrollo los siguientes componentes:

 Loggin: Este componente se desarrolló principalmente para cumplir los requerimien-


tos funcionales REQ04 y REQ05, junto con los requerimientos no funcionales
REQN02, y REQN07.

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

Utilizando los componentes seleccionados y los implementados se desarrollo los siguientes


componentes:

 PersonalGraph: Este componente se desarrollo para suplir los requerimientos fun-


cionales REQ01, REQ02 y REQ03, y el requerimiento no funcional REQN03. Utili-
zando el componente gráfico seleccionado en el punto 1.2 de la sección de Resulta-
dos, se complemento la implementación de este componente.
Como se describió en el punto 2.1 de esta sección, este componente está encargado
de gestionar toda la parte grafica de Transper.
 Transper: Al tener implementado los componentes adicionales que ayudaban a su-
plir algunos requerimientos tanto funcionales como no funcionales, se procedió a rea-
lizar la integración de todos y cada uno de ellos, para que dieran como resultado este
componente.
Adicional a esto, en este componente se realizo la implementación que abarcaba el
cumplimiento de los requerimientos funcionales REQ06, REQ07 y REQ08.
 Plus: Como un plus de este componente, se realizo una funcionalidad mas, “Genera-
ción de código”, que se basa en generar código desde la parte grafica de Transper,
para que el programador lo utilice en sus desarrollos.
Esto funciona de la siguiente forma: El programador gestiona las respectivas opera-
ciones en la parte grafica de Transper, cuando desee realizar dicha operación sobre
la base de datos tendrá la opción de generar código, esto generará, a partir de los da-
tos suministrados por el programador, el respectivo código Java, con el fin de facili-
tarle la programación de la parte de persistencia en sus aplicaciones.

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

Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008


Ingeniería de Sistemas ISTAR – CIS1210IS05

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.

4.1 Verificación y Validación

4.1.1 Caso de estudio “Ayllu-AES”

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”.

Se seleccionó, gracias al grupo de investigación SIDRe, el proyecto “AES_EjemploOVA”, ya


que este contiene la lógica para realizar consultas hacia la base de datos. Este proyecto tiene
asociado otro proyecto llamado “AES_Framework”, por dicha razón, este último también está
enmarcado dentro de las pruebas de verificación y validación de Transper sobre el caso de
estudio.

4.1.1.1 Escenarios de pruebas

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

 PerfilDispositivo: Contiene 14 Anotaciones “@”, Objeto que modela las propiedades


de un Dispositivo

Ilustración 17: Código Implementación para PerfilDispositivo

Página 45

Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008


Ingeniería de Sistemas ISTAR – CIS1210IS05

 PerfilEstudiante: Contiene 18 anotaciones “@”, objeto que modela las propiedades


de un Estudiante.

Ilustración 18: Código implementación para PerfilEstudiante

Además se obtuvo los archivos que gestionan la persistencia a la base de datos, estos archivos
fueron:

 PerfilDispositivoJPAController: Encargado de gestionar la persistencia para los dis-


positivos.
 PerfilEstudianteJPAController: Encargado de gestionar la persistencia para los estu-
diantes.

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:

 estudiantePorId: Contiene 22 líneas de código funcional, método que se encarga de


consultar un Estudiante pasando como parámetro el id del estudiante.

Ilustración 19: Código implementación para método estudiantePorId

 listaEstudiantes: Contiene 5 líneas de código, método que se encarga de consultar to-


dos los estudiantes.

Ilustración 20: Código implementación para método listaEstudiantes

Página 47

Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008


Ingeniería de Sistemas ISTAR – CIS1210IS05

 estudiantePorNombre: Contiene 22 líneas de código, método que se encarga de con-


sultar un estudiante, pasando como parámetro el nombre del estudiante.

Ilustración 21: Código de implementación para método estudiantePorNombre

 dispositivoPorId: Contiene 19 líneas de código, método que se encarga de consultar


un dispositivo, pasando como parámetro el id del dispositivo.

Página 48
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Aplicación Práctica

Ilustración 22: Código implementación para método dispositivoPorId

 dispositivoPorNombre: Contiene 19 líneas de código, método que se encarga de con-


sultar un dispositivo, pasando como parámetro el nombre del dispositivo

Ilustración 23: Código implementación para método dispositivoPorNombre

 listaDispositivos: Contiene 5 líneas de código, método que se encarga de consultar


todos los dispositivos.

Página 49

Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008


Ingeniería de Sistemas ISTAR – CIS1210IS05

Ilustración 24: Código implementación para método listaDispositivos

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

4.1.2 Validación del Componente Transper

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.

Cabe resaltar que las pruebas se realizaron sobre el proyecto creado


(AES_EjemploOVA_Transper).

4.1.2.1 Prueba de Esfuerzo

La primera prueba que se realizo fue la de esfuerzo, propuesta en el punto 4 de la sección


“Desarrollo del Trabajo”. Esta prueba consistió en quitar todas las anotaciones y líneas de
código que eran necesarias para realizar la persistencia sobre la base de datos relacional, y
colocar las líneas de código y anotaciones respectivas para realizar la persistencia, utilizando
Transper, hacia la base de datos orientada a objetos. Esto dio como resultado lo siguiente:

La tabla 9 muestra los datos obtenidos al realizar las pruebas de esfuerzo.

Página 50
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Aplicación Práctica

Tabla 10: Prueba de Esfuerzo Número de líneas y Anotaciones

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

Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008


Ingeniería de Sistemas ISTAR – CIS1210IS05

Ilustración 25: Esfuerzo número de líneas PerfilDispositivoJpaController

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.

Ilustración 26: Esfuerzo número de líneas PerfilEstudianteJpaController

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.

Ilustración 27: Esfuerzo en número de anotaciones necesarias para persistir

4.1.2.2 Prueba de Rendimiento

La siguiente prueba realizada fue la de rendimiento, esta, se encuentra planteada en el punto 4


de la sección “Desarrollo del Trabajo”. Luego de haber realizado la prueba de esfuerzo, en la
cual se modifico los métodos del proyecto “AES_EjemploOVA_Transper” para que fuesen
soportados por Transper, esta prueba se asentó en comparar el tiempo gastado para realizar
las consultas a las bases de datos por cada uno de los proyectos, utilizando los métodos im-
plementados.

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

Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008


Ingeniería de Sistemas ISTAR – CIS1210IS05

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.

Tabla 11: Resultado Consulta por Nombre Dispositivo

La tabla 11 muestra los resultados para la consulta por Id Dispositivo

Tabla 12: Resultado Consulta por Id 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.

Tabla 13: Resultado Consultar todo Dispositivos

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.

Tabla 14: Resultado Consulta por Nombre Estudiante

La tabla 14 muestra los resultados obtenidos para la consulta por Id Estudiante.

Tabla 15: Resultado Consulta por Id 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.

Tabla 16: Resultado Consultar todo Estudiante

A continuación se muestra el comportamiento grafico de cada uno de estos resultados:

Página 55

Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008


Ingeniería de Sistemas ISTAR – CIS1210IS05

La ilustración 12 y la ilustración 13 muestran que al consultar dispositivos por algún atributo,


donde el resultado es un objeto, el tiempo de respuesta, al utilizar Transper, es muchísimo
menor al tiempo de respuesta de la persistencia actual.

En la ilustración 14 se refleja que para la consulta de datos, donde el tamaño de respuesta es


pequeño, Transper se comporta de una forma eficiente, realizando estas consultas en tiempos
de hasta 10 veces menores que los que presenta la persistencia actual del proyecto
“AES_EjemploOVA”, pero asimismo cada vez que este tamaño de respuesta aumente, se irá
aumentando este tiempo de respuesta, hasta llegar a sobrepasar el tiempo de respuesta de la
persistencia del proyecto “AES_EjemploOVA”. Esto puede ser una desventaja para Ayllu-
AES si se desea utilizar Transper y hay muchos datos de por medio.

Ilustración 28: Consultar por Id Dispositivo

Ilustración 29: Consulta por Nombre Dispositivo

Página 56
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Aplicación Práctica

Ilustración 30: Consultar Todo perfilDispositivos

Las ilustraciones 15, 16 y 17 reflejan el mismo comportamiento que las anteriores ilustracio-
nes, por tal motivo no se explica estos resultados.

Ilustración 31: Consulta por Nombre Estudiante

Ilustración 32: Consulta por Id Estudiante

Página 57

Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008


Ingeniería de Sistemas ISTAR – CIS1210IS05

Ilustración 33: Consulta todo Estudiantes

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

300 18786 3937 5621


400 24987 5819 7870
500 31110 8229 10625

Tabla 17: Resultados función de persistir objetos

En la ilustración 18 se puede observar el comportamiento que se tuvo al persistir cierto núme-


ro de registros en cada base de datos, donde en el eje “x” se observa este número de registros
y en el eje “y” el tiempo en milisegundos. Esto da como resultado que la función de persistir
de Transper es mucho más eficiente sobre una función que persiste datos a una base de datos
relacional, ya que al ir aumentando el N° de registros para persistir, el tiempo gastado de la
función de Transper es en proporción 2/3 menor que el tiempo gastado por una función de
persistencia a una base de datos relacional.

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.

Ilustración 34: Pruebas sobre la función persistir

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

Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008


Ingeniería de Sistemas ISTAR – CIS1210IS05

Modelo de Base Modelo de Base de datos Orien-


de datos Relacio- tada a Objetos
nal Local Servidor
1530 50 70

Tabla 18: Resultados función eliminación

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.

Ilustración 35: Pruebas sobre la función de eliminación

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

Tabla 19: Resultados función actualizar

En la ilustración 20, se puede observar casi el mismo comportamiento que en la ilustración


19, donde el tiempo gastado en la función actualizar sobre una base de datos relacional es
mucho mayor sobre la función eliminar de Transper.

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.

Ilustración 36: Pruebas sobre la función de actualización

Página 61

Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008


Ingeniería de Sistemas ISTAR – CIS1210IS05

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

V – CONCLUSIONES, RECOMENDACIONES Y TRABAJOS


FUTUROS

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

Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008


Ingeniería de Sistemas ISTAR – CIS1210IS05

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.

[2] S. B. Shamkant y R. Elmasri. (2007). Fundamentos de Sistemas de Bases de Datos. Ma-


drid, España.

[3] T. M. Conolly y C. E. Begg. (2005). Sistemas de Bases de Datos, Un enfoque práctico


para diseño, implementación y gestión. Madrid, España.

[4] B. J. Cox. (1986). Object Oriented Programming: An Evolutionary Approach. Addison-


Wesley.

[5] Rational Process. Recurso web. Disponible en: http://www-01.ibm.com/software/rational/


(Consultado por última vez, 24 de Noviembre de 2011).

[6] P. Kruchten. (2001). The Rational Unified Process An Introduction, Addison Wes-ley.

[7] Floot, metodología de pruebas. Recurso Web. Disponible en:


http://www.ambysoft.com/essays/flootSpanish.html (Consultado por última vez, 26 de No-
viembre de 2011).

[8] A. Silberschatz, H. F. Korth, S. Sudarchan. (2006). Fundamentos de Bases de Da-tos.


Aravaca, Madrid, España.

[9] Gamma E, Helm R., Johnson R., and Vlissides J. Design Patterns: Elements of Reusable
Object-Oriented Software. Addison Wesley, 1994.

[10] P. Hnetynka, J. Murphy. Deployment of Java-Based Components In Embedded Envi-


ronment. Recurso Web. Disponible en: http://pel.ucd.ie/files/deployment.pdf . Consultado por
última vez: 13 de Marzo de 2012.

[11] http://www.oracle.com/technetwork/java/javaee/ejb/index.html (EJB, consulta, 20 de


Febrero de 2012)

[12] http://www.ibm.com/developerworks/webservices/library/co-cjct6/ (CCM, consulta, 20


de Febrero de 2012)

[13] http://sofa.ow2.org/ (SOFA, consulta, 20 de Febrero de 2012)

[14] http://fractal.ow2.org/ (Fractal, consulta, 20 de Febrero de 2012)

[15] P. Herzum, O. Sims. Business Component Factory. A comprehensive Overview of


Component-Based Development for the Enterprise. Wiley Computer Publishing.

Página 65

Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008


Ingeniería de Sistemas ISTAR – CIS1210IS05

[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.

[19] M. P. Arias. L. Torres. A. Carrillo. A. Pomares. E. González. Servicios Enriquecidos


mediante Adaptación Contextual. Departamento de Ingeniería de Sistemas. Pontificia Univer-
sidad Javeriana. Articulo.

[20] M. P. Arias. L. Torres. A. Carrillo. A. Pomares. E. González. Plataforma basada en


Agentes para apoyo a la colaboración de Equipos de trabajo. Departamento de Ingeniería de
Sistemas. Pontificia Universidad Javeriana. Articulo.

[21] E. F. Codd. (1970). A Relational Model of Data for Large Shared Data Banks. IBM Re-
search Laboratory, San Jose, California.

[22] db4Objects. Object Oriented DataBase. Recurso Web. Disponible en:


http://www.db4o.com/. Consultado por última vez: 15 de Julio de 2012.

[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

[24] SIDRe. Grupo de Investigación. Departamento de Ingeniería de Sistemas. Pontificia


Universidad Javeriana. Recurso web. Disponible en:
http://sophia.javeriana.edu.co/sidre/objetivo.html 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 3. Documento Especificación de requerimientos

Anexo 4. Archivo .zip que contiene los archivos que soportan las
pruebas realizadas.

Anexo 5. Manual de instalación Transper


Anexo 6. Manual de Usuario Transper

Página 67

Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008

Vous aimerez peut-être aussi