LUIS ALFREDO BETANCOURT MALDONADO

DESARROLLO DE UN SISTEMA PARA ADMINISTRACION DE VIAJES

MISIONEROS USANDO TECNOLOGIA OPEN SOURCE

LUIS ALFREDO BETANCOURT MALDONADO

UNIVERSIDAD DE LOS ANDES FACULTAD DE INGENIERIA DE SISTEMAS

BOGOTA 2004

DESARROLLO DE UN SISTEMA PARA ADMINISTRACION DE VIAJES

MISIONEROS USANDO TECNOLOGIA OPEN SOURCE

LUIS ALFREDO BETANCOURT MALDONADO

Proyecto de Grado presentado como requisito para optar al título de Ingeniero de Sistemas

Modalidad TESIS DIRIGIDA

Asesor JUAN PABLO QUIROGA

Ingeniero de Sistemas y Computación

UNIVERSIDAD DE LOS ANDES FACULTAD DE INGENIERIA DE SISTEMAS

BOGOTA 2004

A Dios por ser mi razón de ser, a quien debo mi vida.

A mis padres por su amor, entrega, paciencia, guía.

A mi hermano, mi mejor compañero.

A mi tio y mis tres hermanitos,

por su apoyo y ayuda incondicional

Los amo

4

AGRADECIMIENTOS

Juan Pablo Quiroga

Ingeniera de Sistemas, Universidad de los Andes. Director de tesis.

Gabriel Reyes

Líder de misiones, Iglesia la Biblia Dice.

Facultad de Ingeniería de Sistemas

Universidad de los Andes.

A la universidad y los profesores del área de desarrollo de software de la

facultad de Ingeniería de Sistemas de la Universidad de los Andes por su

apoyo incondicional y la oportunidad brindada para la realización de este

trabajo.

5

TABLA DE CONTENIDO

INTRODUCCION

1. CONTEXTO 11

1.1. DEFINICIÓN DEL PROBLEMA 11 1.1.1. PRESENTACIÓN DE LA EMPRESA 11 1.1.2. IDENTIFICACIÓN DEL PROBLEMA 12 1.2. OBJETIVOS 14 1.2.1. OBJETIVO GENERAL 14 1.2.2. OBJETIVOS ESPECÍFICOS 14 1.3. JUSTIFICACIÓN 15 1.4. IMPACTO Y VIABILIDAD 16

2. MARCO TEÓRICO 18

2.1. PLATAFORMA DE DESARROLLO 18 2.1.1 HERRAMIENTAS DE DESARROLLO 18 2.1.2 SERVIDOR WEB 19 2.1.3 INTERNET 21 2.1.3.1 GENERALIDADES DE INTERNET 21 2.1.3.2 SISTEMAS DE INFORMACIÓN EN INTERNET 22 2.1.4 APLICACIONES WEB 24 2.2 MODELO DEL PROCESO DEL SOFTWARE 26 2.2.1 MODELO EN CASCADA 26 2.2.2 MODELO INCREMENTAL 27 2.3 BASES DE DATOS 32 2.3.1 COMPONENTES PRINCIPALES 32 2.3.2 VENTAJAS EN EL USO DE BASES DE DATOS 33 2.3.3 TIPOS DE MODELOS DE DATOS 33

6

2.3.4 BASES DE DATOS DISTRIBUIDAS 36 2.3.5 TENDENCIAS FUTURAS 36 2.3.6 ALGUNAS BASES DE DATOS 36 2.4 PROGRAMACIÓN WEB 38 2.4.1 JAVASCRIPT 38 2.4.2 JAVA SERVER PAGES (JSP) 39 2.5.5 CONTENIDO DE UN ENTERPRISE BEAN 44 2.5.6 WEB COMPONENTS 45 2.5.7 SERVLETS 45 2.5.8 JSP 46

3 METODOLOGÍA PARA EL DESARROLLO DEL PROYECTO 48

3.1 FASES EN LA ELABORACION DEL PROYECTO 48 3.1.1 FASE I. LECTURA Y ANÁLISIS DE INFORMACIÓN 48 3.1.2 FASE II - ANÁLISIS Y DISEÑO 48 3.1.3 FASE III.- IMPLEMENTACIÓN Y PRUEBAS 49

4 DESARROLLO DEL SISTEMA 51

5 PRUEBAS Y ESTADO FINAL DEL SISTEMA 100

6. CONCLUSIONES 102

8. BIBLIOGRAFÍA 105

ANEXOS 94

7

LISTA DE FIGURAS

Pág.

Figura 1. Esquema de interacción de documentos Web 25 Figura 2. Modelo en cascada 26

Figura 3. Modelo Incremental 27 Figura 4. Metodología Extreme Programing 30 Figura 5. Modelos de implementación de J2EE 42 Figura 6. Arquitectura J2EE 45

Figura 7. Arquitectura Eclipse 47

8

LISTA DE ANEXOS

Pág.

Anexo A. Descripción de las tablas de la base de datos del sistema 105

9

INTRODUCCIÓN

En la actualidad las organizaciones se han visto afectadas por las denominadas

Sociedades de la Información, en las cuales el tratamiento y procesamiento de

datos ha ido adquiriendo mayor importancia debido al valor agregado que éste

representa para las organizaciones como aditivo en su proceso competitivo y

desempeño económico, estableciendo sistemas eficientes y eficaces en el manejo

de información.

La manera en que las tecnologías de la información han ido evolucionando, y

como éstas manipulan los datos para que se acoplen de forma óptima con las

expectativas de los clientes, ya sea durante el procesamiento, almacenamiento o

transmisión, se constituye en un punto clave dentro de la estructura organizativa.

El crecimiento explosivo en el desarrollo de aplicaciones Web ha obligado que

cada vez mas las instituciones, empresas y el comercio en general se vean en la

necesidad de usar la red de redes para administrar información haciendo uso de

servidores, bases de datos y tecnología que pueda ser aplicada para generar

contenido dinámico que permita acceder en tiempo real a información de interés

para los usuarios del sistema

Un agravante que se debe tener en cuenta son los altos costos de adquisición,

desarrollo y administración de aplicaciones Web que generan una barrera para

que pequeñas empresas, que desean ser parte del cambio tecnológico, no puedan

acceder a los beneficios de este tipo de tecnología.

El desarrollo del proyecto ha sido ejecutado en gran parte por la necesidad de

estas pequeñas empresas, con pocos recursos para adquisición de nuevas

tecnologías de información y como un intento de lograr generar un aplicación que

cumpla con los estándares exigidos por la arquitectura Web pero haciendo uso de

10

proyectos de investigación abiertos que permitan una aplicación Web con un costo

financiero mínimo.

Tecnología J2EE en base al lenguaje de programación Java, bases de datos libres

como MySQL, herramientas de implementación libre como Hibernate y proyectos

de investigación para desarrollo de software como Eclipse hacen parte de la

propuesta que se desarrolla en el trabajo de grado que se presenta en este

documento.

Dentro de este contexto, se realiza un proyecto de investigación y desarrollo de

software como trabajo de grado. En éste documento se pretende hacer una

presentación general del problema específico de una empresa que desea

administrar la información correspondiente a un sistema de viajes que se realiza

por todo el territorio nacional, para la cual se desarrolla un software que cumpla

con las características mencionadas. El proyecto de grado esta basado en los

requerimientos y especificaciones que se generan en esta empresa, generando

una aplicación Web que brinde una solución efectiva a sus necesidades de

administración de información haciendo uso de tecnología abierta que no genere

un alto costo para la empresa pero si un valor agregado en la adquisición del

software que se desea implementar y que se desarrolla como tesis de grado.

11

1. CONTEXTO

1.1. DEFINICIÓN DEL PROBLEMA

1.1.1. Presentación de la Empresa

La Iglesia la “Biblia Dice” es una institución creada en Octubre de 1982 con el

objeto de conformar una comunidad cristiana que muestre con sus vidas la

verdad de la Palabra de Dios e impacte a aquellos que no la conocen.

VISION LOCAL

Movilizarnos para el avance del reino de Dios, perfeccionando a los santos y

fieles, capacitándolos para hacer discípulos del Señor Jesucristo

Hasta lo ultimo de la tierra.

VISION NACIONAL

Establecer iglesias modelos en ciudades principales haciendo discípulos de Cristo,

capaces de llevar fruto que permanezca en Colombia y el mundo entero.

RAZON SOCIAL:

IGLESIA LA BIBLIA DICE

PASTOR Y ENCARGADO:

Ing. Rodolfo Garrido.

COORDINADOR DEL PROYECTO

Sr. Gabriel Reyes.

DIRECCIÓN:

Diagonal 111 Num. 53-02. Barrio San Nicolás. Bogota – Colombia

12

1.1.2. Identificación del Problema

La Biblia Dice de Colombia lleva más de dos décadas llegando a diferentes

lugares en el territorio colombiano con el fin de mostrar a otros la Palabra de Dios.

El trabajo de viajar a otros territorios del país implica la movilización de personal

perteneciente al ministerio de misiones con el fin de hacer presencia en entre las

familias a las cuales se esta llegando.

La coordinación de los viajes misioneros, termino que se usa para referirse al

traslado de personal de la iglesia a otro territorio ha ido generando a lo largo de los

años una serie de procesos estandarizados que permiten administrar de forma

efectiva el trabajo que se esta realizando en cada una de las obras, termino que

se usa para referirse a las ciudades o pueblos en los cuales se tiene presencia.

El trabajo de organización, coordinación, control y administración general de los

viajes misioneros en la actualidad se hace de manera personal por medio de

reuniones y documentos que las personas involucradas deben llenar para lograr

llevar un control de las tareas que se están llevando acabo en cada una de las

obras.

Debido al crecimiento que ha tenido la iglesia en estos últimos años y al aumento

explosivo del numero de obras a las cuales se esta llegando en el territorio

colombiano, el manejo de las tareas administrativas del ministerio de misiones

tiene una necesidad imperativa de automatizar sus procesos y lograr obtener de

forma dinámica y en tiempo real información que permita lograr una toma de

decisiones efectiva en las tareas que se deben programas a futuro.

Adicionalmente se debe tener en cuenta los mas de 100 miembros que posee el

ministerio que hacen una tarea casi titánica la realización de calendarios de viaje,

administración del material a usar en los diferentes viajes misioneros, coordinación

de las tareas asignadas y mantenimiento de la información de la situación actual

13

de las obras en Colombia por medio de la consulta y generación de reportes que

permitan generar un valor agregado a la misión y visión de la iglesia.

El registro y mantenimiento de la información del ministerio de misiones en la

actualidad se realiza a mano y no se hace uso de ningún sistema de información o

computacional. Como consecuencia se tiene un proceso de administración lento,

que solo depende de recursos humanos, donde los costos y el tiempo invertido

son altos comparados con la implementación de un sistema que agilice estas

tareas administrativas y donde los errores tienen un alto grado de frecuencia.

La interacción de la información a través de la Web representa disminución de

tiempo y costos, a saber: tiempo de la persona encargada a determinado proceso,

ahorro de papel ya que ahora se obtiene la información en pantalla y si el usuario

la quiere o la necesita impresa este papel no será suministrado por la institución,

costos en el traslado de un usuario desde su casa o lugar de trabajo a la

Institución para realizar consultas de información ó cualquier actividad incluida

dentro de la funcionalidad de la Web, entre otros.

Por las presentes razones nace la necesidad de realizar una aplicación Web que

logre cubrir las necesidades de los requerimientos expresados por el ministerio de

misiones. La institución en la actualidad no posee los recursos económicos para

realizar una inversión en tecnología, por lo cual se hace imperativo que la

aplicación sea realizada sin ningún costo o en su defecto con un costo de

financiamiento mínimo. Es así que el presente trabajo de grado busca hacer uso

de herramientas de investigación de código abierto (Open Source) que logren el

propósito de minimizar los costos e implementar una arquitectura basada en J2EE

que permita desarrollar una aplicación Web que cumpla con los estándares

exigidos en el mercado actual. Las herramientas de desarrollo que se proponen

para la realización de la aplicación son:

• Eclipse: Entorno de desarrollo para aplicaciones en base al lenguaje de

programación Java.

14

• MySQL: Base de datos libre para usos investigativos y desarrollo de bases

de datos pequeñas.

• J2EE: Java 2 Enterprise Edition. Arquitectura para el desarrollo de

aplicaciones Web que integra un servidor de aplicaciones, una base de

datos y una interfaz Web como parte de su arquitectura.

• Tomcat: Servidor gratuito para desarrollo de aplicaciones sencillas que

cumple con las especificaciones exigidas para implementación de una

arquitectura J2EE [7].

1.2. OBJETIVOS

1.2.1. Objetivo General

Este proyecto tiene como objetivo la creación de un sistema Web de terminal que

se utilizará para manejar, controlar, almacenar y organizar el funcionamiento de un

ministerio que se dedica a viajes misioneros, dentro de una iglesia que funciona

como organización establecida, llamada la "Biblia Dice". En resumen se busca que

el sistema que se va a realizar sirva para optimizar el funcionamiento del ministerio

de misiones al interior de la organización de la "Biblia Dice", logrando una mayor

automatización del manejo de las obras, y viajes que se realizan a las mismas, así

como de la comunicación que se da entre el ministerio de misiones y las diferentes

