CAPTULO I MARCO METODOLGICO

En este apartado se incluir la descripcin del contexto general de la problemtica, donde se presentar el planteamiento del problema, los objetivos generales y particulares que se desean alcanzar, las tcnicas e instrumentos de medicin que se utilizarn, el universo y las muestras de aplicacin, la justificacin y relevancia de estudio adems de la hiptesis que se desea comprobar. 1.1Planteamiento del Problema Cuando se presenta un siniestro o accidente vehicular se presentan los siguientes problemas que impiden el seguimiento eficiente del mismo. - Prdida de tiempo valioso al tratar de contactarse con la aseguradora. - El ajustador asignado, suele ser el que se encuentra ms lejos de la ubicacin donde ocurri el siniestro. - Actualmente no se cuenta con el tiempo promedio en que dicho ajustador arribar al lugar del siniestro vehicular.

Figura No.1 Siniestro Vehicular 1.2 Caso de Estudio Cuando desgraciadamente se presenta un siniestro o accidente vehicular aparte de sufrir la amarga experiencia que eso conlleva, se pierde demasiado tiempo en tratar de contactarte con tu aseguradora para que se hagan cargo de dicho siniestro; cuando al fin lo haces el ajustador asignado para ti suele ser el que se encuentra ms lejos de la ubicacin donde ocurri el siniestro y por lo tanto mucho tiempo en llegar. Nunca se tiene el tiempo promedio en que dicho ajustador arribara a auxiliarte ni el lugar exacto de donde viene y en algunos casos el tiempo es fundamental para evitar que los dems involucrados traten de evadir sus responsabilidades. Por eso surge la necesidad de que los clientes puedan dar aviso de manera inmediata desde una terminal personalizada que bien pudiera ser un dispositivo mvil, llamase telfono celular.

1.3 Objetivos generales y especficos

Objetivo General Desarrollar una aplicacin mvil tanto para los clientes como para los ajustadores de la aseguradora. Monitoreado y gestionado desde una central de servicio cuyo objetivo es optimizar el tiempo de arribo y la comunin; as como la gestin y seguimiento de los siniestros; esto mediante un sistema integral mvil que sirva de enlace entre: Objetivo Especfico 1.- El usuario podr dar parte de un accidente desde su dispositivo mvil para acelerar todos los trmites relacionados con el siniestro. 2.- El usuario podr enviar fotografas del accidente y del estado del vehculo, as como informacin adicional y necesaria para levantar un reporte del siniestro. 3.- El cliente recibir un mensaje que confirmar la apertura del siniestro con un nmero de folio la cual le llegara al ajustador ms cercano. 4.- Se enviara la informacin al usuario del ajustador asignado; as como el tiempo aproximado de llegada y punto de origen del mismo. Esto va mensaje para que el usuario lo pueda estar monitoreando. 5.- La aplicacin permitir buscar el taller de reparacin ms cercano o agencia en su caso para que el cliente acuda inmediatamente en caso de ser necesario. 6.-La aplicacin contar con un directorio a travs del cual se puede llamar a los telfonos ms importantes para los asegurados. 1.4 Justificacin El proyecto abarcar completamente la gestin de un siniestro, identificando los puntos que abarca cada siniestro (datos del usuario, datos pliza, datos evaluador de siniestro), con el objetivo de dar un mejor servicio al cliente y de manera oportuna. En el mercado existen una infinidad de compaas aseguradoras las cuales tratan de brindar este servicio de la mejor manera que pueden (en algunos casos); pero como el servicio que brindar es de naturaleza La finalidad del proyecto es brindar un soporte confiable y estable a los usuarios pertenecientes a la aseguradora (clientes, trabajadores), agilizando los procesos que se llevan a cabo actualmente. El cliente o asegurado. Central de servicio. Ajustador

La aportacin de las carreras de Ingeniera en Informtica y Licenciatura en Ciencias de la Informtica en el desarrollo del proyecto se enfoca principalmente en la aplicacin de los conocimientos adquiridos para llevar a cabo el anlisis, diseo, desarrollo e implementacin del proyecto, de acuerdo a un estudio de mercado previamente realizado, esto incluye la optimizacin de los procesos y el manejo ptimo de la informacin de acuerdo a la seleccin de las tecnologas adecuadas. Todo esto para brindar un ambiente de proteccin total al cliente y con la posibilidad de que pueda monitorear el avance de las tecnologas de informacin para su beneficio.

CAPTULO II MARCO TERICO Y REFERENCIAL

El captulo describe los temas necesarios para el desarrollo de la aplicacin y que proporcionaran los conocimientos para trabajar con las herramientas, Modelos y Metodologas informticas ms resientes en la actualidad. Tambin se considerarn las reglas negocio necesarias para que la

aplicacin opere de forma correcta facilitando el trabajo de los ajustadores y clientes de las aseguradoras. A continuacin se mencionarn los temas que utilizaremos como base para nuestro proyecto. 2.1 Diseo y desarrollo del software El Diseo de software se define el proceso de aplicar ciertas tcnicas y principios con el propsito de definir un dispositivo, un proceso, con suficientes detalles como para permitir su interpretacin y realizacin fsica. La etapa del Diseo del Sistema encierra cuatro etapas:

El diseo de los datos. Trasforma el modelo de dominio de la informacin, creado durante el anlisis, en las estructuras de datos necesarios para implementar el Software. El Diseo Arquitectnico. Define la relacin entre cada uno de los elementos estructurales del programa. El Diseo de la Interfaz. Describe como se comunica el Software consigo mismo, con los sistemas que operan junto con l y con los operadores y usuarios que lo emplean. El Diseo de procedimientos.

El Diseo del Software es un proceso y un modelado a la vez. El proceso de Diseo es un conjunto de pasos repetitivos que permiten al diseador describir todos los aspectos del Sistema a construir. A lo largo del diseo se evala la calidad del desarrollo del proyecto con un conjunto de revisiones tcnicas: El diseo debe implementar todos los requisitos explcitos contenidos en el modelo de anlisis y debe acumular todos los requisitos implcitos que desea el cliente. Debe ser una gua que puedan leer y entender los que construyan el cdigo y los que prueban y mantienen el Software. El Diseo debe proporcionar una completa idea de lo que es el Software, enfocando los dominios de datos, funcional y comportamiento desde el punto de vista de la Implementacin.

Diseo de Interacciones con la Base de Datos

La mayora de los sistemas de informacin ya sean implantado en sistemas de cmputos grandes o pequeos, utilizan una base de datos que pueden abarcar varias aplicaciones, por esta razn estos sistemas utilizan u administrador de base de datos, en este caso el diseador no construye la base de datos sino que consulta a su administrador para ponerse de acuerdo en el uso de esta en el sistema.

Herramientas para el Diseo de Sistemas

Apoyan el proceso de formular las caractersticas que el sistema debe tener para satisfacer los requerimientos detectados durante las actividades del anlisis: Herramientas de especificacin

Apoyan el proceso de formular las caractersticas que debe tener una aplicacin, tales como entradas, Salidas, procesamiento y especificaciones de control. Muchas incluyen herramientas para crear especificaciones de datos. Herramientas para presentacin

Se utilizan para describir la posicin de datos, mensajes y encabezados sobre las pantallas de las terminales, reportes y otros medios de entrada y salida. Herramientas para el desarrollo de Sistemas

