Capítulo II Fundamentos Teóricos

Transcripción

1 Capítulo II Fundamentos Teóricos 2.1 Antecedentes En el ámbito internacional, Abuyang (2007), en su tesis de maestría de la Universidad Radboud Nijmegen en los Países Bajos, desarrolló un proyecto titulado Banca Móvil en países en Desarrollo: Un framework seguro para la entrega de servicios de banca SMS. Luego de investigar y analizar propuso un prototipo de implementación que toma en cuenta los problemas de seguridad encontrados luego de indagar en la situación actual. Utilizó Java como lenguaje de programación bajo el estándar J2ME gracias al alto porcentaje de teléfonos móviles que vienen con una máquina virtual de java predeterminada. Presentó un modelo seguro para servicios de banca móvil SMS capaz, adaptable para los usuarios de teléfonos celulares. Este antecedente se relaciona con el presente trabajo de aplicación profesional, debido a que se desarrolló una herramienta para proporcionar servicios de banca a los usuarios de una determinada institución bancaria, tomando en cuenta el importante nivel de usuarios que poseen dispositivos móviles con una máquina virtual de Java incorporada que soportan este tipo de aplicaciones. Gandica (2009), realizó un trabajo de aplicación profesional en la Universidad Nacional Experimental del Táchira denominado Aplicación para Dispositivos Móviles orientada a la recolección y procesamiento de datos socioeconómicos. Este trabajo consistió en el desarrollo de una aplicación para la ejecución de encuestas haciendo uso de dispositivos móviles, con la finalidad de optimizar factores como resultados, confianza y veracidad, entre otros, ahorrando tiempo, dinero y esfuerzo sin dañar el medio ambiente. Utilizó como metodología de desarrollo Scrum, UML como herramienta de modelado, Java como lenguaje de programación, Java ME como plataforma de desarrollo y

2 Netbeans como IDE. Como resultado se presentó una aplicación capaz de recolectar y procesar los datos obtenidos en encuestas móviles inteligentes alojadas en dispositivos móviles. El trabajo realizado por Gandica (2009), se considera como un antecedente importante para esta investigación porque consistió en el desarrollo de una aplicación para dispositivos móviles, utilizando Java como lenguaje de programación. Así mismo, fue desarrollado utilizando la metodología Scrum para el desarrollo de Software, metodología seleccionada para el desarrollo de éste trabajo. Sánchez y Oviedo (2006), en su proyecto Desarrollo de perfiles para dispositivos móviles para la migración de datos a una Grid, en la Universidad Nacional Experimental del Táchira, contemplaron el desarrollo de perfiles para dispositivos móviles para la migración de datos a una Grid, que permite la conexión ente un servidor de servicios Web y un cliente J2ME a través de un Proxy y un cliente java, permitiendo resolver diversos tipos de problemas a través de los servicios Web. El desarrollo de este trabajo siguió la metodología del modelo en espiral la cual permite dirigir y evaluar el desempeño en cada una de las etapas del proyecto. Dando continuidad al trabajo de investigación recién mencionado, Ramírez y Zambrano (2007), en la Universidad Nacional Experimental del Táchira, desarrollaron un proyecto denominado Agente para la Comunicación entre Dispositivos Móviles y la Grid, con el fin de lograr que los usuarios de dichos dispositivos puedan tener acceso a los diferentes recursos que posee una Grid, aumentando de esta manera las capacidades que dichos equipos poseen. Adoptaron la metodología de desarrollo en espiral y al culminar la implementación del agente, se evaluó su funcionalidad efectuando pruebas de integración Agente-Grid. El trabajo realizado por Sanchez y Oviedo (2006) que posteriormente fue punto de partida para Ramírez y Zambrano (2007), se encuentran entre los

3 primeros desarrollos orientados a los dispositivos móviles llevados a cabo en la Universidad Nacional Experimental del Táchira. 2.2 Bases Teóricas INFINIX Suite INFINIX Suite, es una solución multicanal desarrollada en lenguaje de programación Java sobre la plataforma J2EE, orientada a soportar los diferentes canales de distribución de las instituciones financieras, tales como agencias bancarias, oficinas, sucursales bancarias, Internet banking, call centers, ATM, kioscos y terminales móviles entre otros, integrando todos ellos entre sí en conjunto con los diversos sistemas empresariales con los que cuente una institución, utilizando un esquema centralizado. Figura 2: Arquitectura de INFINIX Suite Fuente: WINCOR NIXDORF C.A. INFINIX Suite tiene una arquitectura net-centric, cada una de sus capas está descrita de la siguiente manera:

4 - Presentation Layer: Es el punto de entrada a los servicios de la aplicación de cara al usuario o a un sistema externo. En un primer nivel representa la transformación de las solicitudes recibidas desde un dispositivo externo al mecanismo utilizado internamente por el sistema, ofreciendo un acceso homogéneo que independiza a la capa de deployment y businesslogic de las particularidades asociadas a los diferentes dispositivos que actúan como clientes del sistema. A su vez, esta capa representa las interfaces de usuario necesarias para acceder a los servicios publicitados y los mecanismos de acceso a la aplicación por otros sistemas. - Deployment Layer: Esta capa actúa como la puerta de entrada a los servicios ofrecidos por la lógica de negocio. Actúa como una fachada de la lógica de negocio donde se publican las funcionalidades ofrecidas a la capa de presentación. Esta capa, principalmente tecnológica, condiciona la forma en que los servicios son invocados desde la capa de presentación. - Business Logic Layer: Implementa la lógica de negocio de la aplicación, alberga los componentes que combinan las reglas de negocio y los datos. Los elementos en esta capa modelan los objetos y procesos de negocios interactuando con las capas inferiores para la obtención o persistencia de datos o para la solicitud de servicios a otros sistemas que formen parte del proceso de negocio. Esta capa está definida para ser independiente de la tecnología utilizada en la capa de deployment de forma de buscar su máxima reusabilidad y flexibilidad. - Data Access Layer: Esta capa abstrae a la aplicación del acceso a diferentes mecanismos de persistencia de datos. Cumplen la función de conocer la forma de interactuar con el mecanismo de persistencia y

5 transformar los datos obtenidos a un Value Object que pueda ser transportado y manipulado dentro de los procesos de la lógica de negocio o presentado al usuario o sistema externo. - Value Object Layer: Esta capa define los objetos que transportan los datos entre las diferentes capas y componentes que conforma el sistema. Todo el intercambio de información entre las diferentes capas que definen la aplicación y los componentes que la conforman se realizará utilizando Value Object (también denominados Data Transfers Objects ). Los objetos en esta capa están orientados a encapsular grupos de datos necesarios para realizar un proceso de negocio de forma de transportarlos a lo largo de la aplicación como un único elemento, aportando a su vez funcionalidad específica a lo largo de la arquitectura. - Arquitectura Component Layer: Esta capa ofrece al sistema un conjunto de componentes que simplifican diferentes necesidades dentro de la aplicación. En esta capa se encuentran componentes comunes que por su comportamiento o complejidad tiende a ser elementos reutilizables e independientes de la lógica de negocio y por ellos requieren ser diseñados e implementados de forma independiente. A su vez, los elementos aquí contenidos condicionan el desarrollo, debido a que es en ellos donde se define la forma de interacción entre las diferentes capas, así como la forma de interacción entre INFINIX y elementos externos al sistema, tales como base de datos o sistemas externos. Por otro lado, también da soporte a diferentes mecanismos ampliamente utilizados en el sistema buscando una mayor eficiencia y abstracción para el resto del sistema.

6 El principal propósito de INFINIX Suite es alinearse con el negocio, es decir, ser una solución orientada al ROI (Retorno de la Inversión), incrementando ventas y reduciendo costos, implementando las principales operaciones que los sistemas bancarios necesitan: - Tracing y Logging - Diario electrónico del sistema - Autorizaciones remotas - Seguridad (autenticación, autorización y permisos) - Manejo de dispositivos financieros - Generación de reportes (PDF, Excel entre otros) Robusto y Escalable Enfoque CRM & Multicanal Arquitectura Multicanal Modular & Flexible Estrategia CRM Multicanal Tecnología Correcta Solución Bancaria Flexible Multicanal Estrategia de Negocios Correcta CRM Ventaja Competitiva Capaz de alinearse a los requerimientos del negocio Capaz de responder a las necesidades cambiantes del negocio - Manejo de imágenes digitales (firmas, fotografías ente otros) Figura 3. Estrategia bancaria CRM (relación con el cliente multicanal) Fuente: WINCOR NIXDORF C.A.