obras en el territorio colombiano.

1.2.2. Objetivos Específicos

El ministerio se encarga del manejo de viajes a diferentes lugares del territorio

colombiano, en donde se hace un trabajo personal con diferentes familias e

individuos en las ciudades donde se llega. El objetivo del software es mantener un

control de los viajes que se realiza, la forma en que se realizan, quienes lo realizan

y datos adicionales como fechas, horas de reunión de los diferentes lugares, entre

muchas otras funciones. Se desea adicionalmente mantener un control de los

materiales que se usan dentro del ministerio, materiales que se deben enviar a

15

diferentes lugares de Colombia, en donde se encuentran las diferentes iglesias

que hacen parte de "La Biblia Dice", iglesias que reciben el nombre de "obras" al

interior de la organización. Una función adicional que se desea cubrir es la

comunicación entre diferentes obras adicionalmente de la comunicación al interior

del ministerio de misiones.

Los objetivos específicos incluyen:

• Comunicación efectiva y rápida entre las diferentes iglesias u obras que

hacen parte de la organización.

• Comunicación rápida entre los miembros que hacen parte del ministerio de

misiones en la iglesia principal.

• Comunicación efectiva y rápida de los materiales que necesitan las

diferentes obras.

• Análisis rápido y exacto de la situación en la que se encuentran las

diferentes obras que maneja el ministerio d emisiones de la Iglesia.

• Control automático del inventario que posee el ministerio de misiones.

• Automatización en la asignación de tareas y calendarios que se usan en el

ministerio.

• Control rápido y efectivo de los viajes que se realizan a las diferentes obras.

• Control efectivo en la plantación que se realiza en el ministerio.

• Administración del personal que pertenece al ministerio de misiones de la

organización.

• Administración general del ministerio de misiones permitiendo que los

usuarios tengan acceso haciendo uso de Internet.

• Automatización de los procesos administrativos que se realizan en el

ministerio de misiones.

1.3. JUSTIFICACIÓN

El desarrollo de la aplicación Web se hace imperativo para generar una solución

efectiva para la administración del ministerio de misiones cumpliendo logrando

exigido por el avance tecnológico.

16

No se puede ignorar los grandes beneficios que proporcionan las

telecomunicaciones y el uso de Internet en nuestro medio, lo cual ha llevado a que

cada vez mas organizaciones busquen un alto desarrollo y utilización de los

sistemas de información en línea para incrementar su cobertura y mejorar los

servicios ofrecidos a la comunidad en general.

Adicionalmente los beneficios generados por la aplicación Web evitarán pérdida

de información debido a procesos manuales, mantenimiento persistente de los

procesos haciendo uso de las herramientas específicas y obtención en tiempo real

de datos que permitan una toma de decisiones efectivas.

Hay que tener en cuenta que éste proceso implica transformaciones de

pensamiento, presenta inconvenientes dados por la resistencia al cambio por parte

de personas que temen a la innovación por ser de generaciones diferentes o por

creer que dichas innovaciones implican un desplazamiento laboral para ellos.

Además, actualmente no toda la población presenta el mismo grado de

incorporación a Internet lo cual implica que puede variar el grado de complejidad

de aprendizaje para los diferentes usuarios.

En cada una de las etapas del proyecto se establecen los adecuados controles en

cuanto a la seguridad informática, dando así un alto grado de confiabilidad.

1.4. IMPACTO Y VIABILIDAD

El proyecto representa para cualquier organización aseguramiento en la calidad y

prestación de su servicio, estableciendo una mayor cobertura en la divulgación de

sus planes, en la facilitación de sus procesos administrativos como viajes

misioneros, registro de materiales, asignación de tareas especificas, consulta e

ingreso de datos de importancia para la toma de decisiones, proceso de

elaboración e calendarios para viajes haciendo uso del personal involucrado en el

ministerio, entre otros, estableciendo un acceso a la información a cada uno de los

usuarios según su rol dentro de la organización.

17

Involucra también una reducción de costos y tiempos en el desarrollo de procesos

que exigen una disponibilidad de recurso humano y materiales, que representa

optimización de recursos, por lo cual la aplicación Web reducirá tanto en

tramitología de documentos como en la incomodidad del desplazamiento de

personal, aun de los usuarios para registrar datos de interés para la organización,

debido a que todos estos procesos se llevarán acabo de manera interactiva,

siempre estableciendo un alto grado de confiabilidad tanto para los usuarios como

para la institución.

Para la empresa desarrolladora se constituye en solución factible que garantiza la

satisfacción de las expectativas de un segmento muy importante de sus clientes y

el cumplimiento de la misión que viene cumpliendo desde hace más de veinte

años.

Es importante también señalar que este proceso es viable debido al compromiso e

interés de la empresa de suministrar la información que sea pertinente para el

desarrollo del trabajo de grado, así como del espacio y los recursos que sean

necesarios. De igual forma el respaldo de las directivas garantiza que la labor que

se va a desarrollar contribuirá realmente a la solución de la problemática

planteada.

18

2. MARCO TEÓRICO

2.1. PLATAFORMA DE DESARROLLO

2.1.1 Herramientas de Desarrollo

• J2SE

JAVA 2 SDK, Standard Edition (J2SE) [3] es un entorno de desarrollo para

crear aplicaciones, applets y componentes utilizando el lenguaje de

programación Java Incluye herramientas útiles para desarrollar y probar

programas escritos en el lenguaje de programación Java y que se ejecutan en

la plataforma Java. Estas herramientas están diseñadas para que se utilicen

desde la línea de comandos. Excepto en el caso del visualizador de applets,

estas herramientas no proporcionan una interfaz gráfica de usuario.

La documentación incluida de la plataforma Java 2 contiene especificaciones

API, descripciones de funciones, guías de desarrollador, páginas de referencia

de utilidades y herramientas de SDK, demostraciones y enlaces con

información relacionada.

Java 2 Platform, Standard Edition es la tecnología básica para muchos estilos

diferentes de desarrollo de software, incluidos applets y aplicaciones clientes y

aplicaciones de servidores individuales. Representa la base de la cual se

derivan las tecnologías Java 2 Platform, Micro Edítion (J2ME) y es el motor que

optimiza las implementaciones de Java 2 Plattorm, Enterprise Edition J2EE.

• JRE

Java Runhme Environment (JRE) [3] es el entorno mínimo para ejecutar

programas Java 2. Incluye la JVM y la API. Está incluida en el J2SE aunque

puede descargarse e instalarse separadamente. En aquellos sistemas donde

se vayan a ejecutar programas Java, pero no compilados, el JRE es suficiente.

19

El JRE incluye el Java Plug-in, que es el “añadido” que necesitan los

navegadores (Explorer o Netscape) para poder ejecutar programas Java 2. Es

decir que instalando el JRE se tiene soporte completo Java2, tanto para

aplicaciones normales (denominadas “standalone”) como para Applets

(programas Java que se ejecutan en una página Web, cuando esta es

accedida desde un navegador).

2.1.2 Servidor Web

• TOMCAT

Tomcat es un contenedor de Servlets con un entorno JSP [2]. Un contenedor

de Servlets es un shell de ejecución que maneja e invoca servlets por cuenta

del usuario.

Se pueden dividir los contenedores de Servlets en:

1. Contenedores de Servlets Stand-alone (Independientes).

Estos son una parte integral del servidor web. Este es el caso cuando

usando un servidor web basado en Java, por ejemplo, el contenedor de

servlets es parte de JavaWebServer (actualmente sustituido por iPlanet).

Este el modo por defecto usado por Tomcat. Sin embargo, la mayoría de

los servidores, no están basados en Java.

2. Contenedores de Servlets dentro-de-Proceso.

El contenedor Servlet es una combinación de un plugin para el servidor

web y una implementación de contenedor Java. El plugin del servidor

web abre una JVM (Máquina Virtual Java) dentro del espacio de

direcciones del servidor web y permite que el contenedor Java se

ejecute en él. Si una cierta petición debería ejecutar un servlet, el plugin

toma el control sobre la petición y lo pasa al contenedor Java (usando

JNI). Un contenedor de este tipo es adecuado para servidores multi-

thread de un sólo proceso y proporciona un buen rendimiento pero está

limitado en escalabilidad

3. Contenedores de Servlets fuera-de-proceso.

20

El contenedor Servlet [2] es una combinación de un plugin para el

servidor web y una implementación de contenedor Java que se ejecuta

en una JVM fuera del servidor web. El plugin del servidor web y el JVM

del contenedor Java se comunican usando algún mecanismo IPC

(normalmente sockets TCP/IP). Si una cierta petición debería ejecutar

un servlet, el plugin toma el control sobre la petición y lo pasa al

contenedor Java (usando IPCs). El tiempo de respuesta en este tipo de

contenedores no es tan bueno como el anterior, pero obtiene mejores

rendimientos en otras cosas (escalabilidad, estabilidad, etc.).

Tomcat puede utilizarse como un contenedor solitario (principalmente para

desarrollo y depuración) o como plugin para un servidor web existente

(actualmente se soporan los servidores Apache, IIS y Netscape).

Dentro de los distintos motores existentes para extender las características

adicionales de Java 2 probablemente uno de los proyectos de código

abierto liderado por la Apache Software Foundation en el cual se ha

desarrollado el servidor Jakarta-Tomcat, el cual no es más que un servidor

de aplicaciones basado en Java y creado para ejecutar servlets y páginas

JSP, siendo la implementación oficial de referencia de las especificaciones

Servlet 2.3 y JavaServer Pages 1.2. con la ventaja adicional de ser gratuito.

En el servidor tomcat contiene dos ficheros xml que son los que almacenan

la configuración, y reciben el nombre de server.xml y web.xml, el primero se

encarga de especificar la configuración global de Tomcat mientras que el

segundo se encarga de recoger aquellos parámetros que son opcionales.

Tomcat carece de algunas características funcionales importantes como

son:

- Velocidad: Tomcat es mucho más lento que Apache.

- Configuración: Tomcat no es configurable en muchos de sus aspectos.

21

- Robustez: Tomcat no está pensado como servidor web sino como motor

de JSP y servlet por tanto no se debe sustituir un servidor web por

Tomcat.

• APACHE

Apache es un servidor web, que permite el alojamiento de páginas web en una

máquina específica.

Esta herramienta tiene varias funciones tales como: permitir a los usuarios

tener sus propias páginas web, restricción a determinados sitios web,

conexiones seguras a través de SSL, configuración de módulos de

programación.

2.1.3 INTERNET

2.1.3.1 Generalidades de Internet

El Internet, algunas veces llamado simplemente "La Red", es un sistema mundial

de redes de computadoras, un conjunto integrado por las diferentes redes de cada

país del mundo, por medio del cual un usuario en cualquier computadora puede,

en caso de contar con los permisos apropiados, accesar información de otra

computadora y poder tener inclusive comunicación directa con otros usuarios en

otras computadoras.

Fue concebido por la agencia de nombre ARPA [8] (Advanced Research Projects

Agency) del gobierno de los Estados Unidos en el año de 1969 y se le conocía

inicialmente como ARPANET. El propósito original fue crear una red que

permitiera a los investigadores en un Campus poder comunicarse a través de los

sistemas de cómputo con investigadores en otras Universidades.

Hoy en día, el Internet es un medio de comunicación público, cooperativo y

autosuficiente en términos económicos, accesible a cientos de millones de gentes

22

en el mundo entero. Físicamente, el Internet usa parte del total de recursos

actualmente existentes en las redes de telecomunicaciones. Técnicamente, lo que

distingue al Internet es el uso del protocolo de comunicación llamado TCP/IP

(Transmission Control Protocol/Internet Protocol).

Para muchos usuarios del Internet, el correo electrónico (e-mail) ha reemplazado

prácticamente al servicio postal para breves mensajes por escrito. El correo

electrónico es la aplicación de mayor uso en la red. También se pueden realizar

conversaciones "en vivo" con otros usuarios en otras localidades usando el IRC

(Internet Relay Chat). Más recientemente, el software y hardware para telefonía en

Internet permite conversaciones de voz en línea.

2.1.3.2 Sistemas de Información en Internet

Un sistema de Información puede definirse de diferentes formas, entre las cuales

se encuentra:

- Conjunto ordenado de componentes o elementos interrelacionados,

interdependientes e interactuantes que tienen por finalidad el logro de

objetivos determinados.

- Conjunto de elementos que interaccionan entre si, orientados a la

consecución de un objetivo común. Un sistema está situado en un entorno

o ambiento con el que interactúa, recibe entradas y produce salidas.

- Conjunto de entidades que se relacionan e interactúan, en un contexto

dado, en post de un objetivo final predefinido, brindando apoyo a las

actividades realizadas en una empresa o negocio.

En conclusión, un sistema de información es un conjunto de componentes

interrelacionados que permiten capturar, procesar, almacenar y distribuir la

información para apoyar la toma de decisiones y el control en una entidad o

23

institución. Vale la pena resaltar que este no puede operar por sí mismo. Para eso

se hace necesaria la presencia de un equipo de cómputo que contenga hardware

necesario y también de recurso humano, el cual está formado por las personas

que utilizan el sistema.

Un sistema de información realiza cuatro actividades básicas: entrada,

almacenamiento, procesamiento y salida de información.

Entrada de Información: Es el proceso mediante el cual el Sistema de Información