Estas herramientas nos ayudan como analistas a trasladar diseos en aplicaciones funcionales. Todas las organizaciones son Sistemas que actan de manera recproca con su medio ambiente recibiendo entradas y produciendo salidas. Los Sistemas que pueden estar formados por otros Sistemas de denominan Sub-sistemas y funcionan para alcanzar los fines de su implantacin (http://alarcos.inf-cr.uclm.es/doc/ISOFTWAREI/Tema04.pdf). 2.1.1 RUP El Proceso Unificado de Racional es un proceso de desarrollo de software y junto con el Lenguaje Unificado de Modelado UML, constituye la metodologa estndar ms utilizada para el anlisis, implementacin y documentacin de sistemas orientados a objetos. Caractersticas de RUP Forma disciplinada de asignar tareas y responsabilidades (quin hace qu, cundo y cmo) Pretende implementar las mejores prcticas en Ingeniera de Software Desarrollo iterativo Administracin de requisitos Uso de arquitectura basada en componentes Control de cambios Modelado visual del software Verificacin de la calidad del software

2.1.2 Metodologa RUP Inicio

En esta etapa del desarrollo se pretende crear los modelados de negocio, en donde se tomar la parte esencial de los procesos que hacen referencia a la determinacin de los costos y presupuestos, asimismo los tiempos estimados en cada uno de estos procesos a realizar. En esta parte lo esencial que se pretende mostrar el objetivo y las capacidades del software a desarrollar. Elaboracin

En esta etapa se desarrollar en cuanto al flujo de informacin las actividades a realizar en cada uno de los procesos proponiendo las ms adecuadas tomas de decisiones para el buen manejo de informacin de acuerdo a los recursos disponibles y a una arquitectura bsica, asimismo determinar las tareas en los proceso para un mejor funcionamiento del software a realizar. Construccin

En esta etapa se trata de documentar el software de acuerdo a la informacin recopilada a travs de los casos de uso, de esta forma nos permitir visualizar de una forma global el flujo de informacin, as como el anlisis, entre otras actividades como son las pruebas, etc. Transicin

En esta etapa se llevan a cabo la instalacin, configuracin, empaquetado, mantenimiento, soporte en los diferentes equipos. Cabe mencionar que es parte esencial para los usuarios finales, en donde se les llevara a cabo la capacitacin de estos a travs de los manuales de usuarios, los requerimientos entre otros (http://www.ibm.com/developerworks/rational/library/content/03July/1000/1251/1251_bestpractices_ TP026B.pdf).

Fig. 2 Metodologa RUP

2.1-3 Ciclo de vida Un modelo de ciclo de vida define el estado de las fases a travs de las cuales se mueve un proyecto de desarrollo de software. Un modelo de ciclo de vida de software es una vista de las actividades que ocurren durante el desarrollo de software, intenta determinar el orden de las etapas involucradas y los criterios de transicin asociadas entre estas etapas.

Fig. 3 Ciclo de Vida de Software Celular Un modelo de ciclo de vida del software: Describe las fases principales de desarrollo de software. Define las fases primarias esperadas de ser ejecutadas durante esas fases. Ayuda a administrar el progreso del desarrollo, y Provee un espacio de trabajo para la definicin de un detallado proceso de desarrollo de software (http://es.kioskea.net/contents/genie-logiciel/cycle-de-vie.php3). 2.1.4 Ingeniera de Software Ingeniera de software es la disciplina o rea de la informtica que ofrece mtodos y tcnicas para desarrollar y mantener software de calidad. El trmino ingeniera de software abarca al grupo de mtodos, tcnicas y herramientas que se utilizan en la produccin del software, ms all de la actividad principal de programacin. En la construccin y desarrollo de proyectos se aplican mtodos y tcnicas para resolver los problemas, la informtica aporta herramientas y procedimientos sobre los que se apoya la ingeniera de software. Mejorar la calidad de los productos de software

Aumentar la productividad y trabajo de los ingenieros del software. Facilitar el control del proceso de desarrollo de software. Suministrar a los desarrolladores las bases para construir software de alta calidad en una forma eficiente.

Definir una disciplina que garantice la produccin y el mantenimiento de los productos software desarrollados en el plazo fijado y dentro del costo estimado.

Fig. 4 Ing. de Software Objetivos de los proyectos de sistemas Para que los objetivos se cumplan las empresas emprenden proyectos por las siguientes razones: Capacidad *Aumento en el volumen: * Recuperacin ms rpida de la informacin: Costo * Vigilancia de los costos: * Reduccin de costos: Control *Mayor seguridad de informacin: *Menor margen de error: (mejora de la exactitud y la consistencia) Comunicacin * Interconexin: (aumento en la comunicacin)

* Integracin de reas en las empresas: Competitividad * Asegurar clientes: * Dejar fuera a los competidores: Mtodo del ciclo de vida clsico Por lo tanto, la ingeniera de software requiere la gestin de proyectos para que se pueda desarrollar una aplicacin en el plazo previsto y con el presupuesto establecido que sea satisfactoria para el cliente (el concepto de calidad). Ingeniera de requerimientos Ingeniera de requerimientos es un enfoque sistmico para recolectar, organizar y documentar los requerimientos del sistema; es tambin el proceso que establece y mantiene acuerdos sobre los cambios de requerimientos, entre los clientes y el equipo del proyecto Esta ingeniera comprende, bsicamente, todo el proceso y tareas involucradas en la Captura, Licitacin, Anlisis y Especificacin de Requisitos o requerimientos. La comunidad internacional se decant por el uso de la palabra Requerimientos en lugar de Requisitos, para resolver una posible ambigedad en el uso de los trminos. Actualmente el usar la palabra Requisito debe ser documentado explicando el motivo su uso en lugar del trmino consensuado. El propsito de la ingeniera de requerimientos es hacer que los mismos alcancen un estado ptimo antes de alcanzar la fase de diseo en el proyecto. Los buenos Requerimientos deben ser medibles, comprobables, sin ambigedades o contradicciones, etc. Caractersticas de los requerimientos

Las caractersticas de un requerimiento son sus propiedades principales. Un conjunto de requerimientos en estado de madurez, deben presentar una serie de caractersticas tanto individualmente como en grupo. A continuacin se presentan las ms importantes.

Necesario: Un requerimiento es necesario si su omisin provoca una deficiencia en el sistema a construir, y adems su capacidad, caractersticas fsicas o factor de calidad no pueden ser reemplazados por otras capacidades del producto o del proceso.

Conciso: Un requerimiento es conciso si es fcil de leer y entender. Su redaccin debe ser simple y clara para aquellos que vayan a consultarlo en un futuro. Completo: Un requerimiento est completo si no necesita ampliar detalles en su redaccin, es decir, si se proporciona la informacin suficiente para su comprensin. Consistente: Un requerimiento es consistente si no es contradictorio con otro requerimiento.

No ambiguo: Un requerimiento no es ambiguo cuando tiene una sola interpretacin. El lenguaje usado en su definicin, no debe causar confusiones al lector.

Verificable: Un requerimiento es verificable cuando puede ser cuantificado de manera que permita hacer uso de los siguientes mtodos de verificacin: inspeccin, anlisis, demostracin o pruebas(http://es.kioskea.net/contents/genie-logiciel/genie-logiciel.php3).

2.1.5 UML Es un lenguaje de modelado visual que se usa para especificar, visualizar, construir y documentar artefactos de un sistema de software. Se usa para entender, disear, configurar, mantener y controlar la informacin s los sistemas a construir. UML capta la informacin sobre la estructura esttica y el comportamiento dinmico de un sistema. El lenguaje de modelado pretende unificar la experiencia pasada sobre tcnicas de modelado e incorporar las mejores prcticas actuales en un acercamiento estndar. Es un lenguaje de propsito general para el modelado orientado a objetos. UML es tambin un lenguaje de modelado visual que permite una abstraccin del sistema y sus componentes.

Fig. 5 Lenguaje UML El lenguaje de modelado es la notacin (principalmente grfica) que usan los mtodos para La estandarizacin de un lenguaje de modelado es invaluable, ya que es la parte principal del proceso de comunicacin que requieren todos los agentes involucrados en un proyecto informtico. Si se quiere discutir un diseo con alguien ms, ambos deben conocer el lenguaje de modelado y no as el proceso que se sigui para obtenerlo. La notacin es la parte grfica que se ve en los modelos y representa la sintaxis del lenguaje de modelado. Por ejemplo, la notacin del diagrama de clases define como se representan los

10

elementos y conceptos como son: una clase, una asociacin y una multiplicidad. Y qu significa exactamente una asociacin o multiplicidad en una clase. Un metamodelo es la manera de definir esto (un diagrama, usualmente de clases, que define la notacin). Para que un proveedor diga que cumple con UML debe cubrir con la semntica y con la notacin. Una herramienta de UML debe mantener la consistencia entre los diagramas en un mismo modelo. Bajo esta definicin una herramienta que solo dibuje, no puede cumplir con la notacin de UML. El lenguaje est dotado de mltiples herramientas para lograr la especificacin determinante del modelo, pero en nuestro caso se trabaja en forma simplificada sobre: Modelamiento de Clases Casos de Uso Diagrama de Interaccin

Los esquemas principales de los diagramas UML representan los siguientes puntos:

Los diagramas de clases de UML forman la vista lgica. Los diagramas de interaccin de UML constituyen la vista de proceso. La vista de desarrollo captura el software en su entorno de desarrollo. Los diagramas de despliegue integran la vista fsica . Los escenarios: el modelo de casos de uso.

Relaciones entre Clases: Agregacin: Para modelar objetos complejos, n bastan los tipos de datos bsicos que proveen los lenguajes: enteros, reales y secuencias de caracteres. Cuando se requiere componer objetos que son instancias de clases definidas por el desarrollador de la aplicacin, tenemos dos posibilidades:

Por Valor: Es un tipo de relacin esttica, en donde el tiempo de vida del objeto incluido est condicionado por el tiempo de vida del que lo incluye. Este tipo de relacin es comnmente llamada Composicin (el Objeto base se construye a partir del objeto incluido, es decir, es "parte/todo").

Por Referencia: Es un tipo de relacin dinmica, en donde el tiempo de vida del objeto incluido es independiente del que lo incluye. Este tipo de relacin es comnmente llamada Agregacin (el objeto base utiliza al incluido para su funcionamiento).

Asociacin: La relacin entre clases conocida como Asociacin, permite asociar objetos que colaboran entre si. Cabe destacar que no es una relacin fuerte, es decir, el tiempo de vida de un objeto no depende del otro.

11

2.1.6 Programacin Orientada a Objetos Conceptos de programacin orientada a objetos Herencia

La herencia es uno de los conceptos ms cruciales en la POO. La herencia bsicamente consiste en que una clase puede heredar sus variables y mtodos a varias subclases (la clase que hereda es llamada superclase o clase padre). Esto significa que una subclase, aparte de los atributos y mtodos propios, tiene incorporados los atributos y mtodos heredados de la superclase. De esta manera se crea una jerarqua de herencia. Abstraccin

Denota las caractersticas esenciales de un objeto, donde se capturan sus comportamientos. Cada objeto en el sistema sirve como modelo de un "agente" abstracto que puede realizar trabajo, informar y cambiar su estado, y "comunicarse" con otros objetos en el sistema sin revelar cmo se implementan estas caractersticas. Los procesos, las funciones o los mtodos pueden tambin ser abstrados y cuando lo estn, una variedad de tcnicas son requeridas para ampliar una abstraccin. El proceso de abstraccin permite seleccionar las caractersticas relevantes dentro de un conjunto e identificar comportamientos comunes para definir nuevos tipos de entidades en el mundo real. La abstraccin es clave en el proceso de anlisis y diseo orientado a objetos, ya que mediante ella podemos llegar a armar un conjunto de clases que permitan modelar la realidad o el problema que se quiere atacar. Encapsulamiento

Significa reunir a todos los elementos que pueden considerarse pertenecientes a una misma entidad, al mismo nivel de abstraccin. Esto permite aumentar la cohesin de los componentes del sistema. Algunos autores confunden este concepto con el principio de ocultacin, principalmente porque se suelen emplear conjuntamente. Modularidad

Se denomina Modularidad a la propiedad que permite subdividir una aplicacin en partes ms pequeas (llamadas mdulos), cada una de las cuales debe ser tan independiente como sea posible de la aplicacin en s y de las restantes partes. Estos mdulos se pueden compilar por separado, pero tienen conexiones con otros mdulos. Al igual que la encapsulacin, los lenguajes soportan la Modularidad de diversas formas. Herencia

Las clases no estn aisladas, sino que se relacionan entre s, formando una jerarqua de clasificacin. Los objetos heredan las propiedades y el comportamiento de todas las clases a las que pertenecen. La herencia organiza y facilita el polimorfismo y el encapsulamiento permitiendo a los objetos ser definidos y creados como tipos especializados de objetos preexistentes. Estos

12

pueden compartir (y extender) su comportamiento sin tener que volver a implementarlo. Esto suele hacerse habitualmente agrupando los objetos en clases y estas en rboles o enrejados que reflejan un comportamiento comn. Cuando un objeto hereda de ms de una clase se dice que hay herencia mltiple. Polimorfismo

Este es uno de los conceptos esenciales de una programacin orientada a objetos. As como la herencia est relacionada con las clases y su jerarqua, el polimorfismo se relaciona con los mtodos (http://es.wikipedia.org/wiki/Programaci%C3%B3n_orientada_a_objetos).

2.2 Sistema Manejador de Base de Datos El propsito general de los sistemas de gestin de bases de datos es el de manejar de manera clara, sencilla y ordenada un conjunto de datos que posteriormente se convertirn en informacin relevante para una organizacin. Objetivos Existen distintos objetivos que deben cumplir los SGBD:

Abstraccin de la informacin.

Los SGBD ahorran a los usuarios detalles acerca del almacenamiento fsico de los datos. Da lo mismo si una base de datos ocupa uno o cientos de archivos, este hecho se hace transparente al usuario. As, se definen varios niveles de abstraccin.

Independencia.

La independencia de los datos consiste en la capacidad de modificar el esquema (fsico o lgico) de una base de datos sin tener que realizar cambios en las aplicaciones que se sirven de ella.

Consistencia.

En aquellos casos en los que no se ha logrado eliminar la redundancia, ser necesario vigilar que aquella informacin que aparece repetida se actualice de forma coherente, es decir, que todos los datos repetidos se actualicen de forma simultnea. Por otra parte, la base de datos representa una realidad determinada que tiene determinadas condiciones, por ejemplo que los menores de edad no pueden tener licencia de conducir. El sistema no debera aceptar datos de un conductor menor de edad. En los SGBD existen herramientas que facilitan la programacin de este tipo de condiciones.

Seguridad.

La informacin almacenada en una base de datos puede llegar a tener un gran valor. Los SGBD deben garantizar que esta informacin se encuentra segura de permisos a usuarios y grupos de usuarios, que permiten otorgar diversas categoras de permisos.

13

Manejo de transacciones.

Una transaccin es un programa que se ejecuta como una sola operacin. Esto quiere decir que luego de una ejecucin en la que se produce una falla es el mismo que se obtendra si el programa no se hubiera ejecutado. Los SGBD proveen mecanismos para programar las modificaciones de los datos de una forma mucho ms simple que si no se dispusiera de ellos (http://www.mastermagazine.info/termino/4544.php).

Fig. 6 Sistema Manejador de Base de Datos 2.2.1 Diseo de interaccin con Base de Datos Proveen facilidades para la manipulacin de grandes volmenes de datos (ver objetivos). Entre stas: Simplifican la programacin de equipos de consistencia. Manejando las polticas de respaldo adecuadas, garantizan que los cambios de la base sern siempre consistentes sin importar si hay errores correctamente, etc. Organizan los datos con un impacto mnimo en el cdigo de los programas. Disminuyen drsticamente los tiempos de desarrollo y aumentan la calidad del sistema desarrollado si son bien explotados por los desarrolladores.

Usualmente, proveen interfaces y lenguajes de consulta que simplifican la recuperacin de los datos (http://office.microsoft.com/es-hn/access-help/interacciones-entre-los-diagramasde-base-de-datos-las-ventanas-de-diseno-de-tabla-y-la-base-de-datos-adpHP003083899.aspx).

2.3 Modelos A continuacin se describirn los modelos que sigue la construccin o desarrollo de software

14

2.3.1 Modelo Cascada Este es el ms bsico de todos los modelos, y sirve como bloque de construccin para los dems modelos de ciclo de vida. La visin del modelo cascada del desarrollo de software es muy simple; dice que el desarrollo de software puede ser a travs de una secuencia simple de fases. Cada fase tiene un conjunto de metas bien definidas, y las actividades dentro de una fase contribuye a la satisfaccin de metas de esa fase o quizs a una subsecuencia de metas de la fase. Las flechas muestran el flujo de informacin entre las fases. La flecha de avance muestra el flujo normal. Las flechas hacia atrs representan la retroalimentacin. El modelo de ciclo de vida cascada, captura algunos principios bsicos: Planear un proyecto antes de embarcarse en l. Definir el comportamiento externo deseado del sistema antes de disear su arquitectura interna. Documentar los resultados de cada actividad. Disear un sistema antes de codificarlo. Testear un sistema despus de construirlo.

Esta es una representacin grfica del modelo de cascada.

Fig. 7 Modelo Cascada Una de las contribuciones ms importantes del modelo cascada es para los administradores, posibilitndoles avanzar en el desarrollo, aunque en una escala muy bruta. 2.3.2 Modelo De Desarrollo Incremental Los riesgos asociados con el desarrollo de sistemas largos y complejos son enormes. Una forma de reducir los riesgos es construir slo una parte del sistema, reservando otros aspectos para niveles posteriores. El desarrollo incremental es el proceso de construccin siempre incrementando subconjuntos de requerimientos del sistema. Tpicamente, un documento de requerimientos es escrito al capturar todos los requerimientos para el sistema completo. El modelo de desarrollo incremental provee algunos beneficios significativos para los proyectos:

15

Construir un sistema pequeo es siempre menos riesgoso que construir un sistema grande.

Al ir desarrollando parte de las funcionalidades, es ms fcil determinar si los requerimientos planeados para los niveles subsiguientes son correctos.

Si un error importante es realizado, slo la ltima iteracin necesita ser descartada. Reduciendo el tiempo de desarrollo de un sistema (en este caso en incremento del sistema) decrecen las probabilidades que esos requerimientos de usuarios puedan cambiar durante el desarrollo.

Si un error importante es realizado, el incremento previo puede ser usado. Los errores de desarrollo realizados en un incremento, pueden ser arreglados antes del comienzo del prximo incremento.

Esta es una representacin grfica del modelo de desarrollo integral.

Fig. 8 Modelo de Desarrollo integral 2.3.3 Modelo De Desarrollo Evolutivo Como el modelo de desarrollo incremental, el modelo de desarrollo evolutivo (algunas veces denominado como prototipo evolutivo) construye una serie de grandes versiones sucesivas de un producto. Sin embargo, mientras que la aproximacin incremental presupone que el conjunto completo de requerimientos es conocido al comenzar, el modelo evolutivo asume que los requerimientos no son completamente conocidos al inicio del proyecto. En el modelo evolutivo, los requerimientos son cuidadosamente examinados, y slo esos que son bien comprendidos son seleccionados para el primer incremento. Los desarrolladores construyen una implementacin parcial del sistema que recibe slo estos requerimientos. El sistema es entonces desarrollado, los usuarios lo usan, y proveen retroalimentacin a los desarrolladores. Basada en esta retroalimentacin, la especificacin de requerimientos es

16

actualizada, y una segunda versin del producto es desarrollada y desplegada. El proceso se repite indefinidamente. Todo lo que uno tiene que hacer es construir un subconjunto de requerimientos conocidos (incremental), y comprender al principio que muchos nuevos requerimientos es probable que aparezcan cuando el sistema sea desplegado o desarrollado. El desarrollo de software en forma evolutiva requiere un especial cuidado en la manipulacin de documentos, programas, datos de test, etc. desarrollados para distintas versiones del software. Cada paso debe ser registrado, la documentacin debe ser recuperada con facilidad, los cambios deben ser efectuados de una manera controlada. Esta es una representacin grfica del modelo de desarrollo evolutivo.

Fig. 9 Modelo de Desarrollo Evolutivo 2.3.4 Modelo de Prototipo de Requerimientos El prototipo de requerimientos es la creacin de una implementacin parcial de un sistema, para el propsito explcito de aprender sobre los requerimientos del sistema. Un prototipo es construido de una manera rpida tal como sea posible. Esto es dado a los usuarios, clientes o representantes de ellos, posibilitando que ellos experimenten con el prototipo. Estos individuos luego proveen la retroalimentacin sobre lo que a ellos les gust y no les gust acerca del prototipo proporcionado, quienes capturan en la documentacin actual de la especificacin de requerimientos la informacin entregada por los usuarios para el desarrollo del sistema real. El prototipado puede ser usado como parte de la fase de requerimientos (determinar requerimientos) o justo antes de la fase de requerimientos (como predecesor de requerimientos). En otro caso, el prototipado puede servir su papel inmediatamente antes de algn o todo el desarrollo incremental en modelos incremental o evolutivo. Esta es una representacin grfica del modelo de prototipo de requerimientos.

17

Fig. 10 Modelo de prototipo de requerimientos 2.3.5 Modelo Concurrente Como el modelo espiral, el modelo concurrente provee una meta-descripcin del proceso software. Mientras que la contribucin primaria del modelo espiral es en realidad que esas actividades del software ocurran repetidamente, la contribucin del modelo concurrente es su capacidad de describir las mltiples actividades del software ocurriendo simultneamente. Los requerimientos son usualmente "lneas de base", cuando una mayora de los requerimientos comienzan a ser bien entendidos, en este tiempo se dedica un esfuerzo considerable al diseo. Sin embargo, una vez que comienza el diseo, cambios a los requerimientos son comunes y frecuentes (http://www.mitecnologico.com/Main/ElModeloDesarrolloConcurrente). Esta es una representacin grfica del modelo concurrente.

Fig. 11 Modelo Concurrente 2.4 Herramientas para el diseo de sistemas

18

Como sabemos un lenguaje de programacin es un idioma artificial diseado para expresar computaciones que pueden ser llevadas a cabo por mquinas como las computadoras. Pueden usarse para crear programas que controlen el comportamiento fsico y lgico de una mquina, para expresar algoritmos con precisin, o como modo de comunicacin humana. [] Est formado por un conjunto de smbolos y reglas sintcticas y semnticas que definen su estructura y el significado de sus elementos y expresiones. Al proceso por el cual se escribe, se prueba, se depura, se compila y se mantiene el cdigo fuente de un programa informtico se le llama programacin. Tambin la palabra programacin se define como el proceso de creacin de un programa de computadora, mediante la aplicacin de procedimientos lgicos, a travs de los siguientes pasos: El desarrollo lgico del programa para resolver un problema en particular. Escritura de la lgica del programa empleando un lenguaje de programacin especfico (codificacin del programa). Ensamblaje o compilacin del programa hasta convertirlo en lenguaje de mquina. Prueba y depuracin del programa. Desarrollo de la documentacin.

Siendo el lenguaje de programacin un parte aguas para la tecnologa, es nuestra base esencial para el desarrollo de nuestro sistema. 2.5 Herramientas para el desarrollo de sistemas A continuacin se describirn las herramientas que se ocupan en el transcurso del diseo y desarrollo de nuestro proyecto. 2.5.1 Java Es un lenguaje de programacin orientado a objetos, desarrollado por Sun Microsystems a principios de los aos 90. El lenguaje en s mismo toma mucha de su sintaxis de C y C++, pero tiene un modelo de objetos ms simple y elimina herramientas de bajo nivel, que suelen inducir a muchos errores, como la manipulacin directa de punteros o memoria. Las aplicaciones Java estn tpicamente compiladas en un bytecode, aunque la compilacin en cdigo mquina nativo tambin es posible. En el tiempo de ejecucin, el bytecode es normalmente interpretado o compilado a cdigo nativo para la ejecucin, aunque la ejecucin directa por hardware del bytecode por un procesador Java tambin es posible. La implementacin original y de referencia del compilador, la mquina virtual y las bibliotecas de clases de Java fueron desarrollados por Sun Microsystems en 1995. Desde entonces, Sun ha controlado las especificaciones, el desarrollo y evolucin del lenguaje a travs del Java Community Process, si bien otros han desarrollado tambin implementaciones alternativas de estas tecnologas de Sun, algunas incluso bajo licencias de software libre.

19

Fig. 12 Logo de Java El lenguaje Java se cre con cinco objetivos principales: 1. Debera usar la metodologa de la programacin orientada a objetos. 2. Debera permitir la ejecucin de un mismo programa en mltiples sistemas operativos. 3. Debera incluir por defecto soporte para trabajo en red. 4. Debera disearse para ejecutar cdigo en sistemas remotos de forma segura. 5. Debera ser fcil de usar y tomar lo mejor de otros lenguajes orientados a objetos, como C++. Independencia de la plataforma La segunda caracterstica, la independencia de la plataforma, significa que programas escritos en el lenguaje Java pueden ejecutarse igualmente en cualquier tipo de hardware. Este es el significado de ser capaz de escribir un programa una vez y que pueda ejecutarse en cualquier dispositivo, tal como reza el axioma de Java, write once, run anywhere. Para ello, se compila el cdigo fuente escrito en lenguaje Java, para generar un cdigo conocido como bytecode (especficamente Java bytecode)instrucciones mquina simplificadas especficas de la plataforma Java. Esta pieza est a medio camino entre el cdigo fuente y el cdigo mquina que entiende el dispositivo destino. El bytecode es ejecutado entonces en la mquina virtual (JVM), un programa escrito en cdigo nativo de la plataforma destino (que es el que entiende su hardware), que interpreta y ejecuta el cdigo. Adems, se suministran bibliotecas adicionales para acceder a las caractersticas de cada dispositivo (como los grficos, ejecucin mediante hebras o threads, la interfaz de red) de forma unificada. Se debe tener presente que, aunque hay una etapa explcita de compilacin, el bytecode generado es interpretado o convertido a instrucciones mquina del cdigo nativo por el compilador JIT (Just In Time). El concepto de independencia de la plataforma de Java cuenta, sin embargo, con un gran xito en las aplicaciones en el entorno del servidor, como los Servicios Web, los Servlets, los Java Beans, as como en sistemas empotrados basados en OSGi, usando entornos Java empotrados.

20

El recolector de basura En Java el problema de las fugas de memoria se evita en gran medida gracias a la recoleccin de basura (o automatic garbage collector). El programador determina cundo se crean los objetos y el entorno en tiempo de ejecucin de Java (Java runtime) es el responsable de gestionar el ciclo de vida de los objetos. El programa, u otros objetos pueden tener localizado un objeto mediante una referencia a ste. Cuando no quedan referencias a un objeto, el recolector de basura de Java borra el objeto, liberando as la memoria que ocupaba previniendo posibles fugas (ejemplo: un objeto creado y nicamente usado dentro de un mtodo slo tiene entidad dentro de ste; al salir del mtodo el objeto es eliminado). Aun as, es posible que se produzcan fugas de memoria si el cdigo almacena referencias a objetos que ya no son necesarioses decir, pueden an ocurrir, pero en un nivel conceptual superior. En definitiva, el recolector de basura de Java permite una fcil creacin y eliminacin de objetos, mayor seguridad y puede que ms rpida que en C++. Entornos de funcionamiento El diseo de Java, su robustez, el respaldo de la industria y su fcil portabilidad han hecho de Java uno de los lenguajes con un mayor crecimiento y amplitud de uso en distintos mbitos de la industria de la informtica. En dispositivos mviles y sistemas empotrados Desde la creacin de la especificacin J2ME (Java 2 Platform, Micro Edition), una versin del entorno de ejecucin Java reducido y altamente optimizado, especialmente desarrollado para el mercado de dispositivos electrnicos de consumo se ha producido toda una revolucin en lo que a la extensin de Java se refiere. Es posible encontrar microprocesadores diseados para ejecutar bytecode Java y software Java para tarjetas inteligentes (JavaCard), telfonos mviles, buscapersonas, set-top-boxes, sintonizadores de TV y otros pequeos electrodomsticos. El modelo de desarrollo de estas aplicaciones es muy semejante a las applets de los navegadores salvo que en este caso se denominan MIDlets. En el navegador web Desde la primera versin de java existe la posibilidad de desarrollar pequeas aplicaciones (Applets) en Java que luego pueden ser incrustadas en una pgina HTML para que sean descargadas y ejecutadas por el navegador web. Estas mini-aplicaciones se ejecutan en una JVM que el navegador tiene configurada como extensin (plug-in) en un contexto de seguridad restringido configurable para impedir la ejecucin local de cdigo potencialmente malicioso. El xito de este tipo de aplicaciones (la visin del equipo de Gosling) no fue realmente el esperado debido a diversos factores, siendo quizs el ms importante la lentitud y el reducido ancho de banda de las comunicaciones en aquel entonces que limitaba el tamao de las applets que se

21

incrustaban en el navegador. La aparicin posterior de otras alternativas (aplicaciones web dinmicas de servidor) dej un reducido mbito de uso para esta tecnologa, quedando hoy relegada fundamentalmente a componentes especficos para la intermediacin desde una aplicacin web dinmica de servidor con dispositivos ubicados en la mquina cliente donde se ejecuta el navegador. Las applets Java no son las nicas tecnologas (aunque s las primeras) de componentes complejos incrustados en el navegador. Otras tecnologas similares pueden ser: ActiveX de Microsoft, Flash, Java Web Start, etc. En sistemas de servidor En la parte del servidor, Java es ms popular que nunca, desde la aparicin de la especificacin de Servlets y JSP (Java Server Pages). Hasta entonces, las aplicaciones web dinmicas de servidor que existan se basaban fundamentalmente en componentes CGI y lenguajes interpretados. Ambos tenan diversos inconvenientes (fundamentalmente lentitud, elevada carga computacional o de memoria y propensin a errores por su interpretacin dinmica). Los servlets y las JSPs supusieron un importante avance ya que: El API de programacin es muy sencilla, flexible y extensible. Los servlets no son procesos independientes (como los CGIs) y por tanto se ejecutan dentro del mismo proceso que la JVM mejorando notablemente el rendimiento y reduciendo la carga computacional y de memoria requeridas.

Las JSPs son pginas que se compilan dinmicamente (o se pre-compilan previamente a su distribucin) de modo que el cdigo que se consigue una ventaja en rendimiento substancial frente a muchos lenguajes interpretados.

La especificacin de Servlets y JSPs define un API de programacin y los requisitos para un contenedor (servidor) dentro del cual se puedan desplegar estos componentes para formar aplicaciones web dinmicas completas. Hoy da existen multitud de contenedores (libres y comerciales) compatibles con estas especificaciones. A partir de su expansin entre la comunidad de desarrolladores, estas tecnologas han dado paso a modelos de desarrollo mucho ms elaborados con frameworks (pe Struts, Webwork) que se sobreponen sobre los servlets y las JSPs para conseguir un entorno de trabajo mucho ms poderoso y segmentado en el que la especializacin de roles sea posible (desarrolladores, diseadores grficos, ...) y se facilite la reutilizacin y robustez de cdigo. A pesar de todo ello, las tecnologas que subyacen (Servlets y JSPs) son substancialmente las mismas. Este modelo de trabajo se ha convertido en uno de los estndar de-facto para el desarrollo de aplicaciones web dinmicas de servidor.

22

En aplicaciones de escritorio Hoy en da existen multitud de aplicaciones grficas de usuario basadas en Java. El entorno de ejecucin Java (JRE) se ha convertido en un componente habitual en los PC de usuario de los sistemas operativos ms usados en el mundo. Adems, muchas aplicaciones Java lo incluyen dentro del propio paquete de la aplicacin de modo que se ejecuten en cualquier PC. En las primeras versiones de la plataforma Java existan importantes limitaciones en las APIs de desarrollo grfico (AWT). Desde la aparicin de la biblioteca Swing la situacin mejor substancialmente y posteriormente con la aparicin de bibliotecas como SWT hacen que el desarrollo de aplicaciones de escritorio complejas y con gran dinamismo, usabilidad, etc. sea relativamente sencillo. Plataformas soportadas Una versin del entorno de ejecucin Java JRE (Java Runtime Environment) est disponible en la mayora de equipos de escritorio. Sin embargo, Microsoft no lo ha incluido por defecto en sus sistemas operativos. En el caso de Apple, ste incluye una versin propia del JRE en su sistema operativo, el Mac OS. Tambin es un producto que por defecto aparece en la mayora de las distribuciones de GNU/Linux. Debido a incompatibilidades entre distintas versiones del JRE, muchas aplicaciones prefieren instalar su propia copia del JRE antes que confiar su suerte a la aplicacin instalada por defecto. Los desarrolladores de applets de Java o bien deben insistir a los usuarios en la actualizacin del JRE, o bien desarrollar bajo una versin antigua de Java y verificar el correcto funcionamiento en las versiones posteriores. Programacin Expresiones Las expresiones son un conjunto de elementos o tokens junto con literales que son evaluados para devolver un resultado. Los tokens son elemento ms pequeo de un programa que es significativo, e interpretado o entendido por el compilador, en java los tokens se dividen en cinco categoras que son: Identificadores: Son las representaciones que se les da a los nombres que se asignan a las variables, clases, paquetes, mtodos y constantes en el cdigo de java para que el compilador los identifique y el programador pueda entenderlos. En java los identificadores pueden diferenciar entre maysculas o minsculas por ser case sensitive, por lo que la variable cuyo nombre sea Mivariable, no es igual a mivarialble, ya que java identifica estas como variables diferentes por el case sensitive, tambin se puede utilizar nmeros, o el signo _ para asignar un identificador. Palabras claves: Son los identificadores reservados por java para cumplir con un objetivo especfico en el cdigo y el compilador, se usan de forma limitada y en casos especficos. Las palabras claves que usa java son las siguientes:

23

Abstract

Boolean Break

Byte

Case

Catch

Char

Class

Continue

Default

Do

Doubl

Else

Extends

False

Final

Finally

Float

For

If

implements Import

instanceof Int

interface

Long

Native

New

Null

package

Private

protected Public

Return

Short

Staric

Super

Switch

syncroniced This

Throw

Throws

Transient True

Try

Void

Volatile

While

Var

Rest

Byvalue

Cast

Const

Future

Generic

Goto

Inner

Operator

Outer

Tabla 1 Palabras reservadas de Java Literales y constantes: Los literales son sintaxis para asignar valores a una variable, es decir el valor que puede tomar una variable, tambin es un valor constante que puede ser de tipo numrico. Las constantes son variables que tienen un valor fijo y no puede ser modificado en el trascurso de la ejecucin del cdigo, estas se declaran por medio de los modificadores final y static. Operadores: Son los que nos indican una evaluacin que se aplica a un objeto o un dato, sobre un identificador o constante. Un ejemplo de operadores puede ser la suma, resta o multiplicacin.

24

Separadores: Se utilizan para indicarle al compilador de java donde se ubican los elementos del cdigo, los separadores que admite java son: { } , : ; Tambin el compilador de java identifica y elimina los comentarios, retornos de carros espacios vacos y de tabulacin a la hora de compilar por lo que no son considerados parte de un tokens. Las expresiones pueden ser una combinacin en secuencia de variables, operadores y mtodos. Las expresiones son utilizadas para realizar clculos, para asignar valores a variables, o para controlar la ejecucin del flujo del programa. Operadores Los operadores son aquellos que tras realizar una operacin devuelven un resultado, estos se puede caracterizar por el nmero de operadores, el tipo de operandos, y el resultado que generan. Numero de operandos. Pueden ser de dos tipos unarios, y binarios. Los unarios son aquellos que solo necesitan de un operando para devolver un valor, mientras que los binarios necesitan de dos o ms operandos (http://www.java.com/es/download/index.jsp). Operadores unarios.

Operador Descripcin

Cambio de signo

Operador NOT

Complemento a 1

Tabla 2 Operadores Unarios de Java Operadores binarios.

Operadores

Descripcin

+-*/%

Operadores aritmticos

== != < > <= >=

Operadores relacionales

25

&& || ^

Operadores booleanos

^ << >> >>>

Operadores a nivel de bit

Concatenacin de cadenas Tabla 3 Operadores Binarios de Java

En la actualidad java es el lenguaje ms importante en la actualidad, por lo cual permite crear aplicaciones en diferentes plataformas (http://definicion.de/java/). 2.5.2 Google Web Toolkit GWT o Google Web Toolkit es un framework creado por Google que permite ocultar la complejidad de varios aspectos de la tecnologa AJAX. Es compatible con varios navegadores, lo cual es notorio ya que cada navegador suele necesitar cdigo especfico para lograr un front-end correcto en una aplicacin web. El concepto de Google Web Toolkit es bastante sencillo, bsicamente lo que se debe hacer es crear el cdigo en Java usando cualquier entorno de desarrollo (IDE) de Java y el compilador lo traducir a HTML y JavaScript.

Fig. 13 Google Web Toolkit Con la biblioteca GWT, los desarrolladores pueden crear y depurar aplicaciones AJAX en lenguaje JAVA usando el entorno de desarrollo que prefieran. Cuando una aplicacin es desplegada, el compilador GWT traduce la aplicacin Java a un archivo Javascript, que puede ser ofuscado para optimizar el rendimiento. GWT no es slo una interfaz de programacin; proporciona un conjunto de herramientas que permiten desarrollar funcionalidades Javascript de alto rendimiento en el navegador del cliente. Una aplicacin GWT puede ser ejecutada en dos modos:

Modo host (Hosted mode): La aplicacin se ejecuta como cdigo bytecode de Java dentro de la Mquina Virtual de Java (JVM). Este modo es el ms usado para desarrollo, soportando el cambio de cdigo en caliente y el depurado.

26

Modo web (Web mode): La aplicacin se ejecuta como cdigo Javascript y HTML puro, compilado a partir del cdigo Java. Este modo se suele usar para el despliegue de la aplicacin.

La utilidad de lnea de comandos applicationCreator genera automticamente todos los archivos necesarios para iniciar un proyecto GWT, incluso permite crear un proyecto para Eclipse. Existen varios plugins de cdigo abierto para ayudar a desarrollar en diferentes entornos de desarrollo, como GWT4NB para NetBeans, Cypal Studio for GWT para Eclipse o gwtDeveloper para JDeveloper. Arquitectura GWT GWT contiene los siguientes componentes:[]

GWT Java-to-JavaScript Compiler: la funcin de este componente es traducir el cdigo desarrollado en Java al lenguaje JavaScript. Lo empleamos cuando usamos al GWT en modo web.

Hosted Web Browser: este componente ejecuta la aplicacin Java sin traducirla a JavaScript, en modo host usando la mquina virtual de Java. JRE Emulation Library: contiene las bibliotecas ms importantes de las clases de Java: java.lang en donde se encuentran las clases fundamentales para poder programar en Java y un subconjunto de las clases del paquete java.util. Java.lang incluye, entre otras, la clase java.lang.object que es la clase fundamental de la que heredan o extienden todas las clases en Java. El resto de los paquetes no estn soportados por GWT.

GWT Web UI Class Library: contiene un conjunto de elementos de interfaz de usuario que permite la creacin de objetos tales como textos, cajas de texto, imgenes y botones.

Caractersticas Componentes grficos dinmicos y reusables: los programadores pueden usar clases prediseadas para implementar comportamientos que de otra manera consumiran mucho tiempo, como arrastrar y soltar o mens en rbol. Simple mecanismo RPC. Gestin del historial del navegador web. Soporte para depurado de Java. Control de diferentes caractersticas del navegador. Integracin con JUnit. Internacionalizacin. Los desarrolladores pueden mezclar cdigo escrito en Javascript dentro del cdigo Java usando la Interfaz Nativa Javascript (JSNI).

27

Soporte para las APIs de Google (inicialmente, soporte para Google Gears). Es de cdigo abierto. Los desarrolladores pueden disear y desarrollar sus aplicaciones orientadas a objetos. Errores comunes en Javascript, como la discrepancia de tipos de datos, son controlados en tiempo de compilacin.

El cdigo Javascript generado puede ser ofuscado para optimizar el rendimiento. Existen un numeroso conjunto de bibliotecas desarrolladas por Google y terceros que amplan las funcionalidades de GWT (http://code.google.com/intl/esMX/webtoolkit/doc/latest/tutorial/).

2.5.3 Hibernate Es una herramienta de Mapeo objeto-relacional (ORM) para la plataforma Java (y disponible tambin para .Net con el nombre de NHibernate) que facilita el mapeo de atributos entre una base de datos relacional tradicional y el modelo de objetos de una aplicacin, mediante archivos declarativos (XML) o anotaciones en los beans de las entidades que permiten establecer estas relaciones. Como todas las herramientas de su tipo, Hibernate busca solucionar el problema de la diferencia entre los dos modelos de datos coexistentes en una aplicacin: el usado en la memoria de la computadora (orientacin a objetos) y el usado en las bases de datos (modelo relacional). Para lograr esto permite al desarrollador detallar cmo es su modelo de datos, qu relaciones existen y qu forma tienen. Con esta informacin Hibernate le permite a la aplicacin manipular los datos de la base operando sobre objetos, con todas las caractersticas de la POO. Hibernate convertir los datos entre los tipos utilizados por Java y los definidos por SQL. Hibernate genera las sentencias SQL y libera al desarrollador del manejo manual de los datos que resultan de la ejecucin de dichas sentencias, manteniendo la portabilidad entre todos los motores de bases de datos con un ligero incremento en el tiempo de ejecucin. Hibernate est diseado para ser flexible en cuanto al esquema de tablas utilizado, para poder adaptarse a su uso sobre una base de datos ya existente. Tambin tiene la funcionalidad de crear la base de datos a partir de la informacin disponible. Hibernate ofrece tambin un lenguaje de consulta de datos llamado HQL (Hibernate Query Language), al mismo tiempo que una API para construir las consultas programticamente (conocida como "criteria"). Hibernate para Java puede ser utilizado en aplicaciones Java independientes o en aplicaciones Java EE, mediante el componente Hibernate Annotations que implementa el estndar JPA, que es parte de esta plataforma.

28

Fig. 14 Ejemplo de Hibernate [ edit ] Software componentsLos componentes de software The Hibernate software includes the following components: siguientes componentes:
[3]

El software de Hibernate incluye los

Hibernate Core the base software for an object-relational mapping solution for Java environments
[ 4 ]

Hibernate Core - el software de base para una solucin de mapeo objeto-

relacional para entornos Java

Hibernate Annotations metadata that governs the transformation of data between the objectoriented model and the relational database model according to the JSR 317 Java Persistence API (JPA 2) [ 5 ] Hibernate Anotaciones - metadatos que rige la transformacin de datos entre el modelo orientado a objetos y el modelo de base de datos relacional de acuerdo con el JSR 317 Java Persistence API (JPA 2)

Hibernate EntityManager together with Hibernate Annotations, a wrapper that implements a JSR 317 Java Persistence API (JPA 2) persistence solution on top of Hibernate Core
[ 6 ]

Hibernate EntityManager - junto con Hibernate Annotations, un contenedor que implementa un JSR 317 Java Persistence API (JPA 2) solucin de persistencia en la parte superior de Hibernate ncleo

Hibernate Envers auditing and versioning of persistent classes auditora y control de versiones de las clases persistentes

[ 7 ]

Hibernate Envers -

Hibernate OGM Object/Grid Mapper is an extension to store data in a NoSQL store de NoSQL

[ 8 ]

Hibernate OGM - Objeto / Mapper Grid es una extensin para almacenar datos en una tienda

Hibernate Shards horizontal partitioning for multiple relational databases [ 9 ] Hibernate Shards - particionamiento horizontal de mltiples bases de datos relacionales Hibernate Search integrates the full text library functionality from Apache Lucene in the Hibernate and JPA model
[ 10 ]

Hibernate Search - integra la funcionalidad de texto completo de

la biblioteca de Apache Lucene en la hibernacin y el modelo de APP

29

Hibernate Tools a set of tools implemented as a suite of Eclipse plugins and Ant tasks included in JBoss Developer Studio Developer Studio
[ 11 ]

Hibernate Tools - un conjunto de herramientas

implementadas como un conjunto de Eclipse plugins y Ant las tareas incluidas en JBoss

Hibernate Validator the reference implementation of JSR 303 Bean Validation Validator - la implementacin de referencia de JSR 303 Validacin de Bean

[ 12 ]

Hibernate

Hibernate Metamodel Generator an annotation processor that creates JSR 317 Java Persistence API (JPA 2) static metamodel classes using the JSR 269 Pluggable Annotation Processing API
[ 13 ]

Hibernate Metamodelo Generador - un procesador de anotacin que

genera JSR 317 Java Persistence API (JPA 2) las clases estticas metamodelo utilizando el JSR 269 conectable anotacin API de procesamiento

NHibernate an object-relational mapping solution for the .NET Framework una solucin de mapeo objeto-relacional para el (http://en.wikipedia.org/wiki/Hibernate_(Java)).

[ 14 ]

NHibernate Framework

NET

2.5.4 Java Wireless Toolkit El Sun Java Wireless Toolkit (WTK, anteriormente conocida como Java 2 Plataforma, Micro Edition (JavaME) Wireless Toolkit) es una caja de herramientas del estado de la tcnica para el desarrollo de aplicaciones inalmbricas que se basan en Conectado JavaME la Configuracin Limitada de Dispositivos ( CLDC ) y Perfil de dispositivos mviles de la informacin ( MIDP ), y diseado para funcionar en telfonos celulares, los principales asistentes digitales personales y otros dispositivos mviles pequeos. The toolkit includes the emulation environments, performance optimization and tuning features, documentation, and examples that developers need to bring efficient and successful wireless applications to market quickly El kit de herramientas incluye el entorno de emulacin, la optimizacin del rendimiento y las caractersticas de ajuste, la documentacin y ejemplos que los desarrolladores necesitan para llevar las aplicaciones inalmbricas eficientes y exitosos en el mercado rpidamente The J2ME Wireless Toolkit is a comprehensive set of tools for building MIDP applications. El J2ME Wireless Toolkit es un conjunto completo de herramientas para crear aplicaciones MIDP. The toolkit can be used standalone, or incorporated into many popular integrated development environments (IDEs). El kit de herramientas se puede utilizar independiente o incorporada en muchos ambientes populares de desarrollo integrado (IDE). The Sun J2ME Wireless Toolkit supports the development of Java applications that run on devices such as cellular phones, two-way pagers, and palmtops. El J2ME Wireless Toolkit apoya el desarrollo de aplicaciones Java que se ejecutan en dispositivos tales como telfonos celulares, localizadores de dos vas, y palmtops.

30

Fig. 15 Ejemplo Java Wireless Toolkit 2.5.5 Apache Tomcat Apache Tomcat (tambin llamado Jakarta Tomcat o simplemente Tomcat) funciona como un contenedor de servlets desarrollado bajo el proyecto Jakarta en la Apache Software Foundation. Tomcat implementa las especificaciones de los servlets y de JavaServer Pages (JSP) de Sun Microsystems. Estado de su desarrollo Tomcat es mantenido y desarrollado por miembros de la Apache Software Foundation y voluntarios independientes. Los usuarios disponen de libre acceso a su cdigo fuente y a su forma binaria en los trminos establecidos en la Apache Software Licence. Las primeras distribuciones de Tomcat fueron las versiones 3.0.x. Las versiones ms recientes son las 7.x, que implementan las especificaciones de Servlet 3.0 y de JSP 2.2. Entorno Tomcat es un servidor web con soporte de servlets y JSPs. Tomcat no es un servidor de aplicaciones, como JBoss o JOnAS. Incluye el compilador Jasper, que compila JSPs convirtindolas en servlets. El motor de servlets de Tomcat a menudo se presenta en combinacin con el servidor web Apache. Tomcat puede funcionar como servidor web por s mismo. En sus inicios existi la percepcin de que el uso de Tomcat de forma autnoma era slo recomendable para entornos de desarrollo y entornos con requisitos mnimos de velocidad y gestin de transacciones. Hoy en da ya no existe esa percepcin y Tomcat es usado como servidor web autnomo en entornos con alto nivel de trfico y alta disponibilidad. Dado que Tomcat fue escrito en Java, funciona en cualquier sistema operativo que disponga de la mquina virtual Java.

31

Fig. 16 Servidor Apache Tomcat Estructura de directorios La jerarqua de directorios de instalacin de Tomcat incluye:

bin - arranque, cierre, y otros scripts y ejecutables common - clases comunes que pueden utilizar Catalina y las aplicaciones web conf - ficheros XML y los correspondientes DTD para la configuracin de Tomcat logs - logs de Catalina y de las aplicaciones server - clases utilizadas solamente por Catalina shared - clases compartidas por todas las aplicaciones web webapps - directorio que contiene las aplicaciones web work - almacenamiento temporal de ficheros y directorios (http://tomcat.apache.org/).

2.5.6 MySql Sistema de base de datos operacional MySQL es hoy en da uno de los ms importantes en lo que hace al diseo y programacin de base de datos de tipo relacional. Cuenta con millones de aplicaciones y aparece en el mundo informtico como una de las ms utilizadas por usuarios del medio. El programa MySQL se usa como servidor a travs del cual pueden conectarse mltiples usuarios y utilizarlo al mismo tiempo. La historia del MySQL (cuya sigla en ingls se traslada a My Structured Query Language o Lenguaje de Consulta Estructurado) se remite a principios de la dcada de 1980. Programadores de IBM lo desarrollaron para contar con un cdigo de programacin que permitiera generar mltiples y extendidas bases de datos para empresas y organizaciones de diferente tipo. Desde esta poca numerosas versiones han surgido y muchas de ellas fueron de gran importancia. Hoy en da MySQL es desarrollado por la empresa Sun Mycrosystems.

32

Fig. 17 MySQL Una de las caractersticas ms interesantes de MySQL es que permite recurrir a bases de datos multiusuario a travs de la web y en diferentes lenguajes de programacin que se adaptan a diferentes necesidades y requerimientos. Por otro lado, MySQL es conocida por desarrollar alta velocidad en la bsqueda de datos e informacin, a diferencia de sistemas anteriores. Las plataformas que utiliza son de variado tipo y entre ellas podemos mencionar LAMP, MAMP, SAMP, BAMP y WAMP (aplicables a Mac, Windows, Linux, BSD, Open Solaris, Perl y Phyton entre otras).

Se estn estudiando y desarrollando nuevas versiones de MySQL que buscan presentar mejoras y avances para permitir un mejor desempeo en toda aquella actividad que requiera el uso de bases de datos relacionales. Entre estas mejoras podemos mencionar un nuevo dispositivo de depsito y almacenamiento, backup para todos los tipos de almacenamientos, replicacin segura, planificacin de eventos y otras ms.

2.5.7 Servidor El protocolo HTTP viene siendo ampliamente utilizado desde el nacimiento de la web, en donde es indispensable para la creacin de aplicaciones que hacen uso de esta. Con la llegada de las tecnologas mviles pueden darse diversa situaciones en las que la creacin de un servidor HTTP en dispositivos limitados pueda resultar de gran utilidad. La plataforma J2ME dispone del soporte necesario para la creacin de todo tipo de clientes HTTP. Estos clientes HTTP estn pensados en un principio para la utilizacin y comunicacin con aplicaciones residentes en PCs, de modo que los dispositivos mviles puedan aprovechar todas los servicios ofrecidos por estas mquinas y tener acceso a todo tipo de informacin almacenada en ellas (pginas Web, aplicaciones para su descarga, etc.). El principal objetivo a conseguir es construir un servidor HTTP sobre el perfil J2ME MIDP, de manera que diferentes aplicaciones residentes en distintos dispositivos puedan comunicarse directamente a travs del protocolo HTTP.

33

El servidor residente en el dispositivo mvil ser el encargado de proporcionar los datos solicitados por las diferentes aplicaciones, de modo que no sea necesario un elemento intermedio (tpicamente un PC). A continuacin se describen en profundidad cada uno de los principales mdulos, siendo el primero de ellos el de configuracin, mediante el cual se definen las opciones bsicas de funcionamiento (temporizadores, nmero de conexiones simultaneas, puertos, tipos MIME soportados, etc.). A travs del sistema de archivos (segundo mdulo) se van a poder gestionar los recursos a albergar por el servidor as como resolver las peticiones de los usuarios. Ha sido necesario desarrollar un sistema de archivos en MIDP ya que RMS1 no proporciona ni mecanismos de acceso a ficheros, ni granularidad de permisos a la hora de acceder a los recursos existentes (archivos de sonido, imgenes). Por ltimo, es mediante el servicio de tratamiento de peticiones (tercer mdulo) que las diversas solicitudes HTTP podrn ser tratadas. Una vez tratada la arquitectura del sistema en detalle se procede a describir la funcionalidad implementada en el servidor, las cabeceras de peticin/respuesta existentes, los mtodos y cdigos de error (http://www.masadelante.com/faqs/servidor).

Fig. 18 Interaccin de un Servidor 2.5.8 Arquitectura El servidor est compuesto por tres mdulos principalmente. El primero de ellos es la configuracin mediante la cual se definen las opciones bsicas de funcionamiento. A travs del sistema de archivos (segundo mdulo) se van a poder gestionar los recursos a albergar por el servidor as como resolver las peticiones de los usuarios. Por ultimo es mediante el servicio de tratamiento de peticiones que las diversas solicitudes HTTP podrn ser tratadas.

34

El servidor ha sido diseado de modo que se minimice la complejidad a la hora de aadir futuras ampliaciones y mejoras. La utilizacin de patrones de diseo ha sido un factor determinante a la hora de lograrlo, ya que simplifican en extremo los cambios a realizar en el cdigo a la hora de modificarlo. La arquitectura de un servidor se divide de la siguiente forma: Arquitectura en 2 niveles

La arquitectura en 2 niveles se utiliza para describir los sistemas cliente/servidor en donde el cliente solicita recursos y el servidor responde directamente a la solicitud, con sus propios recursos. Esto significa que el servidor no requiere otra aplicacin para proporcionar parte del servicio.

Fig. 19 Arquitectura 2 Niveles Arquitectura en 3 niveles

En la arquitectura en 3 niveles, existe un nivel intermediario. Esto significa que la arquitectura generalmente est compartida por: 1. Un cliente, es decir, el equipo que solicita los recursos, equipado con una interfaz de usuario (generalmente un navegador Web) para la presentacin

2. El servidor de aplicaciones (tambin denominado software intermedio), cuya tarea es

proporcionar los recursos solicitados, pero que requiere de otro servidor para hacerlo 3. El servidor de datos, que proporciona al servidor de aplicaciones los datos que requiere

35

Fig. 20 Arquitectura 3 Niveles Arquitectura de niveles mltiples

En la arquitectura en 3 niveles, cada servidor (nivel 2 y 3) realiza una tarea especializada (un servicio). Por lo tanto, un servidor puede utilizar los servicios de otros servidores para proporcionar su propio servicio. Por consiguiente, la arquitectura en 3 niveles es potencialmente una arquitectura en N-niveles (http://es.kioskea.net/contents/cs/cs3tier.php3).

Fig. 21 Arquitectura 3 Niveles

2.5.9 Java ME

36

La plataforma J2ME es una familia de especificaciones que definen varias versiones minimizadas de la plataforma Java 2; estas versiones minimizadas pueden ser usadas para programar en dispositivos electrnicos; desde telfonos celulares, en PDAs, hasta en tarjetas inteligentes, etc. Estos dispositivos presentan en comn que no disponen de abundante memoria ni mucha potencia en el procesamiento, ni tampoco necesitan de todo el soporte que brinda el J2SE, (la plataforma estndar de Java usada en sistemas de escritorio y servidor) Qu es la plataforma J2ME? Al principio de los 90, Sun Microsystems cre un nuevo lenguaje de programacin llamado Oak como parte de un proyecto de investigacin para construir productos electrnicos que dependan principalmente del software. El primer prototipo para Oak fue un controlador portable llamado Star7, un pequeo dispositivo handheld con una pantalla touchscreen LCD que tena incorporado soporte a redes inalmbricas y comunicaciones infrarojas. Este dispositivo podra ser usado como control remoto para televisores o VCR y como gua de programas electrnicos, e incluso tena algunas funciones que ahora son asociadas a los PDAs, como agenda de citas. El software para este tipo de dispositivos necesitaba ser extremadamente confiable y no deba hacer excesivo uso de memoria ni requerir demasiada potencia en el procesador. Oak fue desarrollado como resultado de la experiencia del equipo de desarrollo con el lenguaje C++, el cual, a pesar de tener muchas grandes caractersticas, demostr que era un lenguaje complejo y ocasionaba que los programadores comentan fcilmente errores y eso afectaba la confiabilidad del software. Oak fue diseado para quitar o reducir la posibilidad de que los programadores comentan errores, cmo? detectando la mayora de errores en tiempo de compilacin y quitando algunas de las caractersticas del lenguaje C++ (como punteros y la administracin de memoria controlada por el programador) que eran los problemas ms comunes. Desafortunadamente, el mercado para el tipo de dispositivos que el nuevo lenguaje fue creado no se desarroll tanto como Sun Microsystems esperaba, y al final ningn dispositivo basado en Oak fue vendido a los clientes. Sin embargo, al mismo tiempo, el inicio del conocimiento pblico de Internet produjo un mercado para el software de navegacin para Internet (los navegadores Web). En respuesta a esto, Sun Microsystems renombr el lenguaje de programacin Oak a Java y lo us para desarrollar un navegador multiplataforma llamado HotJava. Tambin le dio la licencia de Java a Netscape, quienes lo incorporaron en su navegador que por ese entonces era el ms popular en el mercado, luego fueron incorporados los Java applets. En un par de aos, las capacidades multiplataforma del lenguaje de programacin Java y su potencia como plataforma de desarrollo para aplicaciones que podan ser escritas una vez y ejecutadas en diversos sistemas Windows y Unix, haba despertado el inters de usuarios finales, porque vieron en ella una manera de reducir los costos del desarrollo de software. Con el objetivo de conocer las necesidades de los experimentados desarrolladores en Windows y Motif/X-Windows para crear aplicaciones para usuarios finales sofisticados acostumbrados a usar

37

interfaces ricas, Sun Microsystems rpidamente expandi el alcance y tamao de la plataforma Java. Esta plataforma extendida incluy un conjunto ms complejo de libreras de interfaces de usuario que aquellos que usaran para construir applets, adems con un conjunto de caractersticas de computacin distribuida y seguridad mejorada. Con el tiempo Sun Microsystems liber la primera versin de la plataforma Java 2, haba sido necesario dividirla en varias piezas. La funcionalidad principal, estimado como el mnimo soporte requerido para cualquier ambiente Java, estaba empaquetada en el Java 2 Standard Edtion (J2SE). Muchos paquetes opcionales pueden ser agregados al J2SE para satisfacer requerimientos especficos para aplicaciones particulares, como extensiones seguras de sockets que permitan el comercio electrnico. Sun Microsystems tambin respondi al incremento del inters de usar Java para el desarrollo a un nivel empresarial, y ambientes de servidores de aplicaciones con la plataforma Java 2 Enterprise Edition (J2EE), el cual incorpora nuevas tecnologas como servlets, Enterprise JavaBeans, JavaServer pages, etc. Como la mayora de software, los requerimientos de recursos de Java tienen un incremento con cada nueva versin que aparece. A pesar que Java tiene sus races en el software para productos electrnicos pequeos, J2SE requiere mucha ms memoria y potencia en el procesador para que sea una solucin viable en el mercado. Irnicamente, mientras Sun Microsystems estaba desarrollando Java para Internet y para la programacin comercial, la demanda empez a crecer en los dispositivos pequeos e incluso en tarjetas inteligentes, retornando Java a sus races. Sun Microsystems respondi a esta demanda creando varias plataformas Java con funcionalidades reducidas, cada una hecha a la medida de un segmento vertical y especfico del mercado.

Fig. 22 Java Me

38

Estas plataformas reducidas estn todas basadas en el JDK 1.1, el predecesor de la plataforma Java 2, y cada una tiene una estrategia diferente al problema de reducir la plataforma para acomodarla a los recursos disponibles. Por lo tanto, cada una de estas plataformas de funcionalidad reducida representan una solucin ad hoc al problema. Por ello es que aparece la plataforma J2ME, para reemplazar todas esas plataformas reducidas basadas en el JDK 1.1 y crear una sola solucin basada en Java 2. Resumen En conclusin, J2ME es la versin de Java orientada a los dispositivos mviles. Debido a que los dispositivos mviles tienen una potencia de clculo baja e interfaces de usuario pobres, es necesaria una versin especfica de Java destinada a estos dispositivos, ya que el resto de versiones de Java, J2SE o J2EE, no encajan dentro de este esquema. J2ME es por tanto, una versin reducida de J2SE. 2.5.10 JSP y Servlets Los servlets son mdulos java que nos sirven para extender las capacidades de los servidores web. Aunque es una definicin un poco ambigua los servlets son programas para los servidores, mientras que los applets son programas para los clientes y los middlets los programas para micro dispositivos. Pequeo programa que corre en un servidor. Por lo general son aplicaciones Java que corren en un entorno de servidor web. Esto es anlogo a una aplicacin Java que corre en un navegador. Un servelt es un programa del lado del servidor escrito en lenguaje Java que interacta con clientes y que normalmente est unido a un servidor de "HyperText Transfer Protocol" (HTTP). Uno uso comn para un servlet es ampliar un servidor web proporcionando contenidos web dinmicos. Los servlets son objetos que corren dentro del contexto de un contenedor de servlets (ej: Tomcat) y extienden su funcionalidad. Tambin podran correr dentro de un servidor de aplicaciones (ej: OC4J Oracle) que adems de contenedor para servlet tendr contenedor para objetos ms avanzados como son los EJB (Tomcat slo es un contenedor de servlets). El uso de los servlets viene a ser en un tanto por ciento elevando el del desarrollo de pginas web dinmicas (en contenido y diseo) apoyndose adems en la potencia que nos proporciona el lenguaje Java. Ciclo de vida del servlet Describir un servlet es como describir una mquina de estados. Desde el momento que inicializamos el servlet hasta que el servlet es destruido, este, pasar por una serie de estados dependiendo de cada una de las situaciones ante las que se encuentre (http://www.aves.edu.co/ovaunicor/recursos/1/index_Arquitectura_de_software.pdf).

39

Fig. 23 Interaccin de un Servlet JSP (Java Server Page) Pgina de Servidor Java. Se refiere a un tipo especial de pginas HTML, en las cuales se insertan pequeos programas que corren sobre Internet (comunmente denominados scripts), se procesan en lnea para finalmente desplegar un resultado final al usuario en forma de HTML. Por lo general dichos programas hacen consultas a bases de datos y dependiendo del resultado que se despliegue ser la informacin que se muestre a cada usuario de manera individual. Los archivos de este tipo llevan la extensin .jsp. JSP puede considerarse como una manera alternativa, y simplificada, de construir servlets. Es por ello que una pgina JSP puede hacer todo lo que un servlet puede hacer, y viceversa. Cada versin de la especificacin de JSP est fuertemente vinculada a una versin en particular de la especificacin de servlets. El funcionamiento general de la tecnologa JSP es que el Servidor de Aplicaciones interpreta el cdigo contenido en la pgina JSP para construir el cdigo Java del servlet a generar. Este servlet ser el que genere el documento (tpicamente HTML) que se presentar en la pantalla del Navegador del usuario. El rendimiento de una pgina JSP es el mismo que tendra el servidor equivalente, ya que el cdigo es compilado como cualquier otra clase Java. A su vez, la mquina virtual compilar dinmicamente a cdigo de mquina las partes de la aplicacin que lo requieran. Esto hace que JSP tenga un buen desempeo y sea ms eficiente que otras tecnologas web que ejecutan el cdigo de una manera puramente interpretada. La principal ventaja de JSP frente a otros lenguajes es que el lenguaje Java es un lenguaje de propsito general que excede el mundo web y que es apto para crear clases que manejen lgica de negocio y acceso a datos de una manera prolija. Esto permite separar en niveles las aplicaciones web, dejando la parte encargada de generar el documento HTML en el archivo JSP.

40

Otra ventaja es que JSP hereda la portabilidad de Java, y es posible ejecutar las aplicaciones en mltiples plataformas sin cambios. Es comn incluso que los desarrolladores trabajen en una plataforma y que la aplicacin termine siendo ejecutada en otra. Los servlets y Java Server Pages (JSPs) son dos mtodos de creacin de pginas web dinmicas en servidor usando el lenguaje Java. En ese sentido son similares a otros mtodos o lenguajes tales como el PHP, ASP o los CGIs, programas que generan pginas web en el servidor. Sin embargo, se diferencian de ellos en otras cosas.

Fig. 24 Interaccin JSP Para empezar, los JSPs y servlets se ejecutan en una mquina virtual Java, lo cual permite que, en principio, se puedan usar en cualquier tipo de ordenador, siempre que exista una mquina virtual Java para l. Cada servlet (o JSP, a partir de ahora lo usaremos de forma indistinta) se ejecuta en su propia hebra, es decir, en su propio contexto; pero no se comienza a ejecutar cada vez que recibe una peticin, sino que persiste de una peticin a la siguiente, de forma que no se pierde tiempo en invocarlo (cargar programa + intrprete). Su persistencia le permite tambin hacer una serie de cosas de forma ms eficiente: conexin a bases de datos y manejo de sesiones, por ejemplo. Los JSPs son en realidad servlets: 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 como un servlet. La principal diferencia entre los servlets y los JSPs es el enfoque de la programacin: un JSP es una pgina Web con etiquetas especiales y cdigo Java incrustado, mientras que un servlet es un programa Java puro que recibe peticiones y genera a partir de ellas una pgina web (http://es.wikipedia.org/wiki/JavaServer_Pages). 2.5.11 Visio y Enterprise Architect Microsoft Visio

41

Microsoft Visio es un software de dibujo vectorial para Microsoft Windows. Visio comenz a formar parte de los productos de Microsoft cuando fue adquirida la compaa Visio en el ao 2000. Las herramientas que lo componen permiten realizar diagramas de oficinas, diagramas de bases de datos, diagramas de flujo de programas, UML, y ms, que permiten iniciar al usuario en los lenguajes de programacin (http://office.microsoft.com/en-us/visio/). Enterprise Architect Enterprise Architect combina el poder de la ltima especificacin UML 2.1 con alto rendimiento, interfaz intuitiva, para traer modelado avanzado al escritorio, y para el equipo completo de desarrollo e implementacin. Con un gran conjunto de caractersticas y un valor sin igual para el dinero, EA puede equipar a su equipo entero, incluyendo analistas, evaluadores, administradores de proyectos, personal del control de calidad, equipo de desarrollo y ms, por una fraccin del costo de algunos productos competitivos. Verifique el rango completo de las herramientas y caractersticas case en detalle. Alta capacidad - Caractersticas finales superiores a un precio justo Enterprise Architect es una herramienta comprensible de diseo y anlisis UML, cubriendo el desarrollo de software desde el paso de los requerimientos a travs de las etapas del anlisis, modelos de diseo, pruebas y mantenimiento. EA es una herramienta multi-usuario, basada en Windows, diseada para ayudar a construir software robusto y fcil de mantener. Ofrece salida de documentacin flexible y de alta calidad. El manual de usuario est disponible en lnea. Velocidad, estabilidad y buen rendimiento El Lenguaje Unificado de Modelado provee beneficios significativos para ayudar a construir modelos de sistemas de software rigurosos y donde es posible mantener la trazabilidad de manera consistente. Enterprise Architect soporta este proceso en un ambiente fcil de usar, rpido y flexible. Para una mirada rpida al modelado UML en Enterprise Architect vea nuestro tutorial UML y documentos. Trazabilidad de extremo a extremo Enterprise Architect provee trazabilidad completa desde el anlisis de requerimientos hasta los artefactos de anlisis y diseo, a travs de la implementacin y el despliegue. Combinados con la ubicacin de recursos y tareas incorporados, los equipos de Administradores de Proyectos y Calidad estn equipados con la informacin que ellos necesitan para ayudarles a entregar proyectos en tiempo.

Fig. 25 Paquetera Architect

42

EA le ayuda a administrar la complejidad con herramientas para rastrear las dependencias, soporte para modelos muy grandes, control de versiones con proveedores CVS o SCC, Lneas Base por cada punto del tiempo, la utilidad de comparar (diff) para seguir los cambios del modelo, interfaz intuitiva y de alto rendimiento con vista de proyecto como un "explorador". A provee una generacin poderosa de documentos y herramientas de reporte con un editor de plantilla completo WYSIWYG. Genera reportes detallados y complejos de EA con la informacin que usted necesita en el formato que su compaa o cliente demanda. EA soporta generacin e ingeniera inversa de cdigo fuente para muchos lenguajes populares, incluyendo C++, C#, Java, Delphi, VB.Net, Visual Basic y PHP. Tambin hay Add-ins gratis para CORBA y Python disponibles. Con un editor de cdigo fuente con "resaltador de sintaxis" incorporado, EA le permite navegar y explorar su modelo de cdigo fuente en el mismo ambiente. Para aquellos que trabajan en Eclipse o Visual Studio.Net, Sparx Systems tambin vende puentes livianos para estas IDE's, permitindole modelar en EA y saltar directamente al cdigo fuente en su editor preferido. Las plantillas de generacin de cdigo le permiten personalizar el cdigo fuente generado a las especificaciones de su compaa. EA le ayuda a visualizar sus aplicaciones soportando ingeniera inversa de un amplio rango de lenguajes de desarrollo de software y esquemas de repositorios de base de datos. Ingrese frameworks completos desde cdigo fuente o archivos Java .jar - o an ensambladores binarios .Net! Importando frameworks y libreras de cdigo, Ud. puede maximizar la re-utilizacin y entendimiento de su inversin existente. EA soporta transformaciones de Arquitectura avanzada dirigida por Modelos (MDA) usando plantillas de transformaciones de desarrollo y fciles de usar. Con transformaciones incorporadas para DDL, C#, Java, EJB y XSD, Ud. puede rpidamente desarrollar soluciones complejas desde los simples "modelos independientes de plataforma" (MIP) que son el objetivo en "modelos especficos de plataforma" (MEP). Un MIP se puede usar para generar y sincronizar mltiples MIP's proveyendo un aumento de productividad significativo (http://www.sparxsystems.com.ar/products/ea.html). 2.5.12 Arquitectura empresarial Una arquitectura empresarial (EA) es una descripcin rigurosa de la estructura de una empresa, que comprende los componentes de la empresa (entidades comerciales), las propiedades externamente visibles de esos componentes, y las relaciones (por ejemplo, el comportamiento) entre ellos. EA describes the terminology, the composition of enterprise components , and their relationships with the external environment, and the guiding principles for the requirement (analysis) , design , and evolution of an enterprise.
[ 1 ] [ 2 ]

This description is comprehensive, including

enterprise goals, business process , roles, organizational structures, organizational behaviors, business information , software applications and computer systems . EA se describe la terminologa, la composicin de los componentes de la empresa, y sus relaciones con el entorno

43

externo, y los principios rectores de la necesidad (anlisis), el diseo y la evolucin de una empresa.
[1] [2]

Esta descripcin es completa, incluyendo objetivos de la empresa, procesos de

negocio , funciones, estructuras organizativas, los comportamientos de la organizacin, la informacin de negocios , aplicaciones de software y sistemas informticos . Practitioners of EA call themselves " enterprise architects ." Los practicantes de la EA se hacen llamar " arquitectos de la empresa". An enterprise architect is a person responsible for developing the enterprise architecture and is often called upon to draw conclusions from it.Un arquitecto de la empresa es una persona responsable para el desarrollo de la arquitectura de la empresa y se invita a menudo a sacar conclusiones de ello. By producing an enterprise architecture, architects are providing a tool for identifying opportunities to improve the enterprise, in a manner that more effectively and efficiently pursues its purpose.
[ citation needed ]

Mediante la produccin de una

arquitectura empresarial, los arquitectos estn proporcionando una herramienta para identificar oportunidades para mejorar la empresa, de manera que ms eficaz y eficiente persigue su propsito. Alcance The term "enterprise" is used because it is generally applicable in many circumstances, includingEl trmino "empresa" se utiliza porque es de aplicacin general en muchas circunstancias, incluyendo

Public or Private Sector organizations Organizaciones pblicas o privadas del sector An entire business or corporation Toda una empresa o corporacin A part of a larger enterprise (such as a business unit) A parte de una empresa ms grande (como una unidad de negocio) A conglomerate of several organizations, such as a joint venture or partnership Un conglomerado de varias organizaciones, como una empresa conjunta o sociedad A multiply outsourced business operation Una empresa subcontratada se multiplican operacin
[ 3 ]

The term enterprise includes the whole complex, socio-technical system, empresa incluye todo el complejo, sistema socio-tcnico, incluyendo:

including:El trmino

people personas information informacin technology tecnologa business (eg operations) negocio (por ejemplo, las operaciones)

Defining the boundary or scope of the enterprise to be described is an important first step in creating the enterprise architecture. La definicin de los lmites o el alcance de la empresa que se describe es un primer paso importante en la creacin de la arquitectura de la empresa. "Enterprise" as used in enterprise architecture generally means more than the information systems employed by

44

an organization.

[4]

"Enterprise" como se usa en la arquitectura general de la empresa significa ms

que los sistemas de informacin empleados por la organizacin. [ edit ] Methods and frameworksLos mtodos y los marcos Enterprise architects use various business methods, analytical techniques and conceptual tools to understand and document the structure and dynamics of an enterprise.Arquitectos de la empresa utilizan diversos mtodos de negocio, tcnicas analticas y herramientas conceptuales para comprender y documentar la estructura y dinmica de una empresa. In doing so, they produce lists, drawings, documents and models, together called " artifacts ". Al hacerlo, producen listas, planos, documentos y modelos, denominados en conjunto " artefactos". These artifacts describe the logical organization of business functions, business capabilities, business processes, people organization, information resources, business systems, software applications, computing capabilities, information exchange and communications infrastructure within the enterprise. Estos artefactos describir la organizacin lgica de las funciones de negocio, capacidades de negocio, los procesos de negocio, organizacin de la gente, los recursos de informacin, sistemas empresariales, aplicaciones de software, las capacidades de computacin, el intercambio de informacin e infraestructura de comunicaciones dentro de la empresa. A collection of these artifacts, sufficiently complete to describe the enterprise in useful ways, is considered by EA practitioners an 'enterprise' level architectural description, or enterprise architecture, for short.Una coleccin de estos artefactos, lo suficientemente completo para describir la empresa de manera til, es considerada por los profesionales de EA descripcin de una "empresa" a nivel de arquitectura, arquitectura de la empresa o, para abreviar. The UK National Computing Centre EA best practice guidance Computacin EA normas de buenas prcticas
[5] [ 5 ]

states El Reino Unido Centro Nacional de

Estados

Normally an EA takes the form of a comprehensive set of cohesive models that describe the structure and functions of an enterprise.Normalmente, una EA toma la forma de un conjunto completo de modelos de cohesin que describen la estructura y funciones de una empresa. The individual models in an EA are arranged in a logical manner that provides an ever-increasing level of detail about the enterprise: its objectives and goals; its processes and organization; its systems and data; the technology used and any other relevant spheres of interest.Los modelos individuales en un EA estn dispuestos de una manera lgica que proporciona un nivel creciente de detalle acerca de la empresa: sus objetivos y metas, sus procesos y la organizacin, sus sistemas y datos, la tecnologa utilizada y las otras esferas de inters relevante. An enterprise architecture framework bundles tools, techniques, artifact descriptions, process models, reference models and guidance used by architects in the production of enterprise-specific architectural description. Un marco de arquitectura empresarial paquetes de herramientas, tcnicas, descripciones de artefactos, modelos de procesos, modelos de referencia y orientacin utilizados por los arquitectos en la produccin de una empresa concreta descripcin arquitectnica.

45

A unified architecture framework consists of a coherent set of integral modules to collectively form a holistic discipline guiding the process of development of architected solutions in an enterprise computing environment, as described in Solution Architecting Mechanism (SAM) .
[6]

Un marco de

arquitectura unificada consiste en un conjunto coherente de mdulos integrales para formar en conjunto una disciplina holstica que guan el proceso de desarrollo de soluciones de arquitectura en un entorno informtico empresarial, tal como se describe en el Mecanismo de Solucin de Arquitectura (SAM). [ edit ] Areas of practicereas de prctica Several enterprise architecture frameworks break down the practice of enterprise architecture into a number of practice areas or " domains ".Varios marcos de arquitectura empresarial romper la prctica de la arquitectura de la empresa en un nmero de reas de prctica o " dominios". In his book on Enterprise Architecture, Spewak divides the practice into two domains at 'level 2': "Business Modelling" and "Current Systems and Technology" and three subordinate domains at 'level 3': "Data Architecture", "Applications Architecture" and "Technology Architecture". En su libro sobre la Arquitectura Empresarial, Spewak divide a la prctica en dos dominios de "nivel 2": "Modelos de Negocios" y "Sistemas y la tecnologa actual", y tres dominios subordinados a un "nivel 3": "Datos de la Arquitectura", "Arquitectura de Aplicaciones" y "Tecnologa de la Arquitectura". The final level of Spewak's EAP is the "Implementation" or "Methods" level, which deals with "how" to migrate the Enterprise to match the new model. para que coincida con el nuevo modelo. The popular TOGAF framework divides the practice into three domains: "Business Architecture", "Information Systems Architecture" and "Technology Architecture" and then subdivides the information systems architecture into "Information Architecture and "Applications Architecture".
[9] [ 8 ]

El ltimo nivel de la PEA

Spewak es la "aplicacin" o el nivel de "Mtodos", que trata sobre "cmo" para migrar la empresa

La

popular estructura de TOGAF divide la prctica en tres mbitos: "La arquitectura de negocios", "Arquitectura de Informacin de Sistemas" y "Arquitectura de la tecnologa", y luego se subdivide la arquitectura de sistemas de informacin en "Arquitectura de la Informacin y" Arquitectura de aplicaciones". The Strategic Architecture Model allows for a flexible division into up to ten domains covering many aspects of an enterprise from its objectives and goals through its projects and programmes to its software applications and technology.
[ 10 ]

El modelo de arquitectura estratgica permite una divisin

flexible en un mximo de diez mbitos que abarca muchos aspectos de una empresa de sus objetivos y metas a travs de sus proyectos y programas para sus aplicaciones de software y la tecnologa. EA Domains: An enterprise architecture's landscape is usually divided into various domains based on the attributes of the environment and the logical grouping based on Industry EA FrameworksDominios EA: Una arquitectura de paisaje empresa se divide en diferentes mbitos

46

sobre la base de los atributos del medio ambiente y la agrupacin lgica basada en la industria marcos EA The dividing of the practice into a number of domains allows enterprise architects to describe an enterprise from a number of important perspectives.La divisin de la prctica en una serie de dominios permite a los arquitectos de la empresa para describir una empresa de un nmero de puntos de vista importantes. This practice also encourages the contributions of many individuals and allows the practice as a whole to make good use of individual domain-specific expertise and knowledge. Esta prctica tambin alienta la contribucin de muchas personas y permite la prctica en su conjunto para hacer un buen uso de dominio especfico de cada experiencia y conocimiento. By taking this approach, enterprise architects can ensure a holistic description is produced. Con este enfoque, los arquitectos de la empresa puede garantizar una descripcin global que se produce. The popular and most common four domains and their component parts look like this: El popular y ms comn de cuatro dominios y sus componentes el siguiente aspecto:

1. Business: Negocio: 1. Strategy maps, goals, corporate policies, Operating Model Los mapas estratgicos,
los objetivos, las polticas corporativas, modelo operativo

2. Functional decompositions (eg IDEF0 , SADT ), business capabilities and

organizational models expressed as enterprise / line of business architecture Descomposiciones funcionales (por ejemplo, IDEF0 , TDAA ), las capacidades de negocio y modelos de organizacin expresado en la empresa / lnea de la arquitectura de negocio

3. Business processes , Workflow and Rules that articulate the assigned authorities,
responsibilities and policies Los procesos de negocio , flujo de trabajo y reglas que articulan el asignado las autoridades, las responsabilidades y las polticas

4. Organization cycles, periods and timing Los ciclos de la organizacin, plazos y

calendario

5. Suppliers of hardware , software , and services Los proveedores de hardware ,

software y servicios

2. Information: Informacin: 1. Information architecture - a holistic view on the flow of information in an enterprise
Arquitectura de la informacin - una visin holstica sobre el flujo de informacin en una empresa

2. Data Architecture - describes the way data will be processed, stored , data flows
and used by the projects teams that will use it Arquitectura de datos - se describe

47

la forma de datos ser procesada, almacenada, los flujos de datos y utilizada por los equipos de proyectos que va a usar

3. Master Data Management , is the authoritative, reliable foundation for data used
across many applications and business processes with the goal to provide a single view of the truth no matter where the data is located Master Data Management , es la base autorizada y confiable para los datos utilizados en muchas aplicaciones y procesos de negocio con el objetivo de proporcionar una visin nica de la verdad sin importar donde se encuentran los datos

4. Metadata - data that describes your enterprise data elements Metadatos - datos
que describen a su empresa los datos de los elementos

5. Business Intelligence Analytics & Reporting BI (Business Intelligence) is a broad

category of applications and technologies for gathering, storing, analyzing, and providing access to data to help the organization users make better business decisions. Business Intelligence y generacin de informes Analytics BI (Business Intelligence) es una categora amplia de aplicaciones y tecnologas para recopilar, almacenar, analizar y proporcionar acceso a los datos para ayudar a los usuarios de la organizacin a tomar mejores decisiones de negocios. These include the activities of decision support systems, query and reporting, dashboards , scorecards ,statistical analysis, forecasting, and data mining. stas incluyen las actividades de los sistemas de apoyo a las decisiones, consultas e informes, cuadros de mando, cuadros de mandos, anlisis estadstico, el pronstico, y minera de datos. This includes Reporting Data Stores ( Operational Data Store (ODS), Datamart and DataWarehouses) Esto incluye informes de almacenes de datos (almacn de datos operacionales (ODS), Datamart y Data Warehouse)

6. Data Quality helps identify, analyze, improve, and measure the data quality and
data integrity issues and improvement efforts Calidad de los datos ayuda a identificar, analizar, mejorar y medir la calidad de los datos y la integridad de los datos y los esfuerzos de mejora

7. Data models : conceptual expressed as enterprise information architectures,

logical, and physical Modelos de datos : conceptual expresada en las arquitecturas de informacin de la empresa, lgico y fsico

8. Data Life Cycle Management Processes to govern how to create, classify, update,
use, distribute, and archive, and obsolete data and information Vida de datos de gestin del ciclo de Procesos para gobernar la forma de crear, clasificar, actualizar, usar, distribuir y archivar, y datos obsoletos e informacin Enterprise Architecture Domains SubdomainsDominios de la empresa Arquitectura Subdominios

48

1. Applications: Aplicaciones: 1. Application software inventories and diagrams, expressed as conceptual /

functional or system enterprise / line of business architectures Aplicacin de software de inventarios y diagramas, expresado como empresa conceptual / o funcional del sistema / lnea de arquitecturas de negocio

2. Interfaces between applications - that is: events, messages Interfaces entre

aplicaciones - que es: eventos, los mensajes

2. Technology: Tecnologa: 1. Inter-application mediating software or 'middleware'. Entre aplicaciones de software

de mediacin o "middleware".

2. Application

execution

environments

and

operating

frameworks

including

applications server environments and operating systems, authentication and authorisation environments, security systems and operating and monitoring systems. Entornos de ejecucin de aplicaciones y marcos operativos, incluyendo entornos de aplicaciones de servidor y sistemas operativos, entornos de autenticacin y autorizacin de sistemas de seguridad y de operacin y sistemas de monitoreo.

3. Hardware, platforms, and hosting: servers , datacentres and computer rooms

Hardware, plataformas y hosting: servidores , centros de datos y salas de informtica

4. Local and wide area networks , Internet connectivity diagrams Locales y redes de
rea amplia , Internet diagramas de conectividad

5. Intranet , Extranet , Internet , eCommerce , EDI links with parties within and outside
of the organization Intranet , Extranet , Internet , comercio electrnico , EDI vnculos con los partidos dentro y fuera de la organizacin

6. Operating System Sistema Operativo 7. Infrastructure software: Application servers , DBMS Infraestructura de software:
Los servidores de aplicaciones , DBMS

8. Programming Languages , etc. expressed as enterprise / line of business

technology architecture. Lenguajes de programacin, expresado como empresa / lnea de la arquitectura de negocio de la tecnologa. [ edit ] Using an enterprise architectureLa utilizacin de una arquitectura empresarial Describing the architecture of an enterprise aims primarily to improve the effectiveness or efficiency of the business itself.Describir la arquitectura de una empresa tiene como principal objetivo mejorar

49

la eficacia o la eficiencia de la propia empresa. This includes innovations in the structure of an organization, the centralization or federation of business processes, the quality and timeliness of business information, or ensuring that money spent on information technology (IT) can be justified.
citation needed ] [

Esto incluye innovaciones en la estructura de una organizacin, la centralizacin o la

federacin de los procesos de negocio, la calidad y oportunidad de la informacin comercial, o asegurar que el dinero gastado en tecnologa de la informacin (TI) puede ser justificado (http://en.wikipedia.org/wiki/Enterprise_architecture). One method of using this information to improve the functioning of a business, as described in the TOGAF architectural framework, involves developing an "architectural vision": a description of the business that represents a "target" or "future state" goal.

CAPTULO III ANLISIS DEL PROBLEMA

En este apartado se incluir el anlisis derivado de la investigacin realizada dentro del contexto del mercado perteneciente a Aseguradoras, describiendo detalladamente los resultados obtenidos de dicha investigacin mediante grficas y diagramas, presentando a su vez el modelado de procesos que permita desarrollar, implementar y mejorar la eficiencia del sistema que se desarrollar buscando aumentar la satisfaccin de los clientes de la aseguradora. Este Captulo se dividir en el anlisis de la empresa y el diagnstico del problema. 3.1 Anlisis Descripcin de la organizacin Nombre: El guila, Compaa de Seguros, S.A. de C.V.,

50

Origen: Es una a empresa propiedad de la corporacin estadounidense GREAT AMERICAN INSURANCE GROUP, miembro de AMERICAN FINANCIAL GROUP (AFG). Giro: El guila es una empresa especializada en el seguro de automviles que opera en el mercado mexicano aplicando un novedoso procedimiento para determinar el seguro. Misin Somos una empresa de seguros especializada en el segmento de automviles de uso particular. Estamos en contacto con nuestros clientes a travs de mltiples canales y buscamos permanentemente su satisfaccin. Evaluamos el riesgo de forma integral considerando las caractersticas del conductor. Creamos valor para nuestros accionistas y colaboradores a travs de la innovacin y reconocimiento de nuestra marca. Visin Queremos ser la primera opcin para el cliente en la compra de seguro de auto, manteniendo un alto reconocimiento por la especializacin y profesionalismo de nuestros colaboradores. Nuestra meta es asegurar la proteccin del patrimonio de nuestros clientes otorgando siempre soluciones confiables, un trato personalizado y una red de proveedores de excelente calidad. Valores Integridad: Lograr que cada colaborador muestre con hechos la responsabilidad, rectitud, honestidad, coherencia y compromiso que tiene con la empresa y con los clientes. Trabajo en equipo: Lograr los resultados a travs del respeto, confianza, cooperacin y apoyo entre todos los colaboradores de la empresa, tomando en cuenta la comunicacin y valorando el tiempo de los dems. Innovacin: Ofrecer productos, servicios y procesos creativos y flexibles para nuestros clientes sin perder el objetivo establecido por la empresa. Eficiencia: Aprovechar y optimizar los recursos para alcanzar las metas ofreciendo calidad en el servicio.

51

Servicio: Tratar con calidez y amabilidad a nuestros clientes, proveedores y colaboradores, otorgando informacin veraz y oportuna para crear fidelidad y confianza. Servicios que ofrece: 1. Facilidad de compra: Adquiera su seguro sin salir de casa; basta con una llamada y nosotros nos encargamos de lo dems. 2. Precios competitivos: Somos la mejor opcin para el segmento de conductores de bajo riesgo. 3. Respaldo internacional: Somos parte de American Financial Group, una de las compaas de seguros con mayor prestigio en EEUU. 4. Ajustadores propios: Ms del 95% de los siniestros son atendidos por nuestros ajustadores, no por despachos independientes, para que siempre se sienta como en casa. 5. Cupn cliente de casa: Se otorga para pago de deducibles en la renovacin de su pliza. Es fundamental para El guila la promocin de sus productos por medio de Agentes profesionales establecidos que les dan un valor agregado, destacando sus ventajas, respaldo y solidez. Ventajas para nuestros Agentes: Producto competitivo especializado y dirigido a conductores de bajo riesgo. Sistema computarizado para efectuar cotizaciones. Atractivo plan de incentivos, con comisiones que llegan hasta el 25%. Programa de apoyo directo de renovacin de plizas. En caso de accidente, ser atendido por ajustadores de la compaa que le brindarn un servicio de calidad.

52

Fig. 26 Logo Compaa de Seguros.

3.2 Diagnostico Identificacin y definicin del problema El problema se encuentra en la solicitud de la informacin entre el agente y el cliente que tiene el siniestro vehicular, debido a que existe un retraso de la propia informacin y no existe algn sistema que ofrezca una posible ayuda en la interaccin del ambiente en que se desarrolla el siniestro. Esto refleja poca comunicacin y poca fiabilidad en la obtencin de informacin; por lo tanto en la mayora de las solicitudes de los clientes existe retraso o prdida de comunicacin (informacin). Es conveniente realizar dicho software que evite prdida o retraso de informacin en el ambiente donde se genera la solicitud de siniestro vehicular.

Organigrama General de la Empresa La asegurador El Aguila tiene el siguiente organigrama.

53

Fig. 27 Organigrama General El Aguila

CAPITULO IV PROPUESTA Y DISEO DE SOLUCIN

Se desarrolla una aplicacin mvil para gestionar los siniestros que se presenten en determinado momento de una forma innovadora.

54

Con la finalidad de integrar la informacin de tal manera que el procedimiento sea lo ms ptimo posible mediante el uso de interfaces amigables y tecnologa de punta. 4.1 Determinacin de la solucin al problema La solucin correspondiente es el del desarrollo del software correspondiente, ya que nos permite crear las herramientas y mdulos para la fcil gestin de siniestros vehiculares a travs de nuevas tecnologas mviles. Algunas de las ventajas son las siguientes: Portabilidad en el manejo de informacin Informacin integra El costo es menor El tiempo de desarrollo es corto Personal con la suficiente experiencia sobre el rea y gestin de incidentes Innovacin de nuevas herramientas y mdulos para dispositivos mviles

4.2 Seleccin del proceso: problema a sistematizar El proceso a sistematizar consiste en el apoyo de informacin al ambiente en donde se genera el siniestro vehicular, desde que el cliente solicita apoyo hasta la evaluacin y culminacin del apoyo del agente en dicho siniestro. 4.3 Definicin de necesidades que genera el problema El problema genera las siguientes necesidades: Establecer las referencias adecuadas para los procesos del siniestro, como: tiempos, valuacin del siniestro, obtencin de informacin. Establecer ciertas herramientas que se puedan programar para controlar los siniestros vehiculares. Capacitacin a las reas correspondientes para utilizar las herramientas programadas Obtencin de equipos mviles y comunicaciones para el soporte de los procesos

4.4 Definicin de Actividades Las personas que lo harn son las siguientes: Ing. en Informtica Etapa de inicio Etapa de elaboracin Etapa de construccin

Programadores

55

Etapa de construccin Etapa de transicin

Tcnico en mantenimiento y soporte

Actividad Inicio Elaboracin Construccin Transicin

Responsable I I I, P I, T x

Mes 1 x x x X

Mes 2 x x x x

Mes 3

I P T

Ing. En Informtica Programadores Tcnico en mantenimiento y soporte

Tabla 4 Actividades, Responsables y estadsticas de Tiempo

4.5 Definicin y especificacin de requerimientos Investigacin y generacin de lista de requerimientos (Software, Hardware, Personal, comunicaciones, materiales y equipo) Requerimientos Programacin de las herramientas a utilizar Un servidor apropiado para estas reas en especifico Equipo de cmputo para cada rea (PC y cableado) Personal capaz para la instalacin de la red y el sistema

Software de Base Sistema Operativo Antivirus Paquetera de cartografa Hardware PCs Conexin a Internet Concentrador y switch Componentes para instalacin (canaletas, cable, etc)

56

Equipo de Oficina Sillas Escritorios Personal Tcnicos en mantenimiento y soporte Programadores Ing. en Informtica Tabla 5 Definicin de Requerimientos

Requerimiento Software de aplicacin Requerimientos funcionales

Descripcin del requerimiento

Peso

Referencias de las reas Informes de costos y presupuestos de acuerdo al tipo de trabajo No Funcionales Acceder a las base de datos Respaldar la base de datos Dominio Comunicacin de las reas de cartografa

3 1

3 3 3

57

Software de base, de seguridad y herramientas Sistema operativo Paqueteras de cartografa Anti-Virus Hardware PCs Concentrador y Switch Componentes para la instalacin de LAN (cables, canaletas, rosetas, etc...) Nobreak Conexin a Internet Equipo de oficina Sillas Escritorios Tcnico en mantenimiento y soporte Ingeniero informtico Programadores Personal 1 1 2 3 1 2 3 3 2 2 3 2 1

1 Opcional 2 Deseable 3 Requerido Tabla 6 Descripcin de Requerimientos Requerimiento Requerimientos funcionales Referencias de las reas Informar costos y presupuestos de acuerdo al tipo de trabajo No Funcionales Acceder a las base de datos Respaldar la base de datos Dominio Comunicar las reas de la empresa Descripcin del requerimiento

Tabla 7 Requerimientos Funcionales, No Funcionales Y Dominio

58

Analizando el requerimiento de dominio, se determin que es un requerimiento funcional ya que el software a desarrollar permitir realizar parte esencial del proceso del flujo de informacin con respecto a este requerimiento.

Requerimiento Requerimientos funcionales

Descripcin del requerimiento Comunicar las reas de la empresa Referencias de las reas Informar costos y presupuestos de acuerdo al tipo de trabajo

No Funcionales Acceder a las base de datos Respaldar la base de datos Tabla 8 Requerimientos Funcionales y No Funcionales

4.6 Anlisis de Riesgos

IMPACTO SI EL RIESGO SE PRESENTA

PROBABILIDAD DE OCURRENCIA RIESGOS TCNICOS No se halla capacitado correctamente al personal.

PRIORIDAD DEL RIESGO

IMPACTO

SEVERIDAD

El personal no utilizar correctamente el Software y aprovechar al mximo todas sus herramientas 0.4 y servicios 5

0.6

0.76

59

Existan problemas para la implementacin del sistema

La implantacin del sistema podra ser cancelado si es que no se puede implantar 0.4 correctamente El presupuesto no alcanzara para poder seguir con la implantacin del 0.2 sistema Provocar un retraso en el desarrollo del software y un 0.4 mayor costo. 1 2 6

0.4

0.64

El proyecto se termine despus del plazo establecido

0.4

0.52

El software no sea corregible fcilmente

0.4

0.64

Tabla 9 Anlisis de Riesgos

Concepto Alta Media Baja

Prioridad 8 * 10 5*7 1*4

Concepto Seguro - Ocurrir el riesgo Casi seguro ocurrir el riesgo Probablemente ocurra el riesgo Puede ser que ocurra el riesgo Quizs ocurra el riesgo

Probabilidad 1.0 0.9 0.8 0.6 0.4

60

No lo creo que ocurra el riesgo

0.2

Improbable que ocurra el riesgo Casi seguro que no ocurrir el riesgo

0.1

Tabla 10 Definicin de probabilidades de riegos 4.7 Administracin del riesgo Como sabemos la administracin de riesgos es un enfoque estructurado para manejar la incertidumbre relativa a una amenaza, a travs de una secuencia de actividades humanas que incluyen evaluacin de riesgo, estrategias de desarrollo para manejarlo y mitigacin del riesgo utilizando recursos gerenciales. Las estrategias incluyen transferir el riesgo a otra parte, evadir el riesgo, reducir los efectos negativos del riesgo y aceptar algunas o todas las consecuencias de un riesgo particular. Algunas veces, el manejo de riesgos se centra en la contencin de riesgo por causas fsicas o legales (por ejemplo, desastres naturales o incendios, accidentes, muerte o demandas). Por otra parte, la gestin de riesgo financiero se enfoca en los riesgos que pueden ser manejados usando instrumentos financieros y comerciales. El objetivo de la gestin de riesgos es reducir diferentes riesgos relativos a un mbito preseleccionado a un nivel aceptado por la sociedad. Puede referirse a numerosos tipos de amenazas causadas por el medio ambiente, la tecnologa, los seres humanos, las organizaciones y la poltica. Por otro lado, involucra todos los recursos disponibles por los seres humanos o, en particular, por una entidad de manejo de riesgos. A continuacin se describe una lista de para prevenir futuros riesgos en la implementacin de nuestro software. Definir el personal responsable para la implementacin de software Capacitar al personal que posteriormente manejar el software desarrollado Definir las bases de requerimientos y administre los cambios Iniciar el proyecto con el personal experto necesario No disminuir los estndares con el fin de acortar el proceso de planeacin

61

CAPTULO V DESARROLLO DE SOLUCIN

Se utilizara una metodologa de desarrollo de software orientada a objetos con la finalidad de que el proyecto soporte diferentes arquitecturas mviles. Se reunir los requisitos necesarios para poder programar en bases a las entidades que participarn en el proceso (cliente ajustador unidad central), dividiendo la codificacin en mdulos para la programacin en paralelo.

5.1 Casos de Uso Contexto

62

Ingreso al sistema

63

Levantar reporte del siniestro

Nivel 0

64

Monitoreo Estatus del siniestro

65

5.2 Diagrama Entidad Relacin

66

5.3 Diagrama de actividad

67

Ajustadorinformacin,para a la Proporciona informacinla Seguros verifica acciones Recibe y El Aguila evala Recibe, esperainformacin Solicitud ajustador Cliente apoyo hacia de Recibe Solicita Recibe informacin del Determina las ayuda para ajustador creada poryel cliente solicitudaseguradora asigna la procedente de evidencias resolucinproporcionaya ejecutarsiniestro cliente datos y y la delsiniestro ajustador (Toma y realiza apertura Recibeen aseguradora statuscaso de del evala que est status del siniestro siniestro, de proceso el caso de siniestro siniestro evaluacin de ayuda, etc). conocimiento.

68

5.4 Diagrama de Estados

Evala siniestro / Genera apertura Solicitud de y Verifica Consulta Almacena Recibe clausura de caso y informacin yen informacin la informacin verifica a ayuda y enva asignaBDstatus aseguradora evidencias asigna status siniestro

69

5.5 Diagrama de secuencia o iteracin

70

Sistemastatus y Espera y genera Analiza a la Consulta El Proporciona Adquiere Clasifica Solicitud Almacena Ajustado Cliente status de siniestro evala atencin informacin al aseguradora y informacin Siniestro r guila actualiza BD cliente

71

5.6 Diagrama de tiempo

72

Sistema ydeaEl de y Analiza de atencin a Proporciona de Consulta estudio Adquiere de Clasifica Solicitud Espera Ajustado mximo Cliente Tiempo de Tiempo genera Tiempo Tiempo consulta: Tiempo Tiempo diversasminutos 1 2 min. informacin minutos respuestadel min. informacinminutos presupuesto guila15 al r anlisis:reas recepcin3 cliente: 4055 almacenamiento: espera: transmisin: 5 cliente segundos segundos

73

Almacena informacin y actualiza BD

74

Tomar Evaluar Proporcion Envo / Asesorar Verificar Solicitud Cliente Ajustador evidencia ajustador ar datos recepcin de al cliente y informacin Ayuda respaldar informacin informacin

5.7 Diagrama de paquetes

75

5.8 Diagrama de componentes

Respaldo de informacin Base de Ayuda informacin Solicitud Datos Siniestro Transmisin de Cliente de Rutinas Ajustador Dispositivo conexin ajustador o cliente / Mvil viceversa Envo/recepcin de datos.

76

5.9 Diagrama de comunicacin o despliegue

DBMSde Datos Call center (Aseguradora Base Ajustador Equipo (Evidencia de Switches Servidor siniestros y respaldo inf.) de guila El El quila) Trabajo

77

5.10 Descripcin del Sistema 1.-Login Hay dos tipos de usuarios principales: Cliente/Asegurado: Es la persona que reporta el siniestros desde su dispositivo mvil y adems puede consultar el estatus de su reporte para darle seguimiento.

78

Ajustador: Recibe informacin del siniestro, acude al lugar para auxiliar al asegurado y actualiza informacin en el reporte levantado por el asegurado, enva informacin a la central de servicio para su consulta y seguimiento. Para ingresar al sistema el usuario debe introducir los siguientes datos: Nombre de Usuario Contrasea

La pantalla que se presentar es la siguiente:

Fig. 29 Login del Sistema 2.- Levantar reporte del siniestro El cliente o asegurado podr dar parte de un accidente desde su dispositivo mvil a la central de servicio, enviando informacin del accidente y del estado del vehculo para levantar un reporte del siniestro. Se requieren los siguientes datos: a) Pliza: Nmero de pliza del cliente. b) Fecha del siniestro: la cual se cargar automticamente al ingresar a la pantalla.

79

c) Ubicacin: Lugar donde ocurri el siniestro. d) Descripcin: pequea descripcin de lo que ocurri y se gener el siniestro.

Fig. 30 Captura de Datos Despus de haber ingresado los datos mencionados anteriormente el usuario deber seleccionar la opcin Enviar, como se muestra en la siguiente pantalla:

80

Fig. 31 Envi de informacin del Sistema

El sistema mandar un mensaje al usuario informndole que el envo de los datos fue exitoso, como se muestra en la imagen que se presenta a continuacin:

Fig.32 Comprobacin de Datos

3.-Monitorear estatus del siniestro El ajustador recibir la siguiente informacin del siniestro: Folio: Nmero del siniestro que fue asignado por la central del servicio. Fecha: Fecha del siniestro. Ubicacin: Lugar donde ocurri el siniestro para que acuda inmediatamente Cliente: Nombre del cliente que reporto el siniestro.

Fig.33 Asignacin de Siniestro Ajustador

81

El ajustador tiene la opcin de Actualizar el reporte levantado previamente por el asegurado, seleccionado la opcin Actualizar , mostrada en la pantalla anterior, una vez elegida esta opcin se mostrar la pantalla para actualizar los datos del reporte y enviar los datos al servidor ubicado en la Central de Servicio o Call Center.

Fig. 34 Status de Siniestro Se mostrarn los siguientes datos: Folio Fecha Ubicacin

El ajustador podr actualizar los siguientes campos de acuerdo a la situacin del siniestro: Estatus Descripcin

El estatus del siniestro puede tomar los siguientes valores: Abierto: Cuando el asegurado da de alta el reporte, el siniestro toma este estatus por default. Pendiente: Cuando el siniestro aun no est resuelto, por falta de pruebas o los involucrados aun no llegan a un acuerdo. Resuelto: Las partes involucradas han llegado a un acuerdo Cerrado: El caso est totalmente solucionado.

82

Fig. 35 Respuesta del Status por parte de la Central

Para guardar los datos actualizados en el reporte, el usuario deber seleccionar la opcin Enviar, posteriormente aparecer un mensaje en que se confirma el envo exitoso de los datos al servidor de la Central de servicio. 4.-Mdulo Central de Servicio/Call Center La informacin es almacenada en el servidor de la Aseguradora, dicha informacin la podrn consultar y manipular las diversas Centrales de servicio ubicadas en diferentes zonas, a continuacin se presentan las pantallas principales que podrn manipular: 1.-Consulta de siniestros Esta pantalla mostrar los siniestros dados de alta, se mostrarn los siguientes datos:

Folio: Nmero de Folio asignado por el Call Center o central de servicio

Descripcin: Descripcin del siniestro cuando se dio de alta por primera vez. Ubicacin: Lugar donde ocurri el siniestro. Cliente: Numero de cliente que reporto el siniestro. Ajustador: Nmero del ajustador al cual le fue asignado el siniestro.

83

Fig. 36 Consulta Siniestro 2.-Consulta de Reportes Esta pantalla mostrar los reportes registrados y actualizados por el cliente y el ajustador, se mostrarn los siguientes datos:

Folio del reporte: Nmero de Folio asignado por el Call Center o central de servicio
Descripcin: actualizacin de la descripcin del siniestro por parte del ajustador. Fecha: Fecha en que ocurri el siniestro. Ubicacin: Lugar donde ocurri el siniestro. Status: Ultimo estatus del siniestro actualizado por el ajustador.

Fig. 37 Consulta Reporte

CONCLUSIONES
En general concluimos que el desarrollo del proyecto Sistema integral en plataforma mvil para la gestin de siniestros vehiculares nos proporcion los conocimientos necesarios para el desarrollo de aplicaciones web y aplicaciones en dispositivos mviles. La investigacin realizada en el mercado en conjunto con el conocimiento adquirido en el seminario permiti obtener las herramientas necesarias para agilizar los procesos en cada una de las etapas de la metodologa empleada permitiendo lograr el alcance establecido para la finalizacin del proyecto de forma oportuna. El Sistema desarrollado garantiza la optimizacin de los procesos de la empresa ayudando a que el monitoreo y gestin desde la central de servicio cumpla con el objetivo de minimizar el tiempo de arribo y la comunin entre las partes involucradas, sirviendo como un enlace que proporciona a

84

los clientes un servicio ms completo, brindando atencin y proteccin inmediata a todos sus intereses. Consideramos que las tecnologas empleadas permitirn incrementar el alcance del sistema de forma eficiente debido a que actualmente son las que tienen ms auge dentro del mercado y mayor popularidad entre los desarrolladores de sistemas.

BIBLIOGRAFA

Joyanes Aguilar, Luis. "Java 2 - Manual de Programacion", Edit. McGraw Hill/Interamericana Editores, Mexico. 2010 Joyanes Aguilar, Luis y Zahonero Martnez, Ignacio. Programacin en C, C++, Java y UML. Edit. McGraw Hill/Interamericana Editores, Mexico. 2010 Kendall & Kendall. ANALISIS Y DISEO DE SISTEMAS 6TA. EDICION. Edit. Prentice Hall, Mexico. 2010 Martin Sierra, Antonio. PROGRAMADOR CERTIFICADO JAVA 2. CURSO PRACTICO 3th Edition, Edit. Alfaomega, Mexico. 2010

85

Miguel Gracia, Luis. Java EE 5 Performance Management and Optimization. Edit. Steven Anglin, Mexico. 2010

Referencias de internet:

www.oracle.com ORACLE. 2011 Oracle | Hardware and Software, Engineered to Work Together. Disponible: http://www.oracle.com/index.html [Consulta: 2011, 30 de Marzo] www.oracle.com. ORACLE. 2011 Java SE Downloads Disponible: http://www.oracle.com/technetwork/java/javase/downloads/index.html [Consulta: 2011, 30 de Marzo] netbeans.org. NETBEANS. Netbeans ide. 2011. Disponible: http://netbeans.org/downloads/index.html [Consulta: 2011, 30 de Marzo] (http://alarcos.inf-cr.uclm.es/doc/ISOFTWAREI/Tema04.pdf). (http://www.ibm.com/developerworks/rational/library/content/03July/1000/1251/125 1_bestpractices_TP026B.pdf) http://es.kioskea.net/contents/genie-logiciel/cycle-de-vie.php3 http://es.wikipedia.org/wiki/Programaci%C3%B3n_orientada_a_objetos http://www.mastermagazine.info/termino/4544.php http://office.microsoft.com/es-hn/access-help/interacciones-entre-los-diagramas-debase-de-datos-las-ventanas-de-diseno-de-tabla-y-la-base-de-datos-adpHP003083899.aspx http://www.java.com/es/download/index.jsp http://definicion.de/java/ http://www.mitecnologico.com/Main/ElModeloDesarrolloConcurrente http://code.google.com/intl/es-MX/webtoolkit/doc/latest/tutorial/ http://en.wikipedia.org/wiki/Hibernate_(Java) http://www.docirs.cl/uml.htm http://tomcat.apache.org/ http://www.masadelante.com/faqs/servidor http://es.kioskea.net/contents/cs/cs3tier.php3 http://es.wikipedia.org/wiki/JavaServer_Pages http://www.aves.edu.co/ovaunicor/recursos/1/index_Arquitectura_de_software.pdf

86

GLOSARIO
Address (direccin). - Informacin que contiene un mensaje de correo electrnico y que determina el lugar al que debe enviarse dicho mensaje y el modo de hacerlo. Las direcciones se encuentran tanto en los encabezados de los mensajes como en los sobres. Las direcciones de los sobres determinan el modo de enrutar y entregar los mensajes. La funcin de las direcciones de los encabezados es meramente visual. Alerta.- Mensajes urgentes que reciben los usuarios de forma instantnea mediante una ventana emergente. El remitente sabe quin ha recibido el mensaje y, cuando la alerta se cierra o se hace clic sobre ella, recibe una notificacin de que se ha ledo el mensaje; siempre y cuando se utilice la opcin Mostrar estado del mensaje. En caso de que el mensaje de alerta requiera respuesta, se debe hacer clic con el botn secundario del ratn en la alerta para ver un men contextual donde hay una opcin para charlar con el remitente. API.- (Interfaz de programacin de aplicaciones). Conjunto de instrucciones que un programa informtico puede utilizar para comunicarse con otro software o hardware diseado para interpretar dicha API. Conjunto de convenciones o instrucciones de llamada que define el modo en que los programas solicitan servicios en paquetes de software existentes.

87

Applet container (contenedor de applets).- Contenedor que incluye compatibilidad con el modelo de programacin de applets. Arquitectura.- Diseo que muestra los bloques de construccin fsica y lgica de una aplicacin distribuida (u otro sistema de software) y las relaciones que se establecen entre s. En el caso de una distributed enterprise application (aplicacin empresarial distribuida), el diseo de arquitectura incluye generalmente la logical architecture (arquitectura lgica) y la deployment architecture (arquitectura de implementacin) de la aplicacin. Atributo.- Par nombre-valor que se encuentra en un objeto de solicitud y que puede establecerse mediante un servlet. Asimismo, un par nombre-valor predefinido en un archivo DTD que modifica un elemento en un archivo XML. Contraste con propiedad. Consulte tambin parmetro. En general, un atributo es una unidad de metadatos. Par nombre-valor que contiene informacin descriptiva sobre una entrada. Los atributos tienen un tipo (nombre) y un conjunto de valores. Un tipo de atributo especifica adems la sintaxis del tipo de informacin que puede almacenarse como valores de atributos de dicho tipo. Cach.- Copia de datos originales que se almacena de forma local. Los datos almacenados en la memoria cach no tienen que ser recuperados de un servidor remoto cuando se solicitan. Callable statement (instruccin llamable).- Clase que encapsula una llamada de procedimiento o funcin de base de datos para las bases de datos que permiten devolver conjuntos de resultados de los procedimientos almacenados. Componente.- Uno de los system component (componente del sistema) s incluidos en Java Enterprise System. Unidad de lgica de software desde la que se crean aplicaciones distribuidas. Un componente de aplicacin se desarrolla de forma personalizada y normalmente se adhiere a un modelo de componente distribuido (como por ejemplo CORBA y la plataforma J2EE) y realiza algunas funciones informticas especficas. Estos componentes, ya sea de forma individual o combinada, proporcionan business service (servicio empresarial)s y pueden encapsularse como web service (servicio web) s. Conexin .- En el caso de un resource manager (administrador de recursos), objeto que representa una sesin con un administrador de recursos. Conexin activa a servidor de mensajes de Java Enterprise System. Puede tratarse de una conexin de colas o una conexin de tema. Contenedor.- Proporciona servicios de administracin del ciclo de vida, de seguridad, implementacin y tiempo de ejecucin a un tipo especfico de componente de J2EE. El servidor de

88

aplicaciones (Application Server) proporciona contenedores para todos los tipos de componentes de J2EE. Consulte tambin componente. En Java Enterprise System Portal Server 6.0, un contenedor es un canal que genera principalmente su contenido agregando el contenido de sus canales secundarios. En Java Enterprise System Directory Server Access Management Edition, un contenedor define un tipo de objeto de organizacin que puede contener otros objetos de Directory Server Access Management Edition. Controlador.- Componente conector de Identity Synchronization para Windows que acta de interfaz con los componentes agente y de acceso. El controlador realiza las principales tareas relacionadas con la sincronizacin, como por ejemplo la determinacin de la pertenencia de un usuario a una Lista de usuarios de sincronizacin, la bsqueda y el enlace de entradas de usuario equivalentes y la deteccin de los cambios realizados en usuarios mediante la comparacin de las entradas de usuario actuales con las versiones anteriores almacenadas en la memoria del objeto. Suele hacerse referencia al controlador en los mensajes de registro acerca de una accin. CSS.- (Hoja de estilo en cascada). Hoja de estilo utilizada con documentos HTML y XML para agregar un estilo a todos los elementos marcados con una etiqueta determinada, para la direccin de los navegadores u otros mecanismos de presentacin. Database (base de datos).- Trmino genrico que se utiliza para designar el sistema de administracin de bases de datos relacionales (RDBMS, del ingls). Paquete de software que permite crear y manipular grandes cantidades de datos relacionados y organizados. Consulte tambin schema (esquema). Database connection (conexin a base de datos).- Vnculo de comunicacin con una base de datos u otra fuente de datos. Los componentes pueden crear y manipular varias conexiones a bases de datos a la vez para acceder a los datos. Data service (servicio de datos).- Servicio web que admite la consulta y modificacin de los datos relacionados con un usuario final. Un ejemplo de servicio de datos es un servicio web que aloja y expone la informacin del perfil del usuario como, por ejemplo, el nombre, la direccin y el nmero de telfono. FTP.- (Protocolo de transferencia de archivos) Protocolo de Internet que permite transferir archivos de un equipo a otro a travs de una red. HTML.- (Lenguaje de marcador de hipertexto) Lenguaje de marcado para documentos de hipertexto en Internet. HTML permite la integracin de imgenes, sonidos, emisiones de vdeo,

89

campos de formulario, referencias a otros objetos con URL y formato de texto bsico. Cada bloque de texto est rodeado de cdigos que indican la naturaleza del texto. HTML page (pgina HTML).- Pgina codificada en HTML cuyo fin es ser mostrada en un navegador web. IDE.- (Entorno de desarrollo integrado) Software que permite crear, ensamblar, implementar y depurar cdigo desde una nica interfaz grfica de usuario. Installation path (ruta de instalacin).- La ruta completa de instalacin de Directory Server Enterprise Edition . Al instalar el software por primera vez puede elegir la ruta de instalacin. J2EE platform (plataforma J2EE).- (Java 2 Platform, Enterprise Edition) Entorno para desarrollar e implementar aplicaciones empresariales basadas en web y con varias capas. La plataforma J2EE consiste en un conjunto de servicios, API y protocolos que proporcionan las funciones necesarias para desarrollar estas aplicaciones. J2ME platform (plataforma J2ME).- (Java 2 Platform, Micro Edition) Entorno de tiempo de ejecucin Java altamente optimizado destinado a una amplia gama de productos de consumo, entre los que se incluyen localizadores, telfonos mviles, videotelfonos, decodificadores digitales y sistemas de navegacin de automvil. J2SE platform (plataforma J2SE).- (Java 2 Platform, Standard Edition) La principal plataforma de tecnologa Java. JDBC resource (recurso JDBC).- Recurso que se utiliza para conectar una aplicacin que se est ejecutando con el servidor de aplicacin a una base de datos mediante un conjunto de conexiones JDBC. Se compone de un nombre de Java Naming and Directory Interface (JNDI) (que utiliza la aplicacin) y el nombre de un conjunto de conexiones JDBC existente. JSP page (pgina JSP).- Documento basado en texto que contiene texto esttico y elementos JSP que describe cmo procesar una solicitud para crear una respuesta. Una pgina JSP se traduce y maneja solicitudes tales como un servlet. Normalizacin.- Proceso de supresin de redundancia mediante la modularizacin, como con subrutinas, y de supresin de diferencias superfluas mediante la reduccin a un denominador comn. Por ejemplo, los finales de lnea de diferentes sistemas se normalizan mediante la reduccin de los mismos a una nica lnea nueva, mientras que varios caracteres de espacio en blanco se normalizan a un espacio.

90

Paquete.- Conjunto de archivos y directorios. El paquete es un mtodo de distribucin de software para la instalacin. Parmetro.- Par nombre-valor enviado por el cliente de Java Enterprise System Application Server, incluidos los datos del campo de formulario, informacin del encabezado HTTP, entre otros elementos, y encapsulado en un objeto de solicitud. Argumento a un mtodo de Java o un comando preparado para base de datos. Persistencia.- Para componentes, el protocolo de transferencia del estado entre las variables de la instancia y la base de datos subyacente. Consulte entity bean (bean de entidad). Para sesiones, el mecanismo de almacenamiento de la sesin. Consulte tambin sesin, failover (conmutacin por error), session failover (conmutacin por error de sesin). Plug-in (complemento).- Extensin de cdigo para el navegador que muestra o ejecuta el contenido de una pgina web. Los complementos permiten al navegador mostrar los elementos de contenido de la pgina que el navegador no sera capaz de mostrar por s solo. Servlet.- Programa de servidor escrito en el lenguaje de programacin Java que ampla la funcionalidad de un servidor web, generando contenido dinmico e interactuando con aplicaciones web utilizando el paradigma solicitud-respuesta. Los servlets son parecidos a los applets en el sentido de que se ejecutan en el servidor. Sin embargo, los servlets no utilizan una interfaz de usuario. SQL.- (lenguaje de consulta estructurado) (n.) Lenguaje de base de datos relacional estandarizada para la definicin de objetos de la base y la manipulacin de datos. SQL2 y SQL3 hacen referencia a versiones del lenguaje.

91

ANEXOS
Cdigo Principal - Celular package Principal; import javax.microedition.midlet.*; import javax.microedition.lcdui.*; public class VisualMIDlet extends MIDlet { private boolean midletPaused = false; private Form form; private ChoiceGroup choiceGroup; public VisualMIDlet() { } private void initialize() { } public void startMIDlet() { } public void resumeMIDlet() { } public void switchDisplayable(Alert alert, Displayable nextDisplayable) { Display display = getDisplay(); if (alert == null) { display.setCurrent(nextDisplayable); } else { display.setCurrent(alert, nextDisplayable); } } public Form getForm() { if (form == null) { form = new Form("form", new Item[] { getChoiceGroup() }); } return form; } public ChoiceGroup getChoiceGroup() { if (choiceGroup == null) { choiceGroup = new ChoiceGroup("Estatus", Choice.EXCLUSIVE); choiceGroup.append("Abierto", null); choiceGroup.append("Pendiente", null); choiceGroup.append("Resuelto", null); choiceGroup.append("Cerrar", null); choiceGroup.setSelectedFlags(new boolean[] { true, false, false, false }); }

92

return choiceGroup; } public Display getDisplay () { return Display.getDisplay(this); } public void exitMIDlet() { switchDisplayable (null, null); destroyApp(true); notifyDestroyed(); } public void startApp() { if (midletPaused) { resumeMIDlet (); } else { initialize (); startMIDlet (); } midletPaused = false; } public void pauseApp() { midletPaused = true; } public void destroyApp(boolean unconditional) { } } Cdigo - Pantalla Login package Principal; import java.util.Hashtable; import javax.microedition.midlet.*; import javax.microedition.lcdui.*; import org.netbeans.microedition.lcdui.LoginScreen; public class MIDletLoginAjustador extends MIDlet implements CommandListener{ private boolean midletPaused = false; private final String URL = "http://localhost:8084/ServidorCelular"; private FrmReporteSiniestroAjustador frmReporteSiniestroAjustador; private FrmSiniestrosAsignados frmSiniestrosAsignados; private LoginScreen loginScreen; public FrmSiniestrosAsignados getFrmSiniestrosAsignados() { if(this.frmSiniestrosAsignados==null){ this.frmSiniestrosAsignados= new FrmSiniestrosAsignados("Siniestro asignado", this); this.frmSiniestrosAsignados.setCommandListener(this); } return frmSiniestrosAsignados; }

93

public FrmReporteSiniestroAjustador getFrmReporteSiniestroAjustador() { if(this.frmReporteSiniestroAjustador==null){ this.frmReporteSiniestroAjustador=new FrmReporteSiniestroAjustador("Reportar siniestro", this); this.frmReporteSiniestroAjustador.setCommandListener(this); } return frmReporteSiniestroAjustador; } public MIDletLoginAjustador() { } private void initialize() { } public void startMIDlet() { this.switchDisplayable(null, getLoginScreen()); } public void resumeMIDlet() { } public void switchDisplayable(Alert alert, Displayable nextDisplayable) { Display display = getDisplay(); if (alert == null) { display.setCurrent(nextDisplayable); } else { display.setCurrent(alert, nextDisplayable); } } public Display getDisplay () { return Display.getDisplay(this); } public void exitMIDlet() { switchDisplayable (null, null); destroyApp(true); notifyDestroyed(); } public void startApp() { if (midletPaused) { resumeMIDlet (); } else { initialize (); startMIDlet (); } midletPaused = false; } public void pauseApp() { midletPaused = true; } public void destroyApp(boolean unconditional) { }

94

public String getEstadoStr(){ return String.valueOf(this.getFrmReporteSiniestroAjustador().getChoiceGroup().getSelectedIndex()+1); } public void enviar() { Hashtable params = new Hashtable(); params.put("folio", "240"); params.put("descripcion", this.getFrmReporteSiniestroAjustador().getTxtDescripcion().getString()); params.put("estado",this.getEstadoStr()); try { Comunicacion req = new Comunicacion( URL+"/DatosAjustador", params); req.setEstadoConeccion(new EstadoConeccion() { public void ResultadoEnvioDatos(boolean ok, String resp) { Alert alertaEnvio; if(!(ok && resp.equals("OK"))){ alertaEnvio= new Alert("Fallo el envio","No de pudo enviar los datos",null,AlertType.ERROR); MIDletLoginAjustador.this.switchDisplayable(alertaEnvio,MIDletLoginAjustador.this.g etFrmReporteSiniestroAjustador()); } else{ alertaEnvio= new Alert("Envio exitoso","Los datos se enviaron correctamente",null,AlertType.CONFIRMATION); MIDletLoginAjustador.this.switchDisplayable(alertaEnvio,MIDletLoginAjustador.this.g etFrmReporteSiniestroAjustador()); } } }); req.Enviar(); } catch (Exception e) { } } public LoginScreen getLoginScreen() { if (loginScreen == null) { loginScreen = new LoginScreen(getDisplay()); loginScreen.setLabelTexts("Usuario", "Password"); loginScreen.setTitle("Login"); loginScreen.addCommand(LoginScreen.LOGIN_COMMAND); loginScreen.setCommandListener(this); loginScreen.setBGColor(-3355444); loginScreen.setFGColor(0); loginScreen.setUseLoginButton(false); loginScreen.setLoginButtonText("Login"); } return loginScreen; } public void login(){ ;

95

Hashtable params = new Hashtable(); params.put("user", this.loginScreen.getUsername()); params.put("pass", this.loginScreen.getPassword()); try { Comunicacion req = new Comunicacion( URL+"/LoginAjustador", params); req.setEstadoConeccion(new EstadoConeccion() { public void ResultadoEnvioDatos(boolean ok,String resp) { Alert alertaEnvio; if(!(ok && resp.equals("OK"))){ alertaEnvio= new Alert("Login","No se pudo iniciar secion",null,AlertType.ERROR); MIDletLoginAjustador.this.switchDisplayable(alertaEnvio,MIDletLoginAjustador.this.l oginScreen); } else{ MIDletLoginAjustador.this.switchDisplayable(null, MIDletLoginAjustador.this.getFrmSiniestrosAsignados()); } } }); req.Enviar(); } catch (Exception e) { ; } } public void commandAction(Command command, Displayable displayable) { if (displayable == loginScreen) { if (command == LoginScreen.LOGIN_COMMAND) { this.login(); } } else if(displayable == this.getFrmSiniestrosAsignados()){ if(command == this.getFrmSiniestrosAsignados().getBtnActualizarReporte()){ this.actualizaReport(); } else if(command == this.getFrmSiniestrosAsignados().getBtnSalir()){ this.exitMIDlet(); } } else if(displayable == this.getFrmReporteSiniestroAjustador()){ if(command == this.getFrmReporteSiniestroAjustador().getBtnEnviar()){ this.enviar(); } else if(command == this.getFrmReporteSiniestroAjustador().getBtnCancelar()){ this.switchDisplayable(null, this.getFrmSiniestrosAsignados()); } } } private void actualizaReport() { this.switchDisplayable(null, this.getFrmReporteSiniestroAjustador()); }

96

Cdigo Comunicacin

package Principal; import java.io.ByteArrayOutputStream; import java.io.IOException; import java.io.InputStream; import java.io.OutputStream; import java.util.Enumeration; import java.util.Hashtable; import javax.microedition.io.Connector; import javax.microedition.io.HttpConnection; import javax.microedition.lcdui.Display; public class Comunicacion implements Runnable{ private Thread t; private String respuesta; private HttpConnection c; private Hashtable params; private EstadoConeccion estadoConeccion; private String url; public Comunicacion(String url,Hashtable params) { respuesta = null; this.params=params; this.url=url; } public void run(){ HttpConnection httpConn = null; InputStream is = null; OutputStream os = null; boolean ok=false; try { httpConn = (HttpConnection)Connector.open(url); httpConn.setRequestMethod(HttpConnection.POST); httpConn.setRequestProperty("User-Agent", "Profile/MIDP-1.0 Confirguration/CLDC-1.0"); httpConn.setRequestProperty("Accept_Language","en-US"); httpConn.setRequestProperty("Content-Type", "application/x-www-form-urlencoded"); os = httpConn.openOutputStream(); String paramsStr=""; Enumeration keys = params.keys(); while (keys.hasMoreElements()) { String key = (String) keys.nextElement(); String value = (String) params.get(key); paramsStr+=key+"="+value+"&"; } os.write(paramsStr.getBytes());

97

StringBuffer sb = new StringBuffer(); is = httpConn.openDataInputStream(); int chr; while ((chr = is.read()) != -1) sb.append((char) chr); respuesta=sb.toString(); ok=true; } catch(Exception ex){ ok=false; } finally { try{ if(is!= null) is.close(); if(os != null) os.close(); if(httpConn != null) httpConn.close(); } catch(IOException ex){ ok=false; } finally{ if (this.estadoConeccion != null) { this.estadoConeccion.ResultadoEnvioDatos(ok,respuesta); } } } } public void setEstadoConeccion(EstadoConeccion estadoConeccion) { this.estadoConeccion=estadoConeccion; } public void Enviar() { t = new Thread(this); t.start(); } }

98