7 Dispositivo Móvil Inteligente (Smartphone) La definición de Smartphone no está estandarizada y varía dependiendo de a quien se le pregunte. Para la mayoría de los usuarios, un Smartphone es un dispositivo móvil que ofrece más capacidades que un teléfono celular típico. Versiones modernas incluyen funcionalidades similares a un computador personal. La mayoría de los modelos más nuevos han desarrollado sistemas operativos y software asociado que provee una interfaz estándar. Casi todos los Smartphone tienen características avanzadas como correo electrónico, acceso a Internet, mensajería instantánea, sincronización con computadoras de escritorio etc. Estos dispositivos permiten acceso instantáneo a la Web, lo que se traduce en capacidad de colaboración inmediata. Rittinghouse y Ransom (2010). Firtman (2010), expone que los Smartphones son definidos en la actualidad como dispositivos con características como sistema operativo multitareas, un navegador de escritorio, redes inalámbricas LAN o WAN conocidas como WiFi y conexiones 3G, reproducción de música y algunas de las mencionadas a continuación: - GPS Sistema de Posicionamiento Global o A-GPS Sistema de Posicionamiento Global Asistido) - Brújula digital - Cámara con capacidad de grabar video - Salida de TV - Bluetooth - Sensibilidad al tacto - Aceleración de video 3D - Acelerómetro -

8 BlackBerry BlackBerry es una línea de productos de la empresa canadiense RIM (Research in Motion) que incluye tablets, dispositivos móviles inteligentes, software para negocios y accesorios lanzada al mercado en Java Desarrollado por Sun Microsystems a principios de los años 90, Java es un lenguaje de programación creado por inicialmente por un equipo de 13 personas, guiado por James Gosling en una operación denominada The Green Proyect. La promesa inicial era Write One Run Anywhere (Escríbelo una vez, ejecútalo en cualquier lugar), proporcionando así un lenguaje independiente de la plataforma y un entorno de ejecución ligero y gratuito. Es un lenguaje de programación de propósito general, concurrente, basado en clases y orientado a objetos. Está diseñado lo suficientemente simple para que los programadores adquieran destreza en el lenguaje. Está relacionado con C y C++ pero está organizado de forma diferente, con algunos aspectos de estos lenguajes omitidos y algunas otras ideas de otros lenguajes incluidas. Pretende ser un lenguaje de producción, no de investigación (Gosling, Joy, Steele y Bracha, 2005). Posee una Máquina Virtual de Java (JVM), ejecutable en una plataforma específica que es capaz de interpretar y ejecutar instrucciones expresadas en Java bytecode, generadas por el compilador del lenguaje JAVA. La JVM está situada en un nivel superior de Hardware, y es capaz de entender tanto el bytecode como el sistema sobre el que se pretende ejecutar, por tanto, es capaz de convertir el lenguaje generado por el compilador de Java en el lenguaje nativo del dispositivo final.

9 Java Micro Edition (JME) JME es una plataforma de Java diseñada por Sun Microsystems, ahora subsidiaria de Oracle, en reemplazo la similar Personal Java, licenciado por el General Public License (GNU) en el año Es una colección de tecnologías y especificaciones que se ajustan a los requerimientos de dispositivos móviles, que pueden ser combinadas para la creación de un Java Runtime Environment específico para alcanzar los requerimientos de algún dispositivo particular en el mercado. La plataforma Java ME sido dividida a lo largo del tiempo en dos configuraciones, una para dispositivos móviles pequeños conocida como Connectec Limited Device Configuración (CLDC) y otra llamada Connected Device Cofniguration (CDC) para otros dispositivos móviles con mayor capacidad como Smartphones y codificadores de señal de televisión (Oracle, 2011). BlackBerry Java SDK 6.0 Es un equipo de herramientas de desarrollo de software de Java que permite incluir características del sistema operativo 6 de BlackBerry en las aplicaciones. Incluye mejoras en las APIs del Explorador BlackBerry, elementos de interfaz de usuario prefabricados, localización geográfica mediante WiFi y tiempo de viaje (RIM, 2011). BlackBerry MDS Simulator Es un simulador de prueba que permite simular conectividad a redes y la funcionalidad proporcionada por BlackBerry Enterprise Server (RIM, 2011). Entorno de Desarrollo Integrado (IDE) Mejor conocido por su nombre en inglés Integrated Development Environment, es un conjunto de herramientas que soporta el desarrollo de aplicaciones. La mayoría de los IDEs proporcionan instrumentos que permiten