toma los datos que requiere para procesar la información. Las entradas pueden

ser manuales o automáticas. Las manuales son aquellas que se proporcionan en

forma directa por el usuario, mientras que las automáticas son datos o información

que provienen o son tomados de otros sistemas o módulos.

Las unidades típicas de entrada de datos a las computadoras son las terminales,

las cintas magnéticas, las unidades de diskette, los códigos de barras, los

escáners, la voz, los monitores sensibles al tacto, el teclado y el mouse, entre

otras.

Almacenamiento de información: El almacenamiento es una de las actividades o

capacidades más importantes que tiene una computadora, ya que a través de esta

propiedad el sistema puede recordar la información guardada en la sección o

proceso anterior. Esta información suele ser almacenada en estructuras de

información denominadas archivos.

Procesamiento de información: Es la capacidad del Sistema de Información para

efectuar cálculos de acuerdo con una secuencia de operaciones preestablecida.

Estos cálculos pueden efectuarse con datos introducidos recientemente en el

sistema o bien con datos que están almacenados. Esta característica de los

sistemas permite la transformación de datos fuente en información que puede ser

utilizada para la toma de decisiones.

24

Salida de Información: La salida es la capacidad de un Sistema de Información

para llevar la información procesada o bien datos de entrada al exterior. Las

unidades típicas de salida son las impresoras, terminales, diskettes, cintas

magnéticas, la voz, los graficadores y los plotters, entre otros. Es importante

aclarar que la salida de un Sistema de Información puede constituir la entrada a

otro Sistema de Información o módulo.

Por otro lado, existen diferentes aspectos que deben tenerse en cuenta al

momento de pensar en la implantación de Sistemas de Información Internet, ya

que estos se caracterizan principalmente por su constante crecimiento y evolución.

Internet es un medio de propagación de información en el cual día a día todo

cambia. No es lógico pensar en un sistema de información para Internet bajo un

enfoque clásico y estático ya que por sus mismas características, este nunca llega

a ser un producto definitivo.

Es por esto que al ver las diferentes metodologías que han sido planteadas y

utilizadas en el desarrollo de sistemas de información se puede ver el Proceso

Unificado como un soporte para el desarrollo e implantación de aplicaciones en

Internet debido a sus características.

2.1.4 Aplicaciones Web

La idea fundamental es que los navegadores, browsers, presentan documentos

escritos en HTML [2] que han obtenido de un servidor Web. Estos documentos

HTML habitualmente presentan información de forma estática, sin más posibilidad

de interacción con ellos.

El modo de crear los documentos HTML ha variado a lo largo de la corta vida de

las tecnologías Web pasando desde las primeras páginas escritas en HTML

almacenadas en un fichero en el servidor Web hasta aquellas que se generan al

25

vuelo como respuesta a una acción del cliente y cuyo contenido varía según las

circunstancias.

Además, el modo de generar páginas dinámicas ha evolucionado, desde la

utilización del CGI ,Common Gateway Interface, hasta los servlets pasando por

tecnologías tipo JavaServer Pages. Todas estas tecnologías se encuadran dentro

de aquellas conocidas como Server Side, ya que se ejecutan en el servidor web.

Otro aspecto que completa el panorama son las inclusiones del lado del cliente,

Client Side, que se refieren a las posibilidades de que las páginas lleven

incrustado código que se ejecuta en el cliente, como por ejemplo JavaScript y

programas Java.

El esquema general de la situación se puede ver en la figura 2, donde se

muestran cada tipo de tecnología involucrada en la generación e interacción de

documentos Web.

Figura 1. Esquema de interacción de documentos Web

[1]

26

2.2 MODELO DEL PROCESO DEL SOFTWARE

2.2.1 Modelo en Cascada

Es el más básico de todos los modelos de ciclo de vida y de hecho sirve de base

para otros modelos[2]. Fue originalmente documentado por Royce en el año 1970.

El modelo de cascada ve el desarrollo como una secuencia simple de fases (como

se muestra en la figura) en donde cada fase tiene un conjunto de metas bien

definidas y las actividades entre cualquier fase contribuye a satisfacer las metas

de las fases subsiguientes.

Figura 2. Modelo en cascada

[1]

Algunos principios básicos del Modelo en Cascada son:

- Plan de proyecto antes de embarcarse en él.

- Definición del comportamiento externo del sistema deseado.

- Documentación de los resultados de cada actividad.

- Diseño del sistema previo a la codificación.

- Prueba del sistema antes de su construcción.

Características del Modelo en Cascada:

- Presenta el ciclo de desarrollo de software.

- Tiene una secuencia ordenada.

27

- Una etapa previa es la entrada del siguiente proceso.

2.2.2 Modelo Incremental

El modelo incremental combina elementos del modelo en cascada (aplicados

repetidamente) con la filosofía interactiva de construcción de prototipos. Como

muestra la Figura el modelo incremental aplica secuencias lineales de forma

escalonada mientras progresa el tiempo en el calendario. Cada secuencia lineal

produce un «incremento» del software.

Es clave entender que el modelo incremental entrega el software en partes

pequeñas, pero utilizables, llamadas «incrementos».[1] En general, cada

incremento se construye sobre aquél que ya ha sido entregado.

Cuando se utiliza un modelo incremental, el primer incremento a menudo es un

producto esencial. Es decir, se afrontan requisitos básicos, pero muchas funciones

suplementarias (algunas conocidas, otras no) quedan sin extraer. El cliente utiliza

el producto central (o sufre la revisión detallada). Como un resultado de utilización

y/o de evaluación, se desarrolla un plan para el incremento siguiente. El plan

afronta la modificación del producto central a fin de cumplir mejor las necesidades

del cliente y la entrega de funciones, y características adicionales. Este proceso se

repite siguiendo la entrega de cada incremento, hasta que se elabore el producto

completo.

El modelo de proceso incremental, como la construcción de prototipos y otros

enfoques evolutivos, es iterativo por naturaleza. Pero a diferencia de la

construcción de prototipos, el modelo incremental se centra en La entrega de un

producto operacional con cada incremento. Los primeros incrementos son

versiones «incompletas» del producto final, pero proporcionan al usuario la

funcionalidad que precisa y también una plataforma para la evaluación.

28

El desarrollo incremental es particularmente útil cuando la dotación de personal no

esta disponible para una implementación completa en la fecha límite que se haya

establecido para el proyecto. Los primeros incrementos se pueden implementar

con menos personas.

Figura 3. Modelo Incremental

2.2.3 Xtreme Programing (XP)

La metodología XP [8] es exitosa porque enfatiza la satisfacción del cliente y

promueve el trabajo en equipo.

En XP, las actividades improductivas han sido eliminadas para reducir costos y

frustraciones.

Análisis Diseño Código Prueba




Ingeniería de Sistemas / Información Incremento 1

Incremento 2

Incremento 3

Incremento 4

Entrega del 1er Incremento

Entrega del 2o Incremento

Entrega del 3er Incremento

Entrega del 4o Incremento Tiempo de Calendario

29

Esta metodología ha sido diseñada para solucionar el eterno problema del

desarrollo de software por encargo: entregar el resultado que el cliente necesita a

tiempo.

La metodología XP es exitosa porque enfatiza la satisfacción del cliente y

promueve el trabajo en equipo.

En XP, las actividades improductivas han sido eliminadas para reducir costos y

frustraciones.

Esta metodología ha sido diseñada para solucionar el eterno problema del

desarrollo de software por encargo: entregar el resultado que el cliente necesita a

tiempo.

2.2.3.1 Caracteristicas

El desarrollo bajo XP tiene características que lo distinguen claramente de otras

metodologías:

• Los diseñadores y programadores se comunican efectivamente con el

cliente y entre ellos mismos

• Los diseños del software se mantienen sencillos y libres de complejidad o

pretensiones excesivas.

• Se obtiene retroalimentación de usuarios y clientes desde el primer día

gracias a las baterías de pruebas

• El software es liberado en entregas frecuentes tan pronto como sea posible

• Los cambios se implementan rápidamente tal y como fueron sugeridos.

• Las metas en características, tiempos y costos son reajustadas

permanentemente en función del avance real obtenido.

Es una de las metodologías de desarrollo de software más exitosas en la

actualidad utilizadas para proyectos de corto plazo, corto equipo y cuyo plazo de

entrega era ayer. La metodología consiste en una programación rápida o extrema,

30

cuya particularidad es tener como parte del equipo, al usuario final, pues es uno

de los requisitos para llegar al éxito del proyecto.

[8]

Figura 4: Metodología Extreme Programing

2.2.3.2 Metodología:

La metodología se basa en:

o Pruebas Unitarias: se basa en las pruebas realizadas a los principales

procesos, de tal manera que adelantándonos en algo hacia el futuro,

podamos hacer pruebas de las fallas que pudieran ocurrir. Es como si nos

adelantáramos a obtener los posibles errores.

o Refabricación: se basa en la reutilización de código, para lo cual se crean

patrones o modelos estándares, siendo más flexible al cambio.

o Programación en pares: una particularidad de esta metodología es que

propone la programación en pares, la cual consiste en que dos

desarrolladores participen en un proyecto en una misma estación de

trabajo. Cada miembro lleva a cabo la acción que el otro no está haciendo

en ese momento. Es como el chofer y el copiloto: mientras uno conduce, el

otro consulta el mapa.

31

2.2.3.3 ¿Qué es lo que propone XP?

o Empieza en pequeño y añade funcionalidad con retroalimentación continua

o El manejo del cambio se convierte en parte sustantiva del proceso

o El costo del cambio no depende de la fase o etapa

o No introduce funcionalidades antes que sean necesarias

o El cliente o el usuario se convierte en miembro del equipo

2.2.3.4 Derechos del Cliente

o Decidir que se implementa

o Saber el estado real y el progreso del proyecto

o Añadir, cambiar o quitar requerimientos en cualquier momento

o Obtener lo máximo de cada semana de trabajo

o Obtener un sistema funcionando cada 3 o 4 meses

2.2.3.5 Derechos del Desarrollador

o Decidir como se implementan los procesos

o Crear el sistema con la mejor calidad posible

o Pedir al cliente en cualquier momento aclaraciones de los requerimientos

o Estimar el esfuerzo para implementar el sistema

o Cambiar los requerimientos en base a nuevos descubrimientos

Lo fundamental en este tipo de metodología es:

o La comunicación, entre los usuarios y los desarrolladores

o La simplicidad, al desarrollar y codificar los módulos del sistema

o La retroalimentación, concreta y frecuente del equipo de desarrollo, el

cliente y los usuarios finales

32

2.3 BASES DE DATOS

Se define una base de datos como una serie de datos organizados y relacionados

entre sí, los cuales son recolectados y explotados por los sistemas de información

de una empresa o negocio en particular.

Las bases de datos proporcionan la infraestructura requerida para los sistemas de

apoyo a la toma de decisiones y para los sistemas de información estratégicos, ya

que estos sistemas explotan la información contenida en las bases de datos de la

organización para apoyar el proceso de toma de decisiones o para lograr ventajas

competitivas. Por este motivo es importante conocer la forma en que están

estructuradas las bases de datos y su manejo.

2.3.1 Componentes Principales

• Datos. Los datos son la Base de Datos propiamente dicha.

• Hardware. El hardware se refiere a los dispositivos de almacenamiento en

donde reside la base de datos, así como a los dispositivos periféricos

(unidad de control, canales de comunicación, etc.) necesarios para su uso.

• Software. Está constituido por un conjunto de programas que se conoce

como Sistema Manejador de Base de Datos (DMBS: Data Base

Management System). Este sistema maneja todas las solicitudes

formuladas por los usuarios a la base de datos.

• Usuarios. Existen tres clases de usuarios relacionados con una Base de

Datos:

1. El programador de aplicaciones, quien crea programas de aplicación

que utilizan la base de datos.

2. El usuario final, quien accesa la Base de Datos por medio de un

lenguaje de consulta o de programas de aplicación.

33

3. El administrador de la Base de Datos (DBA: Data Base Administrator),

quien se encarga del control general del Sistema de Base de Datos.

2.3.2 Ventajas en el uso de Bases de Datos

• Globalización de la información. Permite a los diferentes usuarios

considerar la información como un recurso corporativo que carece de

dueños específicos.

• Eliminación de información redundante, duplicada.

• Eliminación de información inconsistente. Si el sistema esta desarrollado a

través de archivos convencionales, dicha cancelación deberá operarse

tanto en el archivo de facturas del Sistema de Control de Cobranza como

en el archivo de facturas del Sistema de Comisiones.

• Permite compartir información. Varios sistemas o usuarios pueden utilizar

una misma entidad.

• Permite mantener la integridad en la información. Solo se almacena la

información correcta.

• Independencia de datos. La independencia de datos implica un divorcio

entre programas y datos; es decir, se pueden hacer cambios a la

información que contiene la base de datos o tener acceso a la base de

datos de diferente manera, sin hace cambios en las aplicaciones o en los

programas.

2.3.3 Tipos de Modelos de Datos

Existen fundamentalmente tres alternativas disponibles para diseñar las bases de

datos: el modelo jerárquico, el modelo de red y el modelo relacional.

34

• El modelo jerárquico: La forma de esquematizar la información se realiza a

través de representaciones jerárquicas o relaciones de padre/hijo, de

manera similar a la estructura de un árbol. Así, el modelo jerárquico puede

representar dos tipos de relaciones entre los datos: relaciones de uno a uno

y relaciones de uno a muchos.

En el primer tipo se dice que existe una relación de uno a uno si el padre de

la estructura de información tiene un solo hijo y viceversa, si el hijo tiene

solamente un padre. En el segundo tipo se dice que la relación es de uno a

muchos si el padre tiene más de un hijo, aunque cada hijo tenga un solo

padre.

Inconveniente del modelo jerárquico

Relación maestro-alumno, donde un maestro tiene varios alumnos, pero un

alumno también tiene varios maestros, uno para cada clase. En este caso,

si la información estuviera representada en forma jerárquica donde el padre

es el maestro y el alumno es el hijo, la información del alumno tendrá que

duplicarse para cada uno de los maestros.

Otra dificultad que presenta el modelo jerárquico de representación de

datos es respecto a las bajas. En este caso, si se desea dar de baja a un

padre, esto necesariamente implicará dar de baja a todos y cada uno de los

hijos que dependen de este padre.

• El modelo de red: El modelo de red evita esta redundancia en la

información, a través de la incorporación de un tipo de registro denominado

el conector, que en este caso pueden ser las calificaciones que obtuvieron

los alumnos de cada profesor.

La dificultad surge al manejar las conexiones o ligas entre los registros y

sus correspondientes registros conectores.

35

• El modelo relacional: Se está empleando con más frecuencia en la práctica,

debido el rápido entendimiento por parte de los usuarios que no tienen

conocimientos profundos sobre Sistemas de Bases de Datos y a las

ventajas que ofrece sobre los dos modelos anteriores.

En este modelo toda la información se representa a través de arreglos

bidimensionales o tablas. Estas operaciones básicas son:

o Seleccionar renglones de alguna tabla (SELECT)

o Seleccionar columnas de alguna tabla (PROJECT)

o Unir o juntar información de varias tablas (JOIN)

Es importante mencionar que la mayoría de los paquetes que manejan bases de

datos disponibles en el mercado poseen las instrucciones SELECT, PROJECT Y

JOIN con diferentes nombres y modalidades.

Una base de datos relacional debe cumplir con las siguientes características

(Modelo ACID – Atomicity, consistency, Isolation, Durability)

- Atomicidad: La atomicidad de una transacción garantiza que todas sus

acciones sean realizadas o ninguna sea ejecutada.

- Consistencia: La consistencia garantiza que las reglas que hayan sido

declaradas para una transacción sean cumplidas.

- Aislamiento: Esto garantiza que las transacciones que se estén realizando

en el sistema sean invisibles a todos los usuarios hasta que estas hayan

sido declaradas finales. El aislamiento garantiza que los usuarios del

sistema no observen estos cambios intermedios hasta que sea finalizada la

última acción de actualización.

- Durabilidad: La durabilidad de una transacción garantiza que al instante en

el que se finaliza la transacción esta perdure a pesar de otras

36

consecuencias, esto es, si el disco duro falla, el sistema aún será capaz de

recordar todas la transacciones que han sido realizadas en el sistema.

2.3.4 Bases de Datos Distribuidas

Son las Bases de Datos que no están almacenadas totalmente en un solo lugar

físico, (esta segmentada) y se comunican por medio de enlaces de

comunicaciones a través de una red de computadoras distribuidas

geográficamente.

2.3.5 Tendencias Futuras

La explotación efectiva de la información dará ventaja competitiva a las

organizaciones.

Las bases de datos orientadas a objetos empleadas para diseño y manufactura

asistida por computadora CAD/CAM serán utilizados a un mismo nivel que las

Bases se Datos relacionales de la actualidad.

Los lenguajes de consulta (SQL) permitirán el uso del lenguaje natural para

solicitar información de la Base de Datos, haciendo más rápido y fácil su manejo.

2.3.6 Algunas Bases de Datos

SQL, INFORMIX, ORACLE, DBASE, IV, FOXPRO, FOXBASE, PARADOS,

ACCES, APPROACH, POSTGRESQL.

2.3.7 MySQL

MySQL es un sistema gestor de bases de datos SQL, que permite la gestión de

los datos usando un lenguaje de consulta estructurado. Esto significa que a partir

de una oración, MySQL llevará a cabo una determinada acción sobre la base de

datos.

37

2.3.8 Hibernate

Al trabajar con programación orientada a objetos y bases de datos relacionales, es

fácil observar que estos dos paradigmas son diferentes. El modelo relacional trata

con relaciones, y conjuntos (es muy matemático por naturaleza). Sin embargo, el

paradigma orientado a objetos trata con objetos, sus atributos y asociaciones de

unos con otros. Al momento de hacer persistir los objetos utilizando una base de

datos relacional se observa que: hay una desaveniencia entre estos dos

paradigmas, la también llamada diferencia objeto-relacional. Un mapeador objeto-

relacional nos ayuda a evitar esta diferencia.

Si se tienen objetos que hacer parte de una aplicación y algunas veces se alcanza

el punto donde se quiere que sean persistentes, normalmente se abre conexión

JDBC, se crea una sentencia SQL y se copian todos los valores de las

propiedades sobre la selección. Esto es fácil para un objeto pequeño pero

considerar esto para objetos con muchas propiedades puede ser una tarea

dificultosa. Adicionalmente se suma el problema de las asociaciones en donde un

objeto puede llegara tener conflictos en el momento de hacer persistir la

aplicación en la base de datos.

Se han realizado estudios que demuestran que el 35% del código de una

aplicación se produce para mepear datos entre la aplicación y la base de datos.

Un ORM básicamente intenta el trabajo de dar persistencia a los objetos de un

modelos de orientado a objetos. Con Hibernate, sólo se debe definir una vez la

forma en que las clases se mapean a tablas, que propiedad se mapea a qué

columna, que clase se mapea a qué tabla, etc. Después de esto, se pueden tomar

los objetos y utilizarlos dentro de la aplicación.

Hibernate es el mapeador objeto-relacional de código abierto más maduro y más

completo que hay ahora. Se utiliza muy ampliamente y se desarrolla activamente.

38

Hibernate también soporta una de las mayores comunidades de Open Source que

se encuentra en el mercado.

2.4 PROGRAMACIÓN WEB

2.4.1 JavaScript

Javascript no es un lenguaje de programación propiamente dicho. Es un lenguaje

script u orientado a documento, como pueden ser los lenguajes de macros que

tienen muchos procesadores de texto. Trabaja siempre del lado del cliente porque

es el navegador el que soporta la carga de procesamiento. Permite interactuar con

el navegador de manera dinámica y eficaz, proporcionando a las páginas Web

dinamismo y vida. Gracias a su compatibilidad con la mayoría de los navegadores

modernos, es el lenguaje de programación del lado del cliente más utilizado.

No es posible desarrollar programas basándose en JavaScript, sin embargo, una

aplicación escrita en JavaScript puede ser incrustada en un documento HTML

proporcionando un mecanismo para la detección y tratamiento de eventos, como

clicks del ratón o validación de entradas realizadas en forms.

JavaScript es sensible a mayúsculas y minúsculas todos los elementos de

JavaScript deben reverenciarse cómo se definieron: no es lo mismo “Salto” que

“salto”, La etiqueta utilizada para la inclusión de este código es:

<Script Language = “JavaScript”>

…

</Script>

Un documento puede tener cualquier número de etiquetas Script, las cuales a su

vez pueden contener cualquier número de sentencias JavaScript.

39

Aunque JavaScript y Java tienen algunas similitudes, tienen también diferencias

fundamentales. JavaScript soporta la mayoría de constructores de flujo de control

básico y sintaxis de expresiones. En contraste con el sistema de clases definidas

en tiempo de compilación en Java, Javascript trabaja en base a un simple sistema

en tiempo de ejecución, el cual permite el uso de enteros, dobles, booleanos y

cadenas. JavaScript soporta un sistema simple de objetos basado en instancias

(no en clases), que provee capacidades significativas.

2.4.2 Java Server Pages (JSP)

Las JSP son una solución que permite en la creación de contenido dinámico,

haciendo más fácil y más rápido construir aplicaciones Web. Inicialmente se

genera código fuente Java para todo el archivo JSP, se compila el código y

ejecuta el archivo JSP como si fuera un servlet.

Entre las características de las JSP se pueden encontrar:

- Velocidad y Escalabilidad: Las JSP no son interpretadas sino compiladas y

cargadas en la memoria del servidor la primera vez que se les llama, así

que para las siguientes llamadas, el tiempo de respuesta es mucho más

corto debido a que simplemente son ejecutadas.

- Plataforma y Servidor Independiente: JSP se adhiere a la arquitectura de la

filosofía Java. En lugar de ser soportada por una única plataforma o

proveedor, esta tecnología puede ser ejecutada en cualquier servidor Web

y es soportada por una gran cantidad de herramientas de múltiples

proveedores.

- La característica más importante de las JSP es que permite separar la

interfaz del usuario de la generación del contenido dinámico, dando lugar a

procesos de desarrollo más rápidos y eficientes.

Un JSP se compila a un programa en Java la primera vez que se invoca, y del

programa en Java se crea una clase que se empieza a ejecutar en el servidor

40

como un servlet. Por consiguiente, el ciclo de vida en tiempo de ejecución de los

archivos JSP es similar al ciclo de vida de los servlets.

Cuando un servidor Web recibe una petición de obtener un archivo JSP, el

servidor pasa la petición al motor de servlets que a su vez llama al procesador

JSP. El procesador JSP es un servlet interno que convierte un archivo JSP en

código fuente Java y lo compila. Si una determinada petición solicita por primera

vez un archivo JSP o si no se encuentra la copia compilada del archivo JSP, el

compilador JSP genera y compila un archivo fuente Java para el archivo JSP, este

se mantiene en la memoria mientras se procesan todas las peticiones recibidas y

generan las respuestas a los usuarios.

Cuando se recibe una petición que solicita un archivo JSP, se comprueba si ese

archivo ha cambiado desde la última vez que se cargó, si es así, se recarga el

archivo JSP actualizado, es decir, se genera un archivo fuente y un archivo de

clase Java actualizados para el archivo JSP.

Existen 2 tipos de acceso a los archivos JSP:

1. Un usuario trabajando en un navegador Web cliente hace una petición que

es enviada a un archivo JSP (.jsp) El archivo .jsp accesa componentes del

servidor que generan contenido dinámico y lo presentan en el navegador.

Después de recibir la petición del cliente, el archivo JSP pide información de

un JavaBean. El JavaBean puede pedir información de una Base de Datos.

Una vez el JavaBean genera el contenido, el archivo JSP puede consultar y

presentar el contenido del Bean.

2. Un usuario trabajando en un navegador Web cliente hace una petición que

es enviada a un Java Servlet que genera un resultado y lo almacena en un

41

componente. En seguida, el servlet llama un archivo JSP, el cual accesa el

componente y presenta el contenido dinámico en el navegador.

En este caso, el cliente hace una petición que es atendida por un Java

Servlet. El servlet genera el contenido dinámico, usa JDBC para

comunicarse con una Base de Datos para obtener el contenido. Ahora, el

servlet empaqueta el contenido en un Bean. El archivo JSP accesa el

contenido dinámico desde el Bean y presenta el contenido en el navegador

cliente.

2.5 ARQUITECTURA J2EE

La plataforma J2EE [7] usa un modelo de aplicación distribuida compuesta de

diferentes capas. La lógica de aplicación esta dividida entre componentes de

acuerdo a su función, y los diferentes componentes de aplicación que

componen la aplicación J2EE están instalados en diferentes maquinas

dependiendo de la capa especifica del entorno de J2EE a la cual la aplicación

pertenece.

La Figura (NUMERO) muestra dos aplicaciones J2EE divididas en capas

descritas en la figura. Una aplicación J2EE esta compuesta por los siguientes

componentes:

• Los componentes que pertenecen a la capa cliente la cual corre en la

maquina cliente.

• Los componentes que pertenecen a la capa Web la cual corre en el servidor

de aplicaciones.

• Los componentes que pertenecen a la capa de negocios que corren en el

servidor de aplicaciones.

42

[8]

Figura 5. Modelos de implementación de J2EE

Las aplicaciones J2EE son consideradas generalmente aplicaciones de tres capas

debido a que están distribuidas en tres espacios diferentes: la maquina cliente, el

servidor J2EE de aplicaciones y la base de datos o sistemas legacy como última

capa de la arquitectura. Estas tres capas de aplicaciones que corren de esta

manera extienden el modelo cliente y servidor estándar que esta compuesto por

dos capas, colocando un servidor de aplicaciones multicapas entre el cliente de

aplicaciones y la parte final de la aplicación.

Las aplicaciones J2EE applications están hechas de componentes. Un

componente J2EE es una unidad de software software funcional que se contiene a

si mismo que hace parte de una aplicación J2EE y sus clases relacionadas y

archivos los cuales se comunican con otros componentes. La especificación J2EE

define los siguientes componentes:

• Aplicaciones clients y applets son componentes que corren en el lado del

clients,

• Java Servlet y JavaServer Pages (JSP) son componentes Web que corren en

el servidor.

• Enterprise JavaBeans [7] (EJB) con componentes de negocio que corren en el

servidor.

43