10 escribir y editar código fuente, visualizar errores en código mientras se escribe, automatizar tareas repetitivas, compilar código entre otras. (Oracle, 2011) El desarrollo de los IDE está destinado a maximizar la productividad de los desarrolladores de software, mediante un entorno de programación presentado como una aplicación. Entre los más conocidos se pueden destacar: NetBeans, JDeveloper, Eclipse, Delphi y C++Builder. BlackBerry Java plug-in for Eclipse Es un complemento de Java para Eclipse que mejora la productividad del desarrollo mediante un desarrollo específico de BlackBerry integrado, depuración y simulación. La versión 1.3 del complemento utilizada para el desarrollo de este proyecto, aumenta la productividad integrando las características y ofertas de ahorro de tiempo de Eclipse Helios 3.6 con la Perspectiva de Desarrollo BlackBerry de Eclipse que organiza las vistas de desarrollo y menús de fácil acceso.

11 Figura 4.Entorno BlackBerry java plug-in for eclipse Fuente: propia. BlackBerry Torch 9800 Simulator Es un simulador que permite cargar las aplicaciones desarrolladas en java para dispositivos móviles BlackBerry. Permite visualizar el funcionamiento de la aplicación mediante una interfaz que simula el sistema operativo 6 de BlackBerry (RIM, 2011). Figura 5. BlackBerry 9800 Simulator Fuente: Propia Desarrollo ágil En el ámbito del desarrollo de software, recientemente han surgido nuevos paradigmas basados en metodologías y procesos catalogados como ágiles. Schuh (2005), expone el desarrollo ágil, como un método de desarrollo de software que delega funciones a las demás personas y tiene confianza, reconociendo el cambio como norma y promoviendo constante retroalimentación.

12 Beck et al (2011), resumieron los valores detrás del desarrollo ágil en el Manifiesto por el Desarrollo Ágil de Software de la siguiente manera: - Individuos e interacciones sobre procesos y herramientas - Software funcionando sobre documentación extensiva - Colaboración con el cliente sobre negociación contractual - Respuesta ante el cambio sobre seguir un plan Scrum Es una metodología de desarrollo de software cuya concepción es relativamente reciente. Su nombre, en español melé, proviene de la analogía con una posición del deporte rugby, que consiste en el trabajo en equipo como un solo hombre por un fin común. Ésta metodología tiene como horizonte, elaborar pequeños prototipos funcionales que puedan ser revisados en el menor tiempo posible y al menor costo. Scrum entra dentro de las metodologías que se pueden clasificar como ágiles y es definida por Schuh (2005) como: un cambio en los paradigmas tradicionales de los proyectos sobre cómo organizar el trabajo, aplicar talentos, incluir al cliente, y generar calidad a todos los beneficiarios del proyecto(p. 267). Schwaber (2004), que forma parte del grupo conocido como la Alianza Ágil que participó en la creación del Manifiesto por el Desarrollo Ágil de Software, afirma que el corazón de Scrum son las iteraciones. El equipo de trabajo revisa los requerimientos, y luego selecciona cuales de estos consideran que pueden transformarse en un incremento funcional, potencial y entregable al final de cada iteración. Scrum maneja distintos factores que intervienen dentro del proceso de desarrollo de cada iteración, estos son, roles, flujos y los denominados artefactos. Schwaber (2004), define estos factores de la siguiente manera: - Roles: Existen tres (3) roles Scrum, denominados por Schwaber como cerdos o gallinas según el grado de compromiso con el proyecto. El