Los componentes J2EE están escritos en lenguaje Java y son compilados de la

misma forma como cualquier programa escrito en este lenguaje. La diferencia

entre componentes J2EE y clases Java comunes consiste en que los

componentes J2EE hacen parte de aplicaciones J2EE, verificando que se

encuentren bien formadas de acuerdo a la especificación J2EE, y depuradas de tal

forma que puedan ser manejadas en un servidor de aplicaciones J2EE.

2.5.1 Clientes Web

Un cliente Web consiste de dos tipos de elementos: paginas web dinámicas que

contienen diferentes tipos de lenguajes markup como HTML, XML, entre otros, los

cuales don generados por componentes Web que corren en la capa Web, y un

Web browser, que realiza un render de las paginas que recibe del servidor.

Un cliente Web es conocido aveces como cliente liviano (thin client). Los clientes

livianos usualmente no hacen realizan tareas como consulta a bases de datos,

ejecución de reglas de negocio complejas, o conexión con aplicaciones en

sistemas legacy.

2.5.2 Applets

Una pagina web que se recibe de la capa web puede incluir un applet. Un applet

es un cliente liviano escrito en java que se ejecuta en la maquina virtual de java

que se encuentra instalada en el browse.

2.5.3 Clientes de Aplicación

Una aplicación cliente J2EE corre en una maquina cliente y provee al usuario una

manera de manejar tareas que requieren de una interfaz mas completa y robusta.

Normalmente se hace uso de una interfaz grafica de usuarios (GUI).

Las aplicaciones cliente accesan directamente los enterprise beans que corren en

la capa de negocio. Sin embargo, una aplicación J2EE puede abrir una conexión

HTTP para establecer comunicación con un servlet que corre en la capa web.

44

2.5.4 JavaBeans

Las capas cliente y servidor pueden incluir componentes JavaBeans para manejar

el flujo de datos entre una aplicación cliente y un componente corriendo en el

servidor J2EE o entre los componentes del servidor y la base de datos. Los

componentes JavaBeans no son considerados componentes J2EE según la

especificación J2EE.

Los componentes JavaBeans tienen variables de instenacia y métodos get y set

para accesar los datos de las variables de instancia. Los componentes

JavaBeans usados de esta manera son típicamente sencillos en cuanto a diseño

se refieren.

2.5.5 Contenido de un Enterprise Bean

Para desarrollar un enterprise bean, se debe proveer los siguientes archivos:

• Deployment descriptor: Un archive XML que especifica la información

relacionada al bean como el tipo de persistencia y los atributos de transacción.

• Enterprise bean class: Implementa los métodos definidos en las interfaces

• Interfaces: La interfaz home y remote son requeridas para acceso. Para un

acceso local una interfaz local es requerida.

El empaquetamiento de los archivos se realiza de acuerdo a la presente lista

dentro de un archive EJB JAR, modulo en el cual de graban los enterprise bean.

Un EJB JAR es portable y puede ser usado para diferentes aplicaciones. Para

armar una aplicación J2EE, se empaquetan uno o mas módulos como los son los

EJB JAR en un archivo EAR, archive que contiene toda la aplicación.

Item Syntax

Enterprise bean name (DD) <name>EJB

EJB JAR display name (DD) <name>JAR

Enterprise bean class <name>Bean

45

2.5.6 Web Components

Los componentes Web J2EE pueden ser servlets o paginas JSP. Los servlets son

clase escritos en Java que procesan dinámicamente requerimientos y construyen

requerimientos. Las paginas JSP son documentos de texto que ejecutan como los

servlets pero permite una mayor capacidad para la creación de contenido estático.

Las paginas HTML estáticas y los applets son unidos a los componentes web a la

hora de ensamblar las aplicaciones, pero no son considerados componentes web

según la especificación J2EE.

[8]

Figura 6. Arquitectura J2EE. 2.5.7 Servlets

Un servlet es una clase escrita en programación Java usada para extender las

capacidades de los servidores que las aplicaciones host accesan a través de

requerimientos y respuestas según el modelo de programación.

Los paquetes javax.servlet y javax.servlet.http proveen interfaces y clases para la

creación de servlets. Todos los servlets deben implementar la interfaz Servlet, que

define métodos para el manejo del ciclo de vida.

46

2.5.8 JSP

Una pagina JSP page es documento de texto que contiene dos tipos de texto:

templates estáticos, que pueden ser expresados en cualquier formato de texto

como HTML, SVG, WML, y XML; y elementos JSP, que contraten contenido

dinámico.

• Las directives (<%@ page ... %>) importan clases en el paquete java.util, y

configuran el tipo de contenido retornado por la pagina.

• El elemento jsp:useBean crea un objeto que contiene una colección de

variables locales que apuntan a un objeto.

• Los Scriptlets (<% ... %> ) manejan contenido java dentro de la pagina.

• Las Expresiones (<%= ... %>) insertan un valor de un nombre local dentro de

una respuesta.

2.6 Entorno de desarrollo

2.6.1 ECLIPSE 2.6.1.1 Proyecto ECLIPSE

El proyecto Eclipse es un proyecto de desarrollo de software abierto dedicado a

proporcionar una plataforma robusta, completa, de calidad comercial para el

desarrollo de herramientas con un alto grado de integración. Esta compuesto de

tres subproyectos: Plataforma, JDT (Java Development Tools), y PDE (Plug-in

Development Enviroment). Es un proyecto de código libre que se concentra en el

desarrollo de código base para desarrolladores que crean sus propias

herramientas.

2.6.1.2 Plataforma ECLIPSE

La plataforma de Eclipse un entorno open-source para la creación, integración, y

desarrollo aplicaciones que pueden ser usadas en un gran rango de tecnologías

computacionales. Provee un conjunto de servicios y establece la infraestructura y

47

el área de trabajo interactivo usado por desarrolladores de proyectos para

construir sus aplicaciones de software y los elementos relacionados con estas.

2.6.1.3 Arquitectura ECLIPSE

Eclipse es una plataforma universal para integrar herramientas de desarrolladores.

Eclipse provee una arquitectura que es abierta y extensible. Todas las

funcionalidades son suplidas a través de plug-ins.

Figura 7. Arquitectura de Eclipse

2.6.3 Ant

Apache Ant es una herramienta basada en Java. Es una herramienta que evalúa

una serie de dependencias y luego ejecuta comandos específicos.

Ant esta basado en comandos shell especialmente para el uso de clases Java. La

diferencia con un archivo shell radica en que el archivo de configuración esta

basado en tecnología XML, haciendo uso de un conjunto de targets que permiten

ejecutar diferentes operaciones. Cada tarea es ejecutada por un objeto que

implementa una Interfaz de Tarea particular.

En conjunto con plataformas de desarrollo como Eclipse permiten realizar las

tareas de compilación de aplicaciones web de manera rápida y segura.

PDE

JDT

Plataforma

Java VM

48

3 METODOLOGÍA PARA EL DESARROLLO DEL PROYECTO

Para el desarrollo del proyecto se utilizará la metodología de acuerdo con los

estándares fijados por desarrollos en base a xtreme programing haciendo uso del

Modelo en Cascada y en algunas ocasiones, según la complejidad a la que pueda

llegar el software, el Modelo Incremental.

3.1 FASES EN LA ELABORACION DEL PROYECTO

A continuación se enumeran y describen cada una de las fases del proyecto.

3.1.1 Fase I. Lectura y Análisis de Información

El objetivo de esta fase, es la ubicación y contextualización dentro de la empresa y

el proyecto específico en donde participa.

Las actividades a realizar en esta fase son:

1. Conocimiento de la empresa y de los requerimientos generales del proyecto

que se desea realizar.

2. Conocimiento de los procesos pertenecientes al Ministerio de Misiones de

la institución.

3. Capacitación y entrenamiento en las herramientas de programación, bases

de datos a utilizar y servidor a implementar: JSP, J2EE, Java, SQL, Tomcat.

4. Consecución y alistamiento del software y hardware necesarios para el

desarrollo del proyecto.

5. Instalación del servidor Tomcat, entorno de programación Eclipse, base de

datos MySQL y configuración de las herramientas de desarrollo.

3.1.2 Fase II - Análisis y Diseño

Durante esta fase se definen claramente los requerimientos especificados por los

clientes en cuanto a los datos y la funcionalidad que debe contener el módulo Web

49

a desarrollar y se elabora un documento de requerimientos que será la base del

diseño.

Se procede a revisar el modelo de datos del sistema académico y se hace la

reingeniería de procesos involucrando los nuevos datos y la aplicación Web

Al final de esta fase se tiene el documento de ESPECIFICACIONES DE DISEÑO,

el cual contendrá el esquema entidad/relación, el diagrama funcional de la

aplicación, la definición del esquema de la base de datos y el esquema de

seguridad.

Las actividades a realizar en forma específica son:

1. Reuniones para conocer y afinar requerimientos de los clientes

2. Elaboración y aprobación del documento de requerimientos.

3. Revisión del modelo de datos del Sistema Académico.

4. Diseño de la base de datos Web

5. Diseño de las páginas

6. Diseño del esquema de seguridad

7. Diseño de las interfases con la base de datos académica

8. Elaboración del documento de especificaciones de diseño

3.1.3 Fase III.- Implementación y Pruebas

Durante esta fase se efectúa la programación del módulo Web del Sistema

Académico y se hacen las respectivas pruebas. Se hace la escritura, depuración y

prueba de los programas tanto en forma independiente como integrada.

Se hacen pruebas de almacenamiento, desempeño, carga pico que garanticen el

óptimo funcionamiento del sistema.

Las actividades a realizar en forma específica son:

1. Desarrollo del módulo de planes de estudio.

2. Desarrollo del módulo de notas

3. Desarrollo del módulo de admisiones

4. Desarrollo del módulo de prematricula

50

5. Desarrollo de las interfases con la base de datos académica

6. Desarrollo de las diferentes aplicaciones (aspirantes, estudiante,

profesores, directores)

7. Implementación del protocolo de seguridad (SSL)

8. Pruebas de la carga de los archivos de datos al servidor Web.

9. Carga y descarga de la base de datos con registros de prueba.

10. Prueba de programas individuales

11. Revisión de características finales de cada página

12. Pruebas de la aplicación en forma integral.

51

4 DESARROLLO DEL SISTEMA

4.1 DESCRIPCION DE LAS FUNCIONES DEL SISTEMA. 4.1.1 Funciones Manejo Material

Ref# Función Categoría

R1.1 Modificar material Evidente

R1.2 Adicionar material Evidente

R1.3 Solicitar material Evidente

R1.4 Borrar material Evidente

R1.5 Mostrar material existente Evidente

R1.6 Reducir material existente cuando se solicita Oculta

4.1.2 Funciones Manejo Calendario


R2.1 Buscar persona en el calendario Evidente

R2.2 Mostrar frecuencia viaje persona Evidente

R2.3 Mostrar cruces calendario Evidente

R2.4 Mostrar equipos del calendario Evidente

R2.5 Crear calendario Evidente

R2.6 Eliminar calendario Evidente

R2.7 Mostrar calendario Evidente

R2.8 Imprimir calendario Evidente

R2.9 Mostrar lista total de personas que pueden viajar en un

calendario Evidente

R2.10 Adicionar personas que viajan Evidente

52

4.1.3 Funciones Manejo Personal Ministerio


R3.1 Adicionar nombre a lista ministerio Evidente

R3.2 Modificar datos lista ministerio Evidente

R3.3 Borrar lista ministerio Evidente

R3.4 Imprimir lista ministerio Evidente

R3.5 Modificar datos lista ministerio Evidente

R3.6 Mostrar lista total ministerio por orden alfabético Evidente

R3.7 Mostrar personas por ministerio en orden alfabético Evidente

R3.8 Buscar persona ministerio Evidente

R3.9 Eliminar nombre a lista de ministerio Evidente

4.1.4 Funciones Manejo Pasajes


R4.1 Solicitar reserva pasaje Evidente

R4.2 Adicionar millas acumuladas Evidente

R4.3 Mostrar millas acumuladas Evidente

R4.4 Mostrar datos pasaje Evidente

R4.5 Mostrar personas con pasaje por confirmar Evidente

R4.6 Mostrar personas con pasaje confirmado Evidente

R4.7 Solicitar confirmación pasaje Evidente

R4.8 Confirmar pasaje Evidente

R4.9 Modificar datos pasaje Evidente

R4.10 Eliminar pasaje Evidente

53

4.1.5 Funciones Manejo Obras


R5.1 Actualizar datos obras Oculta

R5.2 Adicionar obra madura Evidente

R5.3 Adicionar obra menor Evidente

R5.4 Modificar obra madura Evidente

R5.5 Modificar obra menor Evidente

R5.6 Eliminar obra Evidente

R5.7 Mostrar datos obra madura Evidente

R5.8 Mostrar datos obra menor Evidente

4.1.6 Funciones Registro Usuario


R6.1 Registrar Secretaria Evidente

R6.2 Registrar Líder de Misiones Evidente

R6.3 Registrar Líder Obra Evidente

R6.4 Registrar Líder de Ministerio Evidente

4.2 DESCRIPCION DE LOS CASOS DE USO DEL SISTEMA. 4.2.1 Funciones Manejo Material

ID M1

Caso de uso: Modificar material

Actores: Secretaria

Prioridad: 2