13 Product Owner es responsable de representar los intereses de todos los que estén involucrados en el proyecto y el sistema resultante. Es quien marca o define cuales serán los requerimientos, los objetivos de retorno de inversión (ROI) y los planes de entrega. El Team o equipo, es el responsable de desarrollar la funcionalidad. Estos equipos se encargan de gestionarse y organizarse e intercambiar funciones entre ellos mismos, para encontrar la manera de tener el mayor éxito posible en la iteración. Por último, el Scrum Master es el responsable del proceso de Scrum, de enseñar ésta metodología a todos los involucrados en el proyecto para su implementación y de asegurarse que siguiendo estas reglas, obtengan buenos resultados en el marco de la cultura de la organización. - Flujos: El proyecto comienza con una visión del sistema que se va a desarrollar, un poco vaga al principio y probablemente presentada en términos de mercadeo y no en términos de sistema. El Product Owner realiza un plan que incluye un Product Backlog, una lista de requerimientos funcionales y no funcionales que definen la visión que se quiere materializar. Todo el trabajo es realizado en Sprints, iteraciones de 30 días consecutivos aproximadamente. Cada Sprint inicia con una reunión de planificación del Sprint, Sprint Planning, donde el Product Owner y el Team definen cual será el alcance contemplado en el próximo Sprint y su duración no debe exceder las ocho (8) horas. El Sprint planning consta de dos (2) partes, en las primeras cuatro (4) horas está pautado que el Product Owner presente el Product Backlog con mayor prioridad al equipo. El Team aclara sus dudas respecto al contenido, propósito, significado e intenciones de dicho Product Backlog. Antes de finalizar este primer bloque de horas, el Team

14 luego de manejar la información suficiente selecciona qué tanto Product Backlog será capaz de entregar al final del Sprint. Durante el segundo bloque de cuatro (4) horas, se planea el Sprint, el equipo elabora un plan tentativo inicial y las taras de dicho plan pasan a formar parte del Sprint Backlog. Todos los días el equipo asiste a una reunión de Scrum llamada Daily Scrum. En cada reunión los miembros del equipo responden estas tres (3) preguntas: Qué has hecho en el proyecto desde el último DailyScrum? Qué planeas hacer en el proyecto entre éste y el próximo DailyScrum? Qué impedimentos se interponen para que alcances el compromiso adquirido para este Sprint y el proyecto? Al final de cada Sprint, una revisión de Sprint o Sprint Review es sostenida. Es una reunión de cuatro (4) horas en las que el Team presenta al Product Owner o cualquier otro stakeholder o involucrado que desee asistir, qué tanto se desarrolló durante el Sprint. Antes de comenzar la próxima reunión de Sprint Planning, el Scrum Master hace una reunión de retrospectiva Sprint con el equipo, para animarlos a que revisen el proceso de desarrollo para hacerlo más efectivo y cómodo para el próximo Sprint. - Artefactos: El Product Backlog o Pila de Producto, lista los requerimientos del sistema o producto que serán desarrollados por el proyecto. El Product Owner se encarga de sus conceptos, prioritización y disponibilidad. Está sujeto a los cambios que puedan ocurrir a lo largo del desarrollo. El Sprint Backlog o Pila de Sprint, por su parte, define el trabajo o tareas que el Team define como transformar un Product Backlog seleccionado en un incremento funcional. El equipo plantea una lista inicial en el segundo bloque de horas de la reunión de Sprint Planning. El

15 Sprint Backlog es altamente visible, se puede decir que una fotografía en tiempo real del trabajo que el Team planea llevar a cabo en el Sprint. Figura 6. Metodología de desarrollo Scrum Fuente: fund-aprendizaje-tec.blogspot.com El Burndown Chart o Diagrama de Quemado, finalmente, busca plasmar en un gráfico la cantidad de trabajo pendiente a lo largo del tiempo. Es una excelente forma de visualizar la correlación entre el trabajo faltante en cualquier punto en el tiempo y el progreso del Team reduciendo el mismo. Desarrollo Guiado por Pruebas (TDD) TDD es una técnica de programación que consiste en desarrollar primero el código que pruebe una característica antes del código que implementa dicha funcionalidad. Fue probada en sus inicios en Programación Extrema, y su objetivo es lograr que no exista ninguna funcionalidad que no esté avalada por una prueba. Beck (2003), planteó esta metodología en su libro Test-driven development: by example, en español, Desarrollo guiado por pruebas: en ejemplo, y expuso la siguiente frase buscando resumir el por qué del uso de

16 esta metodología: divide y vencerás. Afirmó que primero se debe resolver la parte que funcione del problema y después la parte código limpio, llevando esto a su concepción del ciclo de TDD: - Escribir una prueba; pensar cómo debería plasmarse una operación en código. - Hacer que corra; buscar una solución simple que corra en el menor tiempo posible. - Hacerlo correctamente; remover las duplicaciones de código, hacer que el código este limpio. Figura 7. Desarrollo guiado por pruebas Fuente: Goodpasture (2009), tiene una concepción similar a la de Beck en cuanto al ciclo de TDD. Divide el mismo en pasos y los define de la siguiente manera: - Documentar los requerimientos de desarrollo con pruebas - Correr la prueba, realizando modificaciones hasta que el código pase la prueba. - Refinar los detalles de diseño. Otra forma de denominar a estas tres (3) etapas del ciclo TDD es mediante los colores rojo, verde y refactorizar (Blé et al, 2010). Lenguaje Unificado de Modelado (UML) Según Quatrani (2003), es un lenguaje que pretende estandarizar los elementos de análisis y diseño: modelos semánticos, notación sintáctica y diagramas. Complementando esta definición Fowler, Scott y Scott (1999),

17 definen UML como un lenguaje de modelado y no como un método; una notación (principalmente gráfica) de que se valen los métodos para expresar los diseños. Siendo UML actualmente un lenguaje de modelado estándar adoptado por el Object Management Group (OMG), es un lenguaje que ha tenido gran aceptación a nivel mundial y está siendo utilizado por grandes corporaciones de desarrollo de software para el desarrollo de aplicaciones en diferentes ámbitos. Proceso Unificado de Rational (RUP) Según Rumbaugh et al. (1999), RUP es un ejemplo de un modelo de proceso moderno que proviene del trabajo en el UML y el asociado Proceso Unificado de Desarrollo de Software. Es una metodología que captura muchas de las mejores prácticas modernas de desarrollo de software para adaptarse a una amplia gama de proyectos y organizaciones, siendo una guía para utilización de UML de forma efectiva. RUP describe buenas prácticas de la ingeniería del software que son aconsejables en el desarrollo de sistemas. Se recomiendan seis buenas prácticas fundamentales definidas por Sommerville (2005) de la siguiente manera: - Desarrolle software de forma iterativa. Planifique incrementos del sistema basado en las prioridades del usuario y desarrollo y entregue las características del sistema de más alta prioridad al inicio del proceso de desarrollo. - Gestione los requerimientos. Documente explícitamente los requerimientos del cliente y manténgase al cambio de estos requerimientos. Analice el impacto de los cambios en el sistema antes de aceptarlos. - Utilice arquitectura basadas en componentes. Estructure la arquitectura del sistema en componentes.

18 - Modele el software visualmente. Utilice modelos gráficos UML para presentar vistas estáticas y dinámicas del software. - Verifique la calidad del software. Asegure que el software cumple los estándares de calidad organizacionales. - Controle los cambios de software. Gestione los cambios de software usando un sistema de gestión de cambios y procedimientos y herramientas de gestión de configuraciones. El modelo de RUP está dividido en fases que según Sommerville (2005) están mucho más relacionadas con asuntos de negocio más que técnicos, las cuales se describe como sigue: - Inicio: el objetivo de la fase de inicio es el de establecer un caso de negocio para el sistema. Se deben identificar las entidades externas (personas y sistemas) que interactuaran con el sistema y definir estas interacciones. - Elaboración: los objetivos de la fase de elaboración son desarrollar una comprensión del dominio del problema, establecer un marco de trabajo arquitectónico para el sistema, desarrollar el plan del proyecto e identificar los riesgos clave del proyecto. Al final de esta fase debe tener un modelo de requerimientos del sistema (casos de uso UML). - Construcción: la fase de construcción fundamentalmente comprende el diseño del sistema, la programación y las pruebas. - Transición: la fase final de RUP se ocupa de mover el sistema desde la comodidad de desarrollo a la comunidad del usuario y hacerlo trabajar en un entorno real. Al terminar esta fase se debe tener un software documentado que funciona correctamente en su entorno operativo.