Precondición: El usuario se encuentra en el sistema. Existe un material

54

registrado en el sistema.

Poscondición: El material es reemplazado por la nueva información

suministrada por el usuario.

Descripción: La secretaria entra al sistema. Informa al sistema que desea

modificar un tipo de material existente. Modifica, el nombre o

las características de este material. El sistema despliega una

ventana preguntando si desea realizar los cambios al material

modificado. La secretaria confirma la modificación. El sistema

ID M2

Caso de uso: Adicionar material

Actores: Secretaria

Prioridad: 1

Precondición: El usuario ha ingresado en el sistema. No existe un material

con las mismas especificaciones del material que se desea

adicionar.

Poscondición: Un nuevo material es registrado en el sistema.

Descripción: La secretaria entra al sistema. Informa al sistema que desea

agregar un nuevo tipo de material. El sistema le solicita el

nombre del material y la descripción del mismo, así como el

número inicial de existencias del mismo. La secretaria

suministra los datos al sistema y solicita al sistema guardar la

información.. El sistema guarda los datos suministrados.

ID M3

Caso de uso: Solicitar material

Actores: Secretaria, Líder del ministerio

Prioridad: 2

Precondición: El usuario ha ingresado al sistema. El material solicitado

55

pertenece a uno de los tipos registrados en el sistema y hay

existencias del mismo.

Poscondición: En el sistema queda registrada una solicitud de material.

Descripción: El líder del ministerio ingresa al sistema. Solicita al sistema

que se suministre un tipo de material existente. Si el material

tiene existencia suficiente, el sistema deja una notificación a la

secretaria de que se ha solicitado un material específico,

además del número de elementos necesarios de ese material.

Si el material no tiene suficiente numero de existencia para

cubrir la solicitud, informa a la secretaria el número de

materiales que se solicitaron, el número de material existente,

y el número de material faltante para ser suministrado. La

secretaria revisa en el sistema el tipo de material que se ha

solicitado y lo suministra. Una vez suministrado, informa al

sistema de que la labor de solicitud de material ha finalizado.

El sistema informa al Líder del ministerio que el material esta

listo para ser utilizado.

ID M4

Caso de uso: Borrar material

Actores: Secretaria

Prioridad: 3

Precondición: El usuario ha ingresado en el sistema. Existe el material que

se desea borrar.

Poscondición: Queda eliminado del sistema el tipo de material especificado.

Descripción: La secretaria ingresa al sistema. Informa al sistema que desea

borrar un tipo de material existente. Selecciona al material que

desea borrar. Confirma que el material seleccionado es el que

desea borrar. El sistema borra el material seleccionado y las

56

existencias del mismo.

ID M5

Caso de uso: Mostrar material existente

Actores: Secretaria

Prioridad: 1

Precondición: El usuario ha ingresado en el sistema. Existe por lo menor un

material registrado en el sistema.

Poscondición: El sistema muestra en pantalla la consulta realizada.

Descripción: La secretaria ingresa al sistema. Selecciona un tipo de

material. Solicita al sistema que le muestre el material existe y

disponible para su uso. El sistema muestra en la pantalla una

lista del material, con la descripción del mismo y el número de

existencia.

ID M6

Caso de uso: Reducir material existente cuando se solicita

Actores: Secretaria

Prioridad: 2

Precondición: Se ha realizado una solicitud de material.

Poscondición: El sistema queda con menos material disponible, debido al

número de solicitudes de material atendidas.

Descripción: La secretaria ingresa al sistema. Revisa que material se le ha

solicitado suministrar. Suministra el material respectivo e

informa al sistema que el material ha sido suministrado. El

sistema reduce el número de existencias del material

solicitado y suministrado por la secretaria.

57


ID C1

Caso de uso: Adicionar personas que viajan

Actores: Líder misiones

Prioridad: 1

Precondición: El usuario ha ingresado en el sistema. Existe por lo menos una

persona en la lista de personas que pueden viajar de

misiones.

Poscondición: Se ha adicionado una nueva persona que viaja en el

calendario.

Descripción: El líder ingresa al sistema. Informa al sistema que desea

realizar un calendario nuevo para misiones. El sistema

despliega un formato de calendario con los días del mes. El

líder selecciona del calendario visual el día que desea

programas un viaje. El sistema le solicita los nombres de las

personas que viajan y la función que cumplen en el viaje. El

líder ingresa el nombre de las personas que viajan y sus

respectivas funciones. El líder también puede seleccionar un

equipo ya creado con anterioridad y guardado en el sistema

para que viajen en un ese día sin necesidad de ingresar

nombre por nombre. El sistema confirma que el equipo es el

correcto y guarda la información suministrada. Si se presenta

una frecuencia alta de viaje o se selecciona una persona que

ya fue seleccionada para otro viaje con anterioridad el sistema

informa del error al usuario. Si no se presenta ningún

problema, el sistema guarda los datos del viaje a realizarse en

el calendario.

ID C2

Caso de uso: Buscar persona en el calendario

58


Prioridad: 2

Precondición: El usuario ha ingresado en el sistema.

Poscondición: El sistema muestra en pantalla la información de la búsqueda.

En caso de no encontrar coincidencias, se muestra un

resultado fallido de la búsqueda.


realizar una búsqueda de una persona que ha sido adicionada

al calendario. El sistema solicita el nombre de la persona. El

calendario realiza el proceso de búsqueda en el calendario. Si

se encuentra la persona dentro del calendario informa, de su

existencia y el día que viaja la persona junto con las personas

que la acompañan (equipo).

ID C3

Caso de uso: Mostrar frecuencia viaje persona


Prioridad: 3

Precondición: El usuario ha ingresado en el sistema. Existe la persona de la

cual se quiere saber su frecuencia de viaje asignada por lo

menos a un viaje en el calendario.

Poscondición: El sistema muestra en pantalla la frecuencia de viaje de la

persona solicitada por el usuario.

Descripción: El líder ingresa al sistema. Informa al sistema que desea saber

la frecuencia de viajes que una persona tiene dentro del

calendario. El sistema solicita el al usuario el nombre de la

persona que desea consultar. El usuario ingresa el nombre de

la persona que desea conocer su frecuencia de viaje. El

sistema busca el nombre solicitado dentro del calendario y

59

calcula la frecuencia de viaje del mismo. El sistema muestra en

pantalla el nombre de la persona si se encuentra en el

calendario y su frecuencia de viaje respectiva. Si no se

encuentra dentro del calendario, informa de este hecho al

usuario.

ID C4

Caso de uso: Mostrar cruces del calendario


Prioridad: 1

Precondición: El usuario ha ingresado al sistema. Existe un calendario

creado.

Poscondición: El sistema muestra en pantalla los cruces que hay en el

calendario en la actualidad. Si no hay cruces lo informa al

usuario a través de un mensaje de texto en la pantalla.

Descripción: El líder ingresa al sistema. Ingresa un nombre específico para

ser adicionado al calendario. El sistema revisa que el nombre

ingresado no haya sido programado para un viaje en esa

misma fecha. Si se presenta una coincidencia en la fecha de

viaje, informa al usuario de la existencia de un cruce en la

asignación realizada. El líder debe borrar el nombre

seleccionado para ser ingresado en el calendario en esa fecha

o modificar la fecha de asignación del viaje.

ID C5

Caso de uso: Mostrar equipos del calendario


Prioridad: 4


creado.

60

Poscondición: El sistema muestra el equipo solicitado por el usuario. Si no

existe un equipo asignado al viaje, lo notifica al usuario.

Descripción: El líder entra al sistema. Informa al sistema que desea revisar

los nombres disponibles en el sistema que pueden ser usados

para ser asignados en el calendario. El sistema muestra en

pantalla una lista de todos los nombres disponibles en el

sistema que pueden ser usados para preparar el calendario.

ID C6

Caso de uso: Crear calendario


Prioridad: 1

Precondición: El usuario ha ingresado al sistema.

Poscondición: Se ha creado un nuevo calendario en blanco para ser editado.

Descripción: El líder entra en el sistema. Informa al sistema que desea crear

un calendario trimestral nuevo. El líder asigna los meses que

forman parte del calendario. El sistema crea un calendario

nuevo y despliega en pantalla un calendario visual con los días

de los meses en donde se programan viajes. El líder solicita

guardar el calendario. El sistema confirma la petición y guarda

el calendario para ser actualizado posteriormente.

ID C7

Caso de uso: Eliminar calendario


Prioridad: 2

Precondición: El usuario ha ingresado al sistema. Existe por lo menos un

calendario creado.

Poscondición: Se ha eliminado el calendario seleccionado por el usuario del

61

sistema.

Descripción: El líder entra en el sistema. Selecciona un calendario creado.

Informa al sistema que desea eliminarlo. El sistema confirma

la petición y elimina el calendario seleccionado.

ID C8

Caso de uso: Mostrar calendario


Prioridad: 1


creado en el sistema.

Poscondición: El sistema muestra en pantalla el calendario seleccionado por

el usuario.

Descripción: El líder ingresa al sistema. Selecciona un calendario específico

y solicita al sistema que le muestre el calendario. El sistema

despliega en pantalla el calendario solicitado.

ID C9

Caso de uso: Imprimir calendario


Prioridad: 4

Precondición: El usuario ha ingresado al sistema. Existe un calendario en el

sistema.

Poscondición: Se imprime un calendario seleccionado por el usuario.

Descripción: El líder selecciona un calendario del sistema y el sistema lo

despliega en pantalla. El usuario solicita al sistema que se

imprima el calendario abierto. El sistema envía la información

a la impresora y la impresora imprime el calendario.

62

ID C10

Caso de uso: Mostrar lista total de personas que pueden viajar en un

calendario


Prioridad: 2


Poscondición: Se muestra la lista de personas que pueden viajar en pantalla.

Si no hay nombres asignados a la lista el sistema informa de

la lista vacía al usuario.

Descripción: El líder ingresa al sistema. Solicita que el sistema muestre la

lista de personas que pueden viajar y ser asignadas en el

calendario. El sistema despliega en pantalla la lista solicitada.


ID P1

Caso de uso: Adicionar nombre a lista ministerio

Actores: Líder ministerio

Prioridad: 1


Poscondición: Se ha agregado un nuevo nombre a la lista del ministerio.

Descripción: Un líder de un ministerio específico ingresa al sistema.

Informa al sistema que desea agregar una persona a la lista

de personas autorizadas a viajar por el. Selecciona el

ministerio del cual es líder. El sistema solicita el nombre de la

persona a ingresar y una descripción adicional. El líder del

ministerio ingresa los datos que le solicita el sistema como

dirección, teléfono y situación espiritual.. El sistema guarda la

información suministrada de la persona agregada en la lista

del ministerio respectivo.

63

ID P2

Caso de uso: Modificar datos lista ministerio


Prioridad: 2


nombre en la lista del ministerio.

Poscondición: Se ha modificado la lista del ministerio del sistema.

Descripción: Un líder de un ministerio específico ingresa al sistema.

Informa al sistema que desea modificar los datos de una

persona de la lista de personas autorizadas a viajar por.

Selecciona el ministerio del cual es líder. El sistema solicita el

nombre de la persona a modificar o simplemente el líder

puede seleccionarlo de la lista que esta desplegada en

pantalla. El líder del ministerio modifica los datos de la

persona. El sistema guarda la información suministrada de la

persona modificada en la lista del ministerio respectivo.

ID P3

Caso de uso: Borrar lista ministerio


Prioridad: 3

Precondición: El usuario ha ingresado al sistema. Existe una lista de

ministerio creada en el sistema.

Poscondición: Se ha borrado la lista de ministerio del sistema.

Descripción: El líder del ministerio ingresa al sistema. Informa al sistema

que desea eliminar completamente la lista de personas

autorizadas a viajar de su ministerio. El sistema confirma la

petición realizada y elimina la lista de personas del ministerio

seleccionado.

64

ID P4

Caso de uso: Imprimir lista ministerio


Prioridad: 4

Precondición: El usuario ha ingresado al sistema. Existe una lista de

ministerio creada n el sistema.

Poscondición: Se ha impreso la lista de ministerio del sistema.

Descripción: El líder selecciona la lista de personas pertenecientes a su

ministerio y el sistema lo despliega en pantalla. El usuario

solicita al sistema que se imprima la lista. El sistema envía la

información a la impresora y la impresora imprime la lista.

ID P5

Caso de uso: Mostrar lista total ministerio por orden alfabético


Prioridad: 2


nombre registrado en la lista de ministerio del sistema.

Poscondición: Se muestra en pantalla la lista de ministerio en orden

alfabético.

Descripción: El líder ingresa al sistema. Solicita al sistema la lista de

personas correspondientes a su ministerio. El sistema

despliega en pantalla la lista solicitada en orden alfabético.

ID P6

Caso de uso: Mostrar personas por ministerio en orden alfabético


Prioridad: 2

65


nombre registrado en la lista de ministerio del sistema.

Poscondición: Se muestra en pantalla la lista de ministerio en orden

alfabético.

Descripción: El líder de misiones solicita al sistema la lista total de personas

de todos los ministerios de la iglesia que están autorizados por

sus respectivos lideres para viajar en misiones. El sistema

despliega en orden alfabético todas las personas disponibles

para viajara registradas en el sistema.

ID P7

Caso de uso: Buscar persona ministerio