19 Figura 8. Proceso RUP en 2 direcciones. Fuente: La figura 8 da una idea de la forma en que interactúan las buenas prácticas de la ingeniería del software y las fases de RUP. Lo que se busca es implementar una estructura de proceso de dos dimensiones, es decir, implementar dichas prácticas a lo largo de las fases del método. Diagrama de Caso de Uso Son diagramas que sirven para representar de forma gráfica las funciones de un sistema de software enfocadas en la interacción con un actor, que según Campderrich (2003), simbolizan la visión que tiene el sistema de una entidad exterior, es decir el conjunto de papeles que dicha entidad puede tener en cada interacción con el sistema. Los casos de uso son un lenguaje, un medio para la comunicación entre los usuarios y los desarrolladores, que permiten de forma detallada englobar la funcionalidad del sistema y como es la interacción con los usuarios. Son de gran importancia en las etapas de recolección de requisitos y según Fowler,

20 Scott y Scott (1999), es lo primero que se debe hacer antes de comenzar con el desarrollo del sistema. Lenguaje de Marcas Extensible (XML) Según W3C (2011), fue desarrollado por la World Wide Consortium en 1996, es un formato basado en texto para representar información estructurada: documentos, datos, configuración, libros, transacciones, facturas entre otros. Fue derivado de un estándar anterior con el fin de adaptarlo al uso Web llamado Estándar de Lenguaje de Marcado Generalizado (SGML) que fue normalizado por la Organización Internacional de Estándares bajo el número Los objetivos de diseño de XML son: - XML debe ser utilizable directamente sobre Internet - XML debe soportar una amplia variedad de aplicaciones - XML debe ser compatible con SGML - Debe ser fácil de escribir programas que procesen documentos XML - El número de características opcionales en XML debe ser mantenido en un mínimo, idealmente cero (0). - Los documentos XML deben ser legibles por un humano y razonablemente claros. - El diseño de XML debe ser preparado rápidamente - El diseño de XML debe ser formal y conciso - Los documentos XML deben ser fáciles de crear - La brevedad en la marcación es de mínima importancia Físicamente un documento XML está compuesto por unidades llamadas entidades, que pueden referirse a otras entidades con el fin de causar su inclusión en el documento. Todo documento debe comenzar en una raíz, y puede estar compuesto de declaraciones, elementos, comentarios, referencias de carácter e instrucciones de proceso.

21 Figura 9. Ejemplo de un XML desde el punto de vista lógico Fuente: Un objeto de datos es un documento XML si es bien formado y si adicionalmente es válido cumpliendo con algunas restricciones adicionales: - Documentos XML bien formados: Un objeto de texto es un documento XML bien formado si: o Tomado como un todo, se empareja con la producción marcada como documento, es decir, contiene uno o más elementos y existe exactamente un elemento llamado la raíz. o Cumple todas las restricciones acerca de buena-formación o Cada una de las entidades procesadas referenciadas directa o indirectamente en el documento es bien formada. - Documentos XML válidos: Un documento de XML es válido si: o Tiene asociada una declaración de tipo de documento, que son declaraciones de marcación que proveen gramática para una clase de documentos, tales como declaración de tipo de elemento, declaración de lista de atributos, declaración de entidad, o de notación. o La declaración de tipo de documento es conforme con las restricciones que en ella se expresan.

22 Figura 10. XML bien formado y válido Fuente: Java Servlet Un servlet puede ser visto como una extensión de un servidor. Es una clase de Java que puede ser cargada dinámicamente para expandir la funcionalidad de un servidor. Siendo una amplificación del servidor se ejecuta en una Máquina Virtual de Java en un servidor, por tanto es seguro y portátil. Sus predecesores, los Programas de Interface común de pasarela (GCI), a pesar de ser los únicos programas que permitían ejecutar código en servidores Web y capturar información Web, en la actualidad resultan menos eficaces y ofrecen menos posibilidades que los servlets; se siguen utilizando, aunque cada vez menos. Según Hunter y Crawford (2001), la utilización de los servlets en el desarrollo Web ofrece numerosas ventajas por encima de otros alcances y es una elección viable. Estas ventajas incluyen características como portabilidad, poder, eficiencia, fortaleza, seguridad, elegancia, integración, extensibilidad y flexibilidad.