Prioridad: 2

Precondición: El usuario ha ingresado al sistema. Existe por lo menos una

persona registrada n el sistema.

Poscondición: Se muestra en pantalla la información de la búsqueda

realizada por el usuario.

Descripción: El líder de misiones ingresa al sistema. Informa al sistema que

desea realizar una búsqueda en un ministerio específico. El

sistema despliega en pantalla la lista de ministerio disponible

de la iglesia. El usuario selecciona el ministerio que desea

consultar. El sistema solicita el nombre de la persona que

desea buscar. El usuario ingresa el nombre de la persona que

busca. El sistema muestra la persona y los datos de

descripción correspondiente a la misma.

ID P8

Caso de uso: Eliminar persona de la lista ministerio

66


Prioridad: 1

Precondición: El usuario ha ingresado en el sistema. Existe una persona con

el nombre que se desea borrar en la lista del ministerio.

Poscondición: Se elimina una persona de la lista del ministerio.

Descripción: El líder de ministerio ingresa al sistema. Solicita al sistema que

muestre la lista de personas del ministerio del cual es líder. El

sistema muestra la lista del ministerio respectivo. El usuario

selecciona la persona que desea eliminar de la lista. El usuario

solicita al sistema que sea eliminada la persona seleccionada.

El sistema confirma la petición y elimina la persona de la lista.

El sistema vuelve a mostrar la lista de personas en orden

alfabético.


ID T1

Caso de uso: Solicitar reserva pasaje

Actores: Líder misiones, Secretaria

Prioridad: 1


Poscondición: Se realiza una reserva en el sistema.


desea realizar una reserva de pasaje. El sistema solicita la

fecha del viaje y los datos de la persona que viaja. El usuario

ingresa la información que le solicita el sistema. El sistema

guarda la información y e informa a la secretaria que solicite la

reserva del pasaje solicitada. La secretaria realiza la reserva

en la aerolínea e informa al sistema de que la reserva ya fue

realizada. El líder de misiones revisa que la reserva se haya

67

realizada y queda informado del hecho.

ID T2

Caso de uso: Adicionar millas acumuladas

Actores: Secretaria

Prioridad: 3


Poscondición: Se adiciona un número de millas nuevas en el sistema.

Descripción: La secretaria ingresa al sistema. Informa al sistema que desea

adicionar un número de millas nuevo. El sistema solicita el

número de millas al usuario. La secretaria ingresa el número

de millas que es un valor entero y solicita al sistema que sea

guardado y sumado con los valores de millas existentes. El

sistema solicita la fecha de ingreso de las millas y la agencia a

la cual pertenecen las millas acumuladas. El usuario

suministra la información solicitada por el sistema. El sistema

guarda las millas y las computa con los valores acumulados

hasta la fecha.

ID T3

Caso de uso: Mostrar millas acumuladas


Prioridad: 3


Poscondición: El sistema muestra en pantalla el total de millas acumuladas

con sus respectivas agencias.

Descripción: El líder de misiones ingresa al sistema. Solicita que el sistema

muestre el total de millas acumuladas. El sistema despliega en

pantalla el total de millas acumuladas además de información

68

detallada de fecha y agencia de cada milla obtenida.

ID T4

Caso de uso: Mostrar datos pasaje


Prioridad: 1

Precondición: El usuario ha ingresado al sistema. Existe en el sistema la

reserva de pasaje que se desea consultar.

Poscondición: Se muestra en pantalla los datos del pasaje que solicito el

usuario.


desea consultar la información de reserva de un pasaje. El

sistema muestra los pasajes reservados hasta la fecha. El

usuario selecciona el pasaje de su interés. El sistema muestra

la información del pasaje en pantalla.

ID T5

Caso de uso: Mostrar personas con pasaje por confirmar

Actores: Líder misiones.

Prioridad: 2

Precondición: El usuario ha ingresado en el sistema. Existe por lo menos un

pasaje por confirmar.

Poscondición: El sistema muestra en pantalla una lista con las personas que

no han confirmado su pasaje.

Descripción: El líder de misiones ingresa al sistema Informa al sistema que

desea consultar la lista de personas que no han confirmado su

viaje y que tienen un pasaje de reserva. El sistema despliega

en pantalla la lista de personas que aun no han confirmado su

viaje en orden alfabético. El usuario queda informado.

69

ID T6

Caso de uso: Mostrar personas con pasaje confirmado


Prioridad: 2

Precondición: El usuario ha ingresado en el sistema. Existe por lo menos un

pasaje confirmado.

Poscondición: El sistema muestra en pantalla una lista con las personas que

han confirmado su pasaje.

Descripción: El líder de misiones ingresa al sistema Informa al sistema que

desea consultar la lista de personas que han confirmado su

viaje y que tienen un pasaje de reserva. El sistema despliega

en pantalla la lista de personas que aun han confirmado su

viaje en orden alfabético. El usuario queda informado.

ID T7

Caso de uso: Solicitar confirmación pasaje


Prioridad: 2

Precondición: El usuario ha ingresado al sistema. Existe una reserva de

pasaje del cual se desea solicitar confirmación.

Poscondición: Se ha realizado una solicitud de confirmación en el sistema de

un pasaje solicitado.


necesita realizar una reserva de un pasaje. Una vez realizada

la reserva, el sistema solicita que se confirme que la persona

encargada del viaje efectivamente puede viajar en esa fecha.

El sistema queda a la espera de una confirmación de pasaje.

70

ID T8

Caso de uso: Confirmar pasaje

Actores: Secretaria, Viajero

Prioridad: 1

Precondición: El usuario ha ingresado al sistema. Existe una solicitud de

confirmación de pasaje en el sistema.

Poscondición: Se ha confirmado el pasaje en el sistema.

Descripción: La secretaria ingresa al sistema. Solicita al sistema que le

muestre las reservas de pasajes que no han sido confirmadas.

El sistema muestra la lista de personas que no han confirmado

su viaje. La secretaria solicita la información de la persona que

no ha confirmado su pasaje. La secretaria se comunica con la

persona respectiva y confirma el viaje. El viajero informa si

puede o no viajar en la fecha asignada. Si puede viajar la

secretaria confirma el pasaje reservado. Si no puede viajar la

secretaria realiza una nueva reserva.

ID T9

Caso de uso: Modificar datos pasaje

Actores: Secretaria

Prioridad: 2

Precondición: El usuario ha ingresado al sistema. Existe un pasaje en el

sistema el cual se quiere modificar.

Poscondición: Se ha modificado el pasaje seleccionado por el usuario con los

nuevos datos ingresados en el sistema.

Descripción: La secretaria ingresa al sistema. Solicita al sistema que le

muestre la lista de pasajes reservados. Selecciona un pasaje

del sistema y el sistema muestra en pantalla los datos del

mismo. La secretaria informa al sistema que desea hacer una

71

modificación al pasaje seleccionado. Se modifican los datos

necesarios y se solicita al sistema que guarde los cambios. El

sistema confirma la operación y guarda los datos modificados

del pasaje.

ID T10

Caso de uso: Eliminar pasaje


Prioridad: 1

Precondición: El usuario ha ingresado al sistema. Existe el pasaje que se

desea eliminar en el sistema.

Poscondición: El sistema elimina el pasaje he informa al usuario de este

hecho.

Descripción: El líder ingresa al sistema. Solicita al sistema que le muestre la

lista de reserva de pasajes. El usuario selecciona el pasaje

que desea eliminar de la lista. Solicita al sistema que sea

eliminado. El sistema confirma la operación y elimina el pasaje

seleccionado.


ID O1

Caso de uso: Actualizar datos obras

Actores: Líder equipo encargado

Prioridad: 2

Precondición: El usuario ha ingresado al sistema. Existe en el sistema la obra

que se desea modificar.

Poscondición: Se han actualizado los datos de la obra solicitada por el

usuario.

Descripción: El líder del equipo encargado ingresa al sistema. Informa al

72

sistema que desea actualizar los datos que se encuentran

registrados en la obra. El sistema pregunta al usuario si desea

actualizar los datos de una obra madura o menor. Si es una

obra madura, el usuario solo tiene que llenar los datos actuales

de número de profesiones de fe, asistencia y ofrenda. Si es

una obra menor, debe llenar datos adicionales. Los datos son

guardados en el sistema para futuras consultas.

ID O2

Caso de uso: Adicionar obra madura

Actores: Líder Misiones

Prioridad: 1

Precondición: El usuario ha ingresado al sistema. No existe una obra madura

con la misma información a ingresar por el usuario.

Poscondición: El sistema ha creado una nueva obra madura.

Descripción: El líder entra al sistema e informa al mismo que desea crear

una obra madura en el sistema. El sistema le solicita el

nombre de la obra, y solicita la información inicial de

profesiones de fe, asistencia, ofrenda. El sistema guarda los

datos suministrados para futuras consultas.

ID O3

Caso de uso: Adicionar obra menor


Prioridad: 1

Precondición: El usuario ha ingresado al sistema. No existe una obra menor

con la misma información a ingresar por el usuario.

Poscondición: El sistema ha creado una nueva obra menor.

Descripción: El líder entra al sistema. Informa al sistema que desea

73

ingresar los datos de la obra a la cual representa. El sistema

le solicita datos como: la fecha de creación de la obra, las

actividades que se están realizando en la misma, as

direcciones de las familias a las que se esta llegando y los

teléfonos y nombres de los contactos que se están haciendo

en la misma. Igualmente se ingresa información referente al

estado espiritual de la obra. El sistema guarda la información

para futuras consultas.

ID O4

Caso de uso: Modificar obra madura


Prioridad: 2

Precondición: El usuario ha ingresado al sistema. Existe la obra madura que

el usuario desea modificar registrada en el sistema

Poscondición: Se ha modificado una obra madura y se ha registrado en el

sistema.


modificar los datos básicos de una obra. El sistema le solicita

una nueva fecha de creación, un nombre y datos básicos

necesarios para la existencia de una obra madura en el

sistema. El sistema modifica los datos antiguos con los

nuevos ingresados para futuras consultas.

ID O5

Caso de uso: Modificar obra menor

Actores: Líder equipo encargado

Prioridad: 2

Precondición: El usuario ha ingresado al sistema. Existe la obra menor que

74

el usuario desea modificar registrada en el sistema

Poscondición: Se ha modificado una obra menor y se ha registrado en el

sistema.

Descripción: El líder del equipo encargado de la obra, ingresa al sistema.

Informa al sistema que desea modificar los datos de una obra

menor. El sistema le solicita los datos a cambiar. El sistema

guarda los datos modificados para futuras consultas.

ID O6

Caso de uso: Eliminar obra


Prioridad: 1

Precondición: El usuario ha ingresado al sistema. Existe la obra que el

usuario desea eliminar registrada en el sistema.

Poscondición: El sistema ha eliminado la obra seleccionada por el usuario.


desea eliminar del sistema una obra. El sistema le muestra

una lista de las obras que están disponibles en el sistema. El

líder selecciona una de las obras mostradas en pantalla. El

sistema confirma que realmente desea borrar la obra. El líder

confirma su deseo de eliminar la obra del sistema. El sistema

borra todos los datos de la obra del sistema.

ID O7

Caso de uso: Mostrar datos obra madura


Prioridad: 2

Precondición: El usuario ha ingresado al sistema. Existe registrada en el

sistema la obra madura que el usuario desea consultar.

75

Poscondición: El sistema muestra en pantalla los datos de la obra madura

que el usuario solicitó.


realizar una consulta sobre una obra registrada en el sistema.

El sistema le muestra una lista de las obras maduras

disponibles en el sistema. El líder selecciona una obra. El

sistema muestra los datos de profesiones de fe, asistencia,

ofrenda de la obra selecciona en una tabla en pantalla.

ID O8

Caso de uso: Mostrar datos obra menor


Prioridad: 2

Precondición: El usuario ha ingresado al sistema. Existe registrada en el

sistema la obra menor que el usuario desea consultar.

Poscondición: El sistema muestra en pantalla los datos de la obra menor que

el usuario solicitó.


realizar una consulta sobre una obra registrada en el sistema.

El sistema le muestra una lista de las obras menores

disponibles en el sistema. El líder selecciona una obra. El

sistema muestra los datos actuales de la obra consultada en

pantalla.


ID R1

Caso de uso: Registrar Líder de Misiones


Prioridad: 1

76

Precondición: No existe un líder de misiones registrado en el sistema

Poscondición: Se ha registrado un líder de misiones en el sistema

Descripción: El líder de misiones ingresa al sistema. Informa al sistema

que va a registrar los datos de ingreso al sistema como líder

de misiones. El sistema le pide los datos personales al líder y

adicionalmente pide un nombre de usuario y un password. El

líder le proporciona los datos que pide el sistema. El sistema

proporciona los permisos de un líder de misiones y guarda la

información para su futuro ingreso.

ID R2

Caso de uso: Registrar Secretaria


Prioridad: 1

Precondición: No existe una secretaria registrada en el sistema

Poscondición: Se ha registrado una secretaria en el sistema


que va a registrar una secretaria nueva. El sistema le pide los

datos personales al líder y adicionalmente pide un nombre de

usuario y un password para la secretaria. El líder le

proporciona los datos que pide el sistema. El sistema guarda

la información y registra una secretaria con sus respectivos

permisos de acceso para su futuro ingreso.

ID R3

Caso de uso: Registrar Líder Obra


Prioridad: 1

Precondición: No existe un líder de obra registrado en el sistema

77

Poscondición: Se ha registrado un líder de obra en el sistema


que va a registrar un líder de obra nuevo. El sistema le pide

los datos del líder de obra al líder y adicionalmente pide un

nombre de usuario y un password para el líder de obra. El

líder le proporciona los datos que pide el sistema. El sistema

guarda la información y registra al líder de obra con los

permisos de acceso respectivos para su futuro ingreso.

ID R4

Caso de uso: Registrar Líder Ministerio


Prioridad: 1

Precondición: No existe un líder de ministerio registrado en el sistema

Poscondición: Se ha registrado un líder de ministerio en el sistema


que va a registrar un líder de ministerio nuevo. El sistema le

pide los datos del líder de obra al líder y adicionalmente pide

un nombre de usuario y un password para el líder de

ministerio. El líder le proporciona los datos que pide el

sistema. El sistema guarda la información y registra al líder de

obra con los permisos de acceso respectivos para su futuro

ingreso.

78

4.3 DIAGRAMAS DE CASOS DE USO

4.3.1 Funciones Manejo Material

Adicionar material

Modificar material

Solicitar material

Borrar material

Mostrar material

existente

Modificar material

Reducir material

existente


Buscar persona en

el calendario

Adicionar personas que viajan

Mostrar frecuencia

viaje persona

Mostrar cruces del calendario

Mostrar equipos del calendario

Crear calendario Eliminar

calendario

Mostrar calendario

Imprimir calendario

Mostrar lista total personas

que pueden viajar

79


Modificar datos lista ministerio

Adicionar nombre a lista

ministerio

Borrar lista ministerio

Imprimir lista ministerio

Buscar persona

ministerio

Mostrar personas por ministerio en

orden alfabetico

Mostrar lista total ministerio

en orden al fabetico

Eliminar persona de lista

ministerio


Adicionar millas

Solicitar reserva pasaje

Mostrar frecuencia

viaje persona

Mostrar millas

acumuladas

Mostrar personas con

pasaje confirmado

Solicitar confirmacion

pasaje Mostrar personas con

pasaje por confirmar

Mostrar datos pasaje

Confirmar pasaje

Modificar datos pasaje

Eliminar pasaje

80


Adicionar obra madura

Actualizar datos obra

Adicionar obra menor

Mostrar millas

acumuladas

Mostrar datos obra madura

Modificar obra menor

Mostrar datos obra

menor

Modificar obra madura

Eliminar obra


Registrar Secretaria

Registrar Lider de Misiones

Registrar Lider de

Obra

Registrar Lider de

Ministerio

81

4.4 INTERFAZ DEL SISTEMA

4.4.1 Interfaz Login

4.4.2 INTERFAZ USUARIOS 4.4.2.1 Líder de Misiones

82

4.4.2.2 Secretaria

4.4.2.3 Líder de Obra

83

4.4.2.4 Líder Ministerio

4.4.3 MODULO MATERIALES

4.4.3.1 Interfaz Principal

84

4.4.3.2 Modificar Material

4.4.3.3 Adicionar Material

85

4.4.3.4 Confirmación Material

86

4.4.4 MODULO MINISTERIO


4.4.4.2 Adicionar Miembro

87

4.4.4.3 Confirmación Miembro

4.4.4.4 Consultar Datos Miembro

88

4.4.4.5 Modificar Miembro

4.4.5 MODULO PASAJES


89

4.4.5.2 Solicitud Pasaje

4.4.5.3 Confirmación Solicitud Pasaje

90

4.4.5.4 Consultar Datos Pasaje

4.4.5.5 Modificar Pasaje

91

4.4.6 MODULO USUARIOS


4.4.6.2 Adicionar Usuario

92

4.4.6.3 Confirmación Usuario

4.4.6.4 Consulta Usuario

93

4.4.6.5 Modificar Usuario

4.4.6.6 Cambio De Contraseña

94

4.4.7 MODULO OBRAS


4.4.7.2 Obra Menor

95

4.4.7.2.1 Adicionar Obra

4.4.7.2.2 Confirmación Obra

96

4.4.7.2.3 Consultar Obra Menor

4.4.7.2.4 Adicionar Miembros A Equipo Obra Menor

97

4.4.7.3 Obra Mayor

4.4.7.3.1 Adicionar Obra Mayor

98

4.4.7.3.2 Confirmación Obra Mayor

4.4.7.3.3 Consultar Obra Mayor

99

4.4.7.3.4 Adicionar Datos Obra Mayor

100

5 PRUEBAS Y ESTADO FINAL DEL SISTEMA

5.1 PRUEBAS AL SISTEMA

Durante el desarrollo de cada módulo se llevaron a cabo dos tipos de pruebas:

pruebas en tiempo de desarrollo y pruebas después de la programación.

A medida que se necesitaban datos en el Servidor Web para hacer las pruebas de

la programación de las páginas, era necesario poblar la Base de datos del

Servidor Web.

El objetivo de estas pruebas es comprobar la integridad de los datos, verificar si

los datos son los datos que requiere el servidor Web.

Las pruebas en tiempo de desarrollo fueron realizadas durante toda la etapa de

programación y empalme de los módulos que conforman el software.

Las pruebas después de la programación se efectúan cuando se considera que un

módulo está terminado en su totalidad y se denominan “Pruebas Sistemáticas”.

Su objetivo principal consiste en buscar fallos mediante un criterio específico. Para

realizarlas, se tienen en cuenta dos criterios principales: Pruebas de caja negra y

Pruebas de caja blanca.

Las pruebas de caja blanca fueron realizadas de manera informal y constante

durante las etapas de desarrollo del software, y pretendían:

- Garantizar que la ejecución de todos los caminos posibles para realizar una

acción determinada fuera satisfactoria.

- Probar todas las decisiones de tipo lógico en sus límites verdadero y falso.

- Ejercitar las estructuras de datos internas para asegurar su validez.

101

Las pruebas de caja negra fueron llevadas a cabo por personas naturales y de

manera formal; se enfocan directamente en el exterior del modulo; el código no es

tan representativo en esta etapa ya que estas pruebas son más funcionales y

tienen como objetivo detectar:

- Fallas en la interfaz de usuario

- Fallas en la apariencia de los menús

- Funciones incorrectas o ausentes

- Errores en estructuras de datos

- Errores de rendimiento

- Errores de inicialización y terminación

Algunos de los detalles que se tuvieron en cuenta al realizar estas pruebas fueron:

- Enlaces entre las páginas correspondientes al registro e inicio de sesión.

- Conexión a la base de datos

- Validación de los datos a ingresar en la base de datos

- Ingreso de registros

- Envío de formularios al registro e inicio de sesión

- Finalización de la sesión activa para un usuario cualquiera

- Manejo de variables de sesión

- Envío de formularios a paginas receptoras

- Modificación y eliminación de registros

- Interfaz gráfica

- Correcta ejecución de las consultas SQL (resultados de búsquedas)

102

6. CONCLUSIONES

Se desarrolló un módulo Web que con algunos requisitos básicos de hardware y

software, permite al usuario administrar de forma efectiva toda la información

correspondiente a los viajes que realizan equipos misioneros hacia diferentes

lugares del territorio colombiano.

Con la elaboración del proyecto se logra el objetivo de ofrecer un producto

totalmente nuevo a muy bajo costo, haciendo uso de herramientas investigativas

de open source que adicionalmente puede interactuar con cualquier otra solución

web vigente en el mercado.

Adicionalmente el uso Hibernate como tecnología para el manejo de persistencia

de la aplicación me permitió conocer una solución para la integración de modelos

de entidad relación y modelos orientados a objetos. La utilización de Hibernate

agilizo el proceso de implementación de la persistencia de la aplicación Web

logrando por medio de tecnología XML evitar complicaciones que se pudieran

presentar al manejar la persistencia de forma tradicional haciendo uso de las

respectivas clases para manejo de conexiones y sentencias SQL en Java.

A nivel personal, se vivió una gran experiencia al trabajar como profesor de tesis

con un profesional idóneo y consagrado, que me enseño el sentido de la

responsabilidad en el trabajo y la importancia de aplicar el aseguramiento de

calidad en cada labor desarrollada para garantizar el éxito del proyecto y crear una

imagen personal de cumplimiento, honestidad y confianza.

El participar paso a paso en la implementación e implantación del proyecto en un

cliente específico enriqueció todos aquellos aspectos académicos que se habían

adquirido en la formación como Ingeniero de Sistemas. La investigación de

campo y la práctica de prueba y error permitió cumplir los objetivos de aprender a

configurar servidores e instalar herramientas seguras de bajo costo, igualmente se

103

participó en el diseño de un entorno amigable, funcional, llamativo y seguro, se

diseñaron e implementaron las interfaces necesarias que permiten el manejo de

los datos entre el Servidor de la Web.

104

7. RECOMENDACIONES Y TRABAJO FUTURO

La aplicación Web desarrollada puede ser enriquecida mediante el desarrollo de

nuevas utilidades, tales como, manejo de calendarios, integración con dispositivos

móviles, manejo financiero del ministerios e misiones y otros aspectos importantes

que le permitan a La Biblia Dice colaborar en la búsqueda de una mejor

administración de los procesos que se llevan a cabo en ministerio.

El modulo de generación de calendarios estaba programado dentro del

cronograma. Este modulo no pudo culminarse debido al tiempo dedicado en el

entendimiento de las diferentes tecnologías que componen la aplicación que se

desarrollo. La culminación de este modulo que permita de manera dinámica y a

través de la aplicación programas a las personas que viajan a lo largo de un

trimestre a las diferentes obras es el paso a seguir que deber tomarse en el

mejoramiento y trabajo futuro de la aplicación. Adicionalmente se puede

enriquecer la aplicación con nuevas funciones.

Se espera realizar un mejoramiento de las funcionalidades e la aplicación con el

fin de apoyar el fin para el cual se concibió la elaboración del proyecto que

contemplaba como plan principal dinamizar los procesos de administración del

ministerio de misiones de La Biblia Dice haciendo uso de herramientas de bajo

costo y bajo el fundamento de tecnología Web.

A nivel de la Escuela de Ingeniería de Sistemas, es muy importante que animen a

los estudiantes a realizar proyectos de grado basados en tecnología Web, ya que

la mayoría de proyectos en el área profesional están basados en el uso de este

tipo de tecnología debido al auge de integración que las empresas viven hoy en

día.

105

8. BIBLIOGRAFÍA

[1] INGENIERÍA DEL SOFTWARE – Un enfoque práctico. PRESSMAN Roger S.

Mc. Graw Hill.

[2] SERVLETS Y JAVASERVER PAGES. Marty Hall. Primera Edicion. Editorial:

Pearson Educacion, Mexico, 2000.

[3] TEACH YOURSELF JAVA IN 21 DAYS. Laura Lemay, Charles L. Perkins.

First Edition. Editorial: Sams.net Publishing and its licensors, 1996.

[4] SUN EDUCATIONAL SERVICES, J2EE PATTERNS. Volumen 2 de 3 (

modules 11-B). Editorial: Sun Microsistems, 2001.

[5] Beginning JSP Web Development, Jayson Falkner (Author), John Timney,

Casey Kochmer, Romin Irani, Perrumal Krishnaraj, Meeraj Moidoo Kunnumpurath,

Sathya Narayana Panduranga, Ben Galbraith

[6] [7] [8] Páginas WEB:

o http://www.verextremadura.com/miguel/jsp/index.htm

Manual de JSP

o http://www.informaticamilenium.com.mx/paginas/espanol/sitioweb.ht

m#top

o http://www.adap.es/utilidades/internet/generalidades/protocolos.htm

o http://www.arsys.es/soporte/generalidades/redes.htm

o http://www.peruserver.com/des_metodologia.php

o http://ant.apache.org/

o http://java.sun.com

106

ANEXO A.

DESCRIPCION DE LAS TABLAS DE LA BASE DE DATOS DEL SISTEMA. Base de datos: sam

material Tabla para manejo de persistencia de los materiales utilizados

en el ministerio de misiones.

Obra Tabla para manejo de persistencia de las obra menores a las

cuales se esta llegando en el territorio colombiano. miembro Tabla para el manejo de persistencia de los miembros que

hacen parte del ministerio. obraMayor Tabla para el manejo de persistencia de las obras mayores a

las cuales se esta llegando en el territorio colombiano. pasaje Tabla para el manejo de persistencia de los pasajes que se

solicitan para realizar viajes a las diferentes obras.

usuario Tabla para el manejo de persistencia de los usuarios que

ingresan al sistema web de administración de misiones.

seq_material Tabla generada por Hibernate para el manejo de materiales

del sistema. seq_miembro Tabla generada por Hibernate para el manejo de los miembros

que hacen parte del ministerio.

107

seq_obra Tabla generada por Hibernate para el manejo de obras

menores del sistema.

seq_obraMayor Tabla generada por Hibernate para el manejo de obras

mayores del sistema. seq_pasaje Tabla generada por Hibernate para el manejo de pasajes del

sistema.

seq_user Tabla generada por Hibernate para el manejo de usuarios del

sistema.

Documents

LUIS ALFREDO BETANCOURT MALDONADO