UNIVERSIDAD CENTROAMERICANA FACULTAD DE CIENCIA TECNOLOGÍA Y AMBIENTE

Transcripción

1 UNIVERSIDAD CENTROAMERICANA FACULTAD DE CIENCIA TECNOLOGÍA Y AMBIENTE Desarrollo de un prototipo de Framework para la creación de aplicaciones web dinámicas, en el marco del proyecto de investigación Colibrí en la Facultad de Ciencia Tecnología y Ambiente de la Universidad Centroamericana (UCA) entre Enero y Abril del año Tipo de FCE: Producto Creativo Trabajo investigativo para obtener el Título de Ingeniero en Sistemas y Tecnologías de la Información Autor: Everts Joaquín Arceda Rodríguez Tutor: Iván Argüello Managua, Nicaragua Enero 2012

2 PÁGINA DE ACEPTACIÒN Este Producto Creativo fue aprobado por el tribunal examinador de la Facultad de Ciencia, Tecnología y Ambiente de la Universidad Centroamericana como requisito para optar al título de Ingeniería en Sistemas y tecnologías de la información. Lic. Armando José López López Presidente del Tribunal Lic. César David Marín López Secretario Lic. Carlos Iván Argüello Martínez Tutor Br. Everts Joaquín Arceda Rodríguez Egresado

3 DEDICATORIA Dedico esta Tesis a Dios Padre celestial, porque me ha permitido realizar esta ardua y enriquecedora tarea, muestra del conocimiento asimilado a través de este extenso proceso de formación profesional. A mis apreciados Padres que con esfuerzo y sacrificio me ofrecieron su apoyo incondicional, comprensión y aliento en tiempos difíciles, para alcanzar la meta propuesta. A mis docentes de la Facultad de Ciencia Tecnología y Ambiente a quienes con mucho aprecio honro al adquirir de ellos los valiosos conocimientos transmitidos a lo largo de esta trayectoria académica. Con esmero y dedicación Everts Joaquin Arceda Rodríguez

4 AGRADECIMIENTO Agradezco a Dios Padre, por darme el privilegio de alcanzar este logro, por la sabiduría e inteligencia que ha añadido a mi mente para poder alcanzar la meta y culminar los estudios de formación superior. A mis padres porque han sabido realizar su trabajo por el gran cariño y apoyo que me han brindado en esta etapa de estudios, quienes siempre me han alentado a continuar y no retroceder pese a los obstáculos y difíciles situaciones que se han presentado durante todo este transcurso. A los docentes, quienes con compromiso, esfuerzo, dedicación y profesionalismo me guiaron durante el periodo de enseñanza, transmitiendo sus experiencias y depositando la semilla del conocimiento, con capacidad de resolver cualquier problemática o circunstancia adversa que se presente en el mundo laboral. A mi tutor Lic. Iván Argüello, quien tuvo la oportunidad de brindarme todo el apoyo posible, tiempo y esmero en la preparación de la FCE (Forma de Culminación de Estudios), a través de su dirección para presentar un trabajo este trabajo. Gracias por todo el apoyo brindado durante todo este periodo de arduo trabajo.

5 CONTENIDO I. INTRODUCCION II. OBJETIVOS III. MARCO CONCEPTUAL Framework Web Framework para Desarrollo de Aplicaciones Web Aplicaciones web Web Framework Patrón de Diseño (Modelo Vista -Controlador) Metodologías de Desarrollo de Software Metodología Framework Lift Software IV. METODOLOGÍA V. PRESENTACIÓN DE RESULTADOS Definición de Requisitos Diseño de software Codificación e implementación Integración y pruebas del sistema VI. VII. VIII. CONCLUSIONES REFERENCIAS BIBLIOGRAFICAS ANEXOS Anexo 1 Modelado UML Anexo 2 Plan de pruebas

6 RESUMEN El presente documento contiene toda la información del desarrollo de un prototipo de Framework, el cual permitirá construir aplicaciones web dinámicas de manera más rápida, reduciendo tiempos de desarrollo para los programadores, facilitando la reutilización de código de las rutinas más comunes que estos realizan para la construcción de software en tiempos relativamente cortos. La estructura del documento contiene los siguientes aspectos: Introducción donde se refleja la problemática que enfrentan los desarrolladores cuando no utilizan un web Framework para la construcción de aplicaciones web. Además contiene el marco conceptual, donde se plasmó toda la información técnica de las herramientas utilizadas para el desarrollo de este prototipo de Framework y la metodología utilizada. También presenta el alcance obtenido durante el tiempo de desarrollo de esta herramienta y el cumplimiento de cada fase de la metodología implementada, así como las limitaciones que presenta el proyecto.

7 I. INTRODUCCION La presente Forma de Culminación de estudios tiene como propósito el desarrollo de un prototipo de Framework para la creación de aplicaciones web dinámicas, este tipo de proyecto es el primero que se realiza en la Universidad, esto con el objetivo de dar solución a los problemas más comunes que se enfrentan los programadores al momento de construir proyectos de software. Los principales inconvenientes a los que se enfrentan son los tiempos de desarrollo, los cuales son demasiado extensos, esto debido a que tienen que estar realizando tareas repetitivas de programación, pero con la integración de este Framework en un proyecto estos tiempos disminuyen considerablemente. La utilización de este Framework facilitará a los programadores acelerar el proceso de desarrollo, permitiendo la reutilización de código fuente genérico ya existente, el cual puede ser modificado de acuerdo a lo que se desea construir y además permitirá la separación de la aplicación en capas utilizando el patrón de diseño MVC (Modelo Vista Controlador). El alcance del proyecto será cumplir con funcionalidades como: conexión a base de datos, acceso a datos, separación entre diseño y contenido, controladores que permiten la introducción de datos mediante formulario, generación de páginas HTML, autenticación y control de acceso, estas funcionalidades pueden ser fácilmente adaptables a las necesidades de un proyecto concreto.

8 II. OBJETIVOS Objetivo General Desarrollar un prototipo de Framework para la creación de aplicaciones web dinámicas, en el marco del proyecto de investigación Colibrí en la Facultad de Ciencia Tecnología y Ambiente de la Universidad Centroamericana (UCA) entre Enero y Abril del año Objetivos Específicos Realizar el análisis del sistema mediante la identificación de los requerimientos funcionales y la especificación de los mismos. Diseñar el prototipo de Framework con base en la identificación de objetivos de diseño y la construcción de una arquitectura funcional que de soporte a los requerimientos del análisis. Implementar el sistema mediante la tecnología de programación Scala y el Framework de desarrollo Lift.

9 III. MARCO CONCEPTUAL Framework Pressman (2005) expresa: Con el propósito de normalizar y estructurar el código del sistema, facilitando un esquema (un patrón, un esqueleto) para el desarrollo y/o la implementación de aplicaciones. El uso de Frameworks para cualquier tipo de desarrollo reduce el tiempo de elaboración e implementación y ayuda a hacer un trabajo mantenible y escalable, según las características del mismo. Larman (2003) dice: Un Framework agrega funcionalidad extendida a un lenguaje de programación, automatiza muchos de los patrones de programación para orientarlos a un determinado propósito, proporcionando una estructura al código, mejorándolo y haciéndolo más entendible y sostenible, y permite separar en capas la aplicación. En general, divide la aplicación en tres capas: La lógica de presentación que administra las interacciones entre el usuario y el software. La lógica de datos que permite el acceso a un agente de almacenamiento persistente. La lógica de dominio o de negocio, que manipula los modelos de datos de acuerdo a los comandos recibidos desde la presentación. Martínez villalobos (2010) dice: Los Frameworks no son lenguajes de programación, por el contrario son un conjunto de librerías, clases y funciones de un lenguaje en concreto, organizadas para ser reutilizadas en el desarrollo. Es por eso, que la elección de un Frameworks lo primero que debemos decidir es el lenguaje sobre el cual esté desarrollado.

10 Web Framework para Desarrollo de Aplicaciones Web Tal como se expresa en la Introducción de este documento, las aplicaciones web han ido evolucionando progresivamente, debido a que se ha incrementado la incorporación de nuevas funcionalidades, por lo que se estima conveniente especificar lo que son las mismas: Aplicaciones web Iteisa (2009) expresa lo siguiente: Las aplicaciones web pueden considerarse como un sitio web al que se accede de manera normal a través de un navegador, pero dotado de interactividad para la gestión, una base de datos, comunicaciones encriptadas y contraseñas de acceso. En el esquema tradicional de aplicaciones de escritorio el usuario instala el software en su ordenador, generalmente un sistema Windows, donde también se almacenan la totalidad de los datos generados durante su uso. La información se administra desde una única máquina que posee tanto la propia aplicación como toda la información sensible involucrada. Todos los datos de la misma dependen de esta única máquina y de su normal operación. En las aplicaciones web, por el contrario, tanto el software como los datos se alojan en una máquina diferente (remota), centralizada y convenientemente secularizada para trabajar de manera estable, continua e ininterrumpida. El usuario se conecta a este servidor a través de un simple navegador web. En muchos contextos la plataforma web aporta interesantes ventajas frente al software de escritorio, que convierten a este esquema en una interesante alternativa: Ubicuidad. Se accede a la aplicación desde cualquier equipo informático (ordenador personal, portátil, PDA...) conectado a Internet, con independencia de su situación geográfica. Así, es posible controlar en todo momento la situación del negocio, almacén, empleados... tanto desde el propio local como desde casa, o incluso desde extranjero en periodos de vacaciones, etcétera.

11 Multiusuario. A diferencia de las aplicaciones de escritorio, donde sólo el usuario frente al ordenador puede utilizar la aplicación, en las aplicaciones web puede haber varios usuarios conectados al sistema simultáneamente, cada uno a través de un ordenador distinto y en una ubicación geográfica separada (empresas con varios almacenes, por ejemplo), y todos utilizar la aplicación con normalidad. Independencia de software. Para acceder a la aplicación sólo es requisito un navegador web estándar, sin necesidad de instalar en cada equipo ningún otro programa específico. Debido a estos bajos requerimientos, el software puede utilizarse incluso desde ordenadores obsoletos y poco potentes. Seguridad. Al albergarse en un servidor remoto, el funcionamiento de la aplicación y los valiosos datos que contiene son totalmente independientes del ordenador utilizado para la gestión. Así, la normal operación de la aplicación es inmune a una avería de hardware, virus informáticos, o cualquier otro problema local. En caso de necesidad, basta con retomar la conexión al servidor desde cualquier otro ordenador personal o portátil. Multiplataforma e interoperabilidad. A diferencia de las aplicaciones de escritorio, que sólo pueden funcionar bajo el sistema para el que fueron diseñadas, las aplicaciones web son multiplataforma por diseño. Esto significa que podrá conectar con el software desde cualquier versión de Windows -presente o futura-, o incluso otros sistemas operativos como GNU/Linux, Solaris, Symbian (teléfonos móviles GPRS). webdeveloperjuice (2011) dice: Los sitios web dinámicos y robustos se construyen en los entornos de aplicaciones Web. Hay una gran cantidad de Frameworks disponibles hoy en día de pago y gratuitos, pero los más utilizados son Frameworks libres, para el desarrollo de aplicaciones Web. Para la realización de este trabajo, el tipo de Framework que nos interesa es el Web Framework, debido a las ventajas que este ofrece a los desarrolladores de aplicaciones web, pero Qué son los Web Framework? A continuación se describe:

12 Web Framework Camacho Sánchez (2008) expresa lo siguiente: En el desarrollo de software, un Framework es una estructura de soporte definida en la cual otro proyecto de software puede ser organizado y desarrollado. En programación es un set de funciones o código genérico que realiza tareas comunes y frecuentes en todo tipo de aplicaciones (creación de objetos, conexión a base de datos, etc.). Esto brinda una base sólida sobre la cual desarrollar aplicaciones concretas y permite obviar los componentes más triviales y genéricos del desarrollo y abre camino a que diseñadores y programadores puedan pasar más tiempo identificando requerimientos de software. En general los Frameworks son construidos con base en lenguajes orientados a objetos. Esto permite una mejor modularización de los componentes y óptima reutilización de código. Además en la mayoría de los casos un Framework implementará uno o más patrones de diseño de software que aseguren la escalabilidad del producto. El uso de web Frameworks para cualquier tipo de desarrollo reduce el tiempo de elaboración e implementación y ayuda a hacer un trabajo mantenible y escalable, según las características del mismo. Gutiérrez (2006) dice: Los objetivos principales que persigue un Framework son: acelerar el proceso de desarrollo, reutilizar código ya existente y promover buenas prácticas de desarrollo como el uso de patrones. Un web Framework, por tanto, es un conjunto de componentes (clases, descriptores, archivos de configuración XML) que componen un diseño reutilizable que facilita y agiliza el desarrollo de aplicaciones web. Algunas características de los Framework son: Abstracción de URLs y Sesiones: No es necesario manipular directamente las URLs ni las sesiones, el Framework se encarga de realizar esta tarea. Acceso a datos: Incluyen las herramientas e interfaces necesarias para integrarse con herramientas de acceso a datos, en Base de Datos, XML, etc.

13 Controladores: La mayoría de los Framework implementa un serie de controladores para gestionar eventos, como un introducción de datos mediante un formulario o el acceso a una página. Estos controladores suelen ser fácilmente adaptables a las necesidades de un proyecto concreto. Autenticación y control: Incluyen mecanismos para la identificación de usuarios mediante login y password y permiten restringir el acceso a determinadas páginas a determinados usuarios. Además existe una separación entre el diseño y el contenido. Patrón de Diseño (Modelo Vista -Controlador) Para comprender como trabajan los web Frameworks existentes es imprescindible conocer el patrón MVC Figura 1. Patrón de diseño MVC Gutiérrez (2006) expresa: El patrón Modelo-Vista-Controlador es una guía para el diseño de arquitecturas de aplicaciones que ofrezcan una fuerte interactividad con usuarios. Este patrón organiza la aplicación en tres modelos separados, el primero es un modelo que representa los datos de la aplicación y sus reglas de negocio, el segundo es un conjunto de vistas que representan los formularios de entrada y salida de información, el tercero es un conjunto de

14 controladores que procesa las peticiones de los usuarios y controla el flujo de ejecución de la aplicación, Modelo: es la representación de los datos de la aplicación y del código. Coordina la lógica de la aplicación, acceso a base de datos y otras partes no visuales del sistema. Vista: es la representación visual de los datos. Se encarga de la interacción con el usuario. Controlador: es el intermediario entre las otras dos partes. Es responsable de desplegar la vista adecuada al usuario La importancia de la utilización de Framework está claramente establecida por Larman (2003) quien afirma lo siguiente: Debido a la clara separación de componentes y funciones que se logra con el MVC, éste ha jugado un papel muy importante en el desarrollo de los Framework orientados a aplicaciones web, ya que la mayoría de estos aprovechan sus beneficios y lo toman como paradigma. Esta importancia ha hecho que se desarrollen web que faciliten el trabajo de los desarrolladores, entre éstas podemos citar a Biancha (2009) quien menciona los siguientes: Prado Su nombre es la sigla de (PHP Rapid Application Development Objectoriented) Lanzado en Agosto de 2004, es uno de los Frameworks más extendidos y completos. Está compuesto por líneas de código y unas 500 clases. Actualmente se encuentra en la versión y necesita PHP 5.1 o superior para funcionar. Está diseñado en base a Componentes con soporte HTML (controles de ingreso, texto, combo, etc.; validadores, datagrids, wizards, etc. con soporte AJAX) Cake PHP Cake es otro de los grandes. Una excelente página WEB con una enorme cantidad de información para el aprendizaje. Muchos ejemplos, screencast, tutoriales, libros, etc.

15 Cake introdujo Scaffolding. (Creación automática de código para crear, leer, actualizar y borrar datos de las bases de datos). Funciona con PHP o superior. Zend Framework Zend se ha planteado ser el número uno. Está actualmente planteando una estrategia de colocarse como el elegido de los programadores. Actualmente se encuentra en la versión 1.5 y ha anunciado el partnership con DOJO una de las librerías javascript más conocidas y extendidas, lo que promete convertirlo en el framework con soporte AJAX más importante. Pero por ahora es solo una promesa. Lo real, es que es un proyecto de Zend, una empresa que ya nos ha dado el Zend Cache, un sistema de Caching actualmente utilizado en muchísimos proyectos. Además de la utilización de un Framework para el desarrollo de aplicaciones web se necesita utilizar una metodología de desarrollo de software para crear un producto de calidad. No solo existe un tipo de metodología existen varios, las cuales se mencionan a continuación. Metodologías de Desarrollo de Software Stapleton (1997) expresa: Un proceso de software detallado y completo suele denominarse Metodología. Las metodologías se basan en una combinación de los modelos de proceso genéricos (cascada, evolutivo, incremental, etc.). Adicionalmente una metodología debería definir con precisión los artefactos, roles y actividades involucrados, junto con prácticas y técnicas recomendadas, guías de adaptación de la metodología al proyecto, guías para uso de herramientas de apoyo, etc. Habitualmente se utiliza el término método para referirse a técnicas, notaciones y guías asociadas, que son aplicables a una (o algunas) actividades del proceso de desarrollo, por ejemplo, suele hablarse de métodos de análisis y/o diseño. La comparación y/o clasificación de metodologías no es una tarea sencilla debido a la diversidad de propuestas y diferencias en el grado de detalle, información disponible y alcance de cada una de ellas. A grandes rasgos, si tomamos como criterio las notaciones utilizadas para especificar artefactos producidos en actividades de análisis y diseño, podemos clasificar las metodologías en dos grupos: Metodologías Estructuradas y Metodologías Orientadas a Objetos. Por otra parte, considerando su filosofía de desarrollo, aquellas metodologías con mayor énfasis en la planificación y control del proyecto, en especificación precisa de requisitos y modelado,

16 reciben el apelativo de Metodologías Tradicionales (o peyorativamente denominada Metodologías Pesadas, o Peso Pesado). Otras metodologías, denominadas Metodologías Ágiles, están más orientadas a la generación de código con ciclos muy cortos de desarrollo, se dirigen a equipos de desarrollo pequeños, hacen especial hincapié en aspectos humanos asociados al trabajo en equipo e involucran activamente al cliente en el proceso. Metodologías estructuradas Stapleton (1997) expresa: Los métodos estructurados comenzaron a desarrollarse a fines de los 70 s con la Programación Estructurada, luego a mediados de los 70 s aparecieron técnicas para el Diseño (por ejemplo: el diagrama de Estructura) primero y posteriormente para el Análisis (por ejemplo: Diagramas de Flujo de Datos). Estas metodologías son particularmente apropiadas en proyectos que utilizan para la implementación lenguajes de 3ra y 4ta generación. Ejemplos de metodologías estructuradas de ámbito gubernamental: MERISE (Francia), MÉTRICA (España), SSADM (Reino Unido). Ejemplos de propuestas de métodos estructurados en el ámbito académico: Gane & Sarson, Ward & Mellor, Yourdon & DeMarco e Information Engineering. Metodologías orientadas a objetos Stapleton (1997) dice: Su historia va unida a la evolución de los lenguajes de programación orientada a objeto, los más representativos: a fines de los 60 s SIMULA, a fines de los 70 s Smalltalk-80, la primera versión de C++ por Bjarne Stroustrup en 1981 y actualmente Java o C# de Microsoft. A fines de los 80 s comenzaron a consolidarse algunos métodos Orientadas a Objeto. En 1995 Booch y Rumbaugh proponen el Método Unificado con la ambiciosa idea de conseguir una unificación de sus métodos y notaciones, que posteriormente se reorienta a un objetivo más modesto, para dar lugar al Unified Modeling Language (UML), la notación OO más popular en la actualidad.

17 Algunos métodos OO con notaciones predecesoras de UML son: OOAD (Booch), OOSE (Jacobson), Coad & Yourdon, Shaler & Mellor y OMT (Rumbaugh). Algunas metodologías orientadas a objetos que utilizan la notación UML son: Rational Unified Process (RUP), OPEN, MÉTRICA (que también soporta la notación estructurada). Metodologías tradicionales (no ágiles) Stapleton (1997) dice: Las metodologías no ágiles son aquellas que están guiadas por una fuerte planificación durante todo el proceso de desarrollo; llamadas también metodologías tradicionales o clásicas, donde se realiza una intensa etapa de análisis y diseño antes de la construcción del sistema. Todas las propuestas metodológicas antes indicadas pueden considerarse como metodologías tradicionales. Aunque en el caso particular de RUP, por el especial énfasis que presenta en cuanto a su adaptación a las condiciones del proyecto (mediante su configuración previa a aplicarse), realizando una configuración adecuada, podría considerarse Ágil. Metodologías ágiles Un proceso es ágil cuando el desarrollo de software es incremental (entregas pequeñas de software, con ciclos rápidos), cooperativo (cliente y desarrolladores trabajan juntos constantemente con una cercana comunicación), sencillo (el método en sí mismo es fácil de aprender y modificar, bien documentado), y adaptable (permite realizar cambios de último momento). Entre las metodologías ágiles identificadas se encuentran: Extreme Programming Scrum Familia de Metodologías Crystal Feature Driven Development Proceso Unifica (Goette, 2010)do Rational, una configuración ágil Dynamic Systems Development Method Adaptive Software Development Open Source Software Development

18 Además de las metodologías de desarrollo de software existen los modelos de proceso de software, de los cuales se dará una breve explicación a continuación: Modelos de Proceso de Software Sommerville (2002) define modelo de proceso de software como: Una representación simplificada de un proceso de software, representada desde una perspectiva específica. Por su naturaleza los modelos son simplificados, por lo tanto un modelo de procesos del software es una abstracción de un proceso real. Los modelos genéricos no son descripciones definitivas de procesos de software; sin embargo, son abstracciones útiles que pueden ser utilizadas para explicar diferentes enfoques del desarrollo de software. Modelos de Proceso de software existentes: Codificar y corregir Modelo en cascada Desarrollo evolutivo Desarrollo formal de sistemas Desarrollo basado en reutilización Desarrollo incremental Desarrollo en espiral

19 Metodología Modelo en Cascada Royce (1970) dice: El primer modelo de desarrollo de software que se publicó se derivó de otros procesos de ingeniería. Éste toma las actividades fundamentales del proceso de especificación, desarrollo, validación y evolución y las representa como fases separadas del proceso. El modelo en cascada consta de las siguientes fases: 1. Definición de los requisitos: Los servicios, restricciones y objetivos son establecidos con los usuarios del sistema. Se busca hacer esta definición en detalle. 2. Diseño de software: Se particiona el sistema en sistemas de software o hardware. Se establece la arquitectura total del sistema. Se identifican y describen las abstracciones y relaciones de los componentes del sistema. 3. Codificación e implementación: Construcción de los módulos y unidades de software. 4. Integración y pruebas del sistema: Se integran todas las unidades. Se prueban en conjunto. Se entrega el conjunto probado al cliente. 5. Operación y mantenimiento: Generalmente es la fase más larga. El sistema es puesto en marcha y se realiza la corrección de errores descubiertos. Se realizan mejoras de implementación. Se identifican nuevos requisitos. Framework Lift Web Framework Lift Goette (2010) dice: Lift es un web Framework. El cual corre bajo la plataforma java, pero usa Scala como lenguaje de programación. Lift nació con las virtudes de Frameworks web más famosos como Rails y Django. Lift tiene la ventaja del lenguaje scala que al ser un lenguaje script y multiparadigma permite desarrollar rápidamente, pero como corre en la plataforma java se puede comunicar con librerías jar ya desarrolladas.

20 Lift puede empaquetarse como un war y funcionar en cualquier servidor web java como Tomcat o Jetty. Lift es un proyecto open source distribuido bajo licencia Apache V2.0 Software Para poder realizar la programación del proyecto, se utilizó como IDE (Entorno de Desarrollo Integrado) Eclipse Galileo debido a que este permite la integración de proyectos en Scala, este es un lenguaje de programación del que se especificará a continuación. Eclipse Galileo Eclipse (2010) nos dice: Eclipse es un entorno de desarrollo integrado de código abierto multiplataforma para desarrollar lo que el proyecto llama "Aplicaciones de Cliente Enriquecido", opuesto a las aplicaciones "Cliente-liviano" basadas en navegadores. Esta plataforma, típicamente ha sido usada para desarrollar entornos de desarrollo integrados (del inglés IDE), como el IDE de Java llamado Java Development Toolkit (JDT) y el compilador (ECJ) que se entrega como parte de Eclipse (y que son usados también para desarrollar el mismo Eclipse). Sin embargo, también se puede usar para otros tipos de aplicaciones cliente, como BitTorrent o Azureus. Eclipse es también una comunidad de usuarios, extendiendo constantemente las áreas de aplicación cubiertas. Un ejemplo es el recientemente creado Eclipse Modeling Project, cubriendo casi todas las áreas de Model Driven Engineering. Eclipse fue desarrollado originalmente por IBM como el sucesor de su familia de herramientas para VisualAge. Eclipse es ahora desarrollado por la Fundación Eclipse, una organización independiente sin ánimo de lucro que fomenta una comunidad de código abierto y un conjunto de productos complementarios, capacidades y servicios.

21 Scala Pollak (2009) expresa lo siguiente: Scala es un lenguaje que combina la orientación a objetos con la programación funcional; tiene un sistema de tipado fuerte pero con inferencia de tipos; es un lenguaje que compila a bytecode de la JVM (Java Virtual Machine) pero puede aproximar la interpretación de los lenguajes de script en ocasiones. Toma muchas ideas de lenguajes anteriores como: Smalltalk (Lenguaje de Programación Orientado a Objetos), Erlang (Lenguaje de Programación Concurrente), Haskell (Lenguaje de Programación Funcional), ML (Lenguaje de Programación Multiparadigma: Imperativo y Funcional ), Eiffel (Lenguaje de Programación Orientado a Objetos) y Ruby (Lenguaje de Programación Multiparadigma: Interpretado, Reflexivo y Orientado a Objetos) y las intenta aglutinar en un lenguaje aparentemente amplio pero que esconde un núcleo conciso y compacto. La mayoría de la funcionalidad más visible está implementada en forma de librerías. Además de la utilización de un IDE y de un lenguaje de programación, se ha decidido utilizar Apache Maven como compilador, debido a que permite la localización de errores cuando se realiza la compilación y es usado en proyectos desarrollados en java. A continuación se especifica mejor: Apache Maven ApacheMavenProject (2011) dice: JDK Apache Maven es un gestor de configuración y automatización de compilación y pruebas de software, principalmente usado para proyectos Java. A diferencia de Apache Ant (otro popular automatizador de compilación) que su configuración es vía imperativa (se especifican las instrucciones en secuencia de cómo hacer la compilación); Apache Maven funciona de forma declarativa (a través de XML se especifica que es lo que se quiere de entregable final). Debido a que la programación del proyecto se realizará en Scala, es necesario utilizar las librerías de Java, por este motivo se tiene que depender del JDK (Java Development Kit)

22 Oracle (2011) expresa: Se trata de un conjunto de herramientas (programas y librerías) que permiten desarrollar (compilar, ejecutar, generar documentación, etc.) programas en lenguaje Java. Existen versiones del JDK para prácticamente todos los Sistemas Operativos y existen también distintos programas comerciales Sun distribuye gratuitamente el JDK oficial para los siguientes sistemas operativos: Windows 95/98/NT, Solaris y Linux Para la manipulación de los datos, se utiliza como Gestor de Base de Datos PostGreSQL por la facilidad que ofrece para ser integrado en Scala. PostGreSQL Lockhart (2001) dice: PostGreSQL es un sistema de gestión de bases de datos objeto-relacional (ORDBMS) basado en el proyecto POSTGRES, de la universidad de Berkeley. El director de este proyecto es el profesor Michael Stonebraker, y fue patrocinado por Defense Advanced Research Projects Agency (DARPA), el Army Research Office (ARO), el National Science Foundation (NSF), y ESL, Inc. PostGreSQL es una derivación libre (OpenSource) de este proyecto, y utiliza el lenguaje SQL92/SQL99, así como otras características que comentaremos más adelante. El Sistema Gestor de Bases de Datos Relacionales Orientadas a Objetos conocido como PostgreSQL (y brevemente llamado Postgres95) está derivado del paquete Postgres escrito en Berkeley. Con cerca de una década de desarrollo tras él, PostgreSQL es el gestor de bases de datos de código abierto más avanzado hoy en día, ofreciendo control de concurrencia multi-versión, soportando casi toda la sintaxis SQL (incluyendo subconsultas, transacciones, y tipos y funciones definidas por el usuario), contando también con un amplio conjunto de enlaces con lenguajes de programación (incluyendo C, C++, Java, perl, tcl y python). Para la elaboración de los diagramas que componen el modelado del sistema, se utilizó la herramienta de modelado UML Enterprise Architect:

23 Enterprise Architect Sparxsystems (2007) dice: Enterprise Architect es una herramienta de uso muy sencillo, que aborda el diseño y análisis UML (Unified Modeling Language) y cubre el desarrollo de software desde la captura de requerimientos a lo largo de las etapas de análisis, diseño, pruebas y mantenimiento. EA es una herramienta multiusuario, Windows, diseñada para ayudar a construir software robusto y fácil de mantener. Además, permite generar documentación e informes flexibles y de alta calidad.

24 IV. METODOLOGÍA El proceso de desarrollo de software que se realizó, está compuesto de una serie de actividades, las cuales son necesarias para alcanzar el producto deseado, las actividades genéricas que se realizaron según la metodología modelo en cascada fueron: Para lograr un mejor resultado en estas actividades, en el desarrollo de este proyecto, se trabajó con la Metodología de desarrollo de software Modelo en Cascada, de la cual se ha especificado en el Marco Teórico. Las fases que se lograron alcanzar son las siguientes: Definición de requisitos Figura 2. Actividades del ciclo de vida del software Lo que se realizó en esta fase, fue tomar las ideas que proporcionó el profesor Kaoru Sato quien era nuestro stakeholder (Facilitador de Requerimientos); luego de realizar un análisis de las mismas, procedimos a seleccionar cuál de los requisitos planteados eran los más adecuados y los más alcanzables a integrar al Framework en el tiempo estimado. Diseño de software Debido a que el prototipo de Framework está dirigido al desarrollo de aplicaciones web, la arquitectura de desarrollo que se utilizó fue MVC (Este tipo de arquitectura se explicó anteriormente en el Marco Teórico de este documento). También se realizó el diseño de la base de datos y el modelado del sistema. Para efectuar el diseño de la base de datos se utilizó como buena práctica de desarrollo la normalización datos esto para evitar la redundancia de los mismos, el diseño fue elaborado con la herramienta de modelado UML Enterprise Architect. El resultado en esta etapa del desarrollo fue el Diagrama de Base de Datos. Como parte del diseño también se elaboro el diagrama de clases, diagramas de secuencia y diagramas de casos de uso.

25 Codificación e implementación En esta fase lo que obtuvo fue el código fuente del proyecto como resultado de la programación realizada, la codificación se llevo a cabo bajo el IDE de desarrollo Eclipse Galileo. Además se realizo el modelo físico de la Base de Datos con el Sistema Gestor de Base de Datos Objeto-Relacional, PostgreSql y se generó el Diccionario de datos. El resultado fue el código fuente y funcional del proyecto y el modelo físico de la Base de Datos. Integración y pruebas del sistema En esta fase lo que ejecutamos fue un plan de pruebas el cual fue ejecutado en el proyecto que obtuvo como resultado en la fase anterior, en el cual se realizaron pruebas de integridad de datos y pruebas unitarias esto con el objetivo de encontrar errores en el código fuente del proyecto. Para realizar esto se utilizó como herramienta de documentación Microsoft Excel, donde se crearon formatos para la realización de las pruebas bajo los cuales se presentarían el resultado obtenido de las pruebas realizadas, con esto se creó un plan de pruebas. Operación y mantenimiento Debido a que el proyecto tenía una duración de 3 meses, solo se llegó a desarrollar algunas funcionalidades del Framework, por este motivo la programación se limitó a un prototipo. Se realizó una demostración del prototipo de Framework en la cual se ejecutaron las funcionalidades que se logran programar.

26 V. PRESENTACIÓN DE RESULTADOS Como se expresa en la metodología por cada fase del ciclo de vida del software se deben obtener resultados, los cuales se presentaran a continuación: Definición de Requisitos Requisitos Funcionales Número de requisito RF1 Nombre de requisito Gestión de Usuarios Tipo Requisito Restricción Descripción El usuario podrá Administrar los usuarios del sistema Prioridad del requisito Baja/ Alta/Esencial Media/Deseado Opcional Número de requisito RF2 Nombre de requisito Agregar Control Tipo Requisito Restricción Descripción El usuario podrá agregar controles a la página. Prioridad del requisito Baja/ Alta/Esencial Media/Deseado Opcional Número de requisito RF3 Nombre de requisito Modificar Control Tipo Requisito Restricción Descripción El usuario podrá realizar cambios a los diferentes controles que componen la página Prioridad del requisito Baja/ Alta/Esencial Media/Deseado Opcional Número de requisito RF4 Nombre de requisito Eliminar Control Tipo Requisito Restricción Descripción El usuario podrá eliminar controles de la página que no desee utilizar, estos cambios solo los podrá realizar dependiendo del tipo de privilegio que tenga Prioridad del requisito Baja/ Alta/Esencial Media/Deseado Opcional

27 Número de requisito RF5 Nombre de requisito Autorizar Modificación Tipo Requisito Restricción Descripción El usuario (administrador) autorizara modificaciones de página, las aprobaciones de los cambios en las páginas solo serán autorizadas por el administrador Prioridad del requisito Baja/ Alta/Esencial Media/Deseado Opcional Número de requisito RF6 Nombre de requisito Ver lista de Operaciones Tipo Requisito Restricción Descripción El usuario tendrá acceso a ver la lista de operaciones que posee una página. Las operaciones están compuestas por una serie de controles. Prioridad del requisito Baja/ Alta/Esencial Media/Deseado Opcional Número de requisito RF7 Nombre de requisito Ver lista de Controles Tipo Requisito Restricción Descripción El usuario podrá visualizar en cualquier momento la cantidad de controles da las operaciones Prioridad del requisito Baja/ Alta/Esencial Media/Deseado Opcional Número de requisito RF8 Nombre de requisito Ver Lista de Páginas Tipo Requisito Restricción Descripción El usuario tendrá acceso a ver la lista de páginas que ha creado Prioridad del requisito Baja/ Alta/Esencial Media/Deseado Opcional Número de requisito RF9 Nombre de requisito Uso de Funciones Tipo Requisito Restricción Descripción La aplicación permitirá el uso de funciones y tipos de datos generados a partir del Framework Prioridad del requisito Baja/ Alta/Esencial Media/Deseado Opcional

28 Requisitos no funcionales Número de requisito RNF1 Nombre de requisito Autenticación de Usuarios Tipo Requisito Restricción Descripción El sistema contara con una página de acceso que permitirá la autenticación de usuarios Número de requisito RNF2 Nombre de requisito Arquitectura Implementada Tipo Requisito Restricción Descripción La aplicación será web por lo tanta estará basada en una arquitectura cliente-servidor. Número de requisito RNF3 Nombre de requisito Entorno por Usuario Tipo Requisito Restricción Descripción Cada rol de usuario permitirá cargar entornos de página que contienen funcionalidades diferentes.

29 Diseño de software En esta fase se realizó el diseño de los diagramas de casos de uso, diagramas de secuencia y diagrama de clases, diccionario de datos de la base de datos, los cuales se presentan a continuación: Diagramas de Casos de Uso Figura 3. Caso de uso gestión de operación En este diagrama se muestra como el usuario a través del prototipo de Framework puede gestionar las operaciones, es decir que el mismo puede visualizar todas las operaciones que se han creado y las puede modificar.

30 Figura 4. Caso de uso gestión de página En este diagrama se muestra como el usuario a través del prototipo de Framework puede gestionar las páginas, es decir que el mismo puede visualizar todas las páginas que se han creado y las puede modificar. Para visualizar todos los diagramas de secuencia se recomienda ver Anexo N 1, inciso 1.1

31 Diagramas de Secuencia Figura 5. Diagrama de secuencia crear datos de operación

32 Figura 6. Diagrama de secuencia crear elementos de página Para visualizar todos los diagramas de secuencia se recomienda ver Anexo N 1, inciso 1.2.

33 Diagrama de Clases class Diagrama de Clases User System_Validation - explain_c: varchar(256) - id: int - label_nm: varchar(16) - validation_nm: varchar(16) - value: int 1 Control - id: int - mode_c: int 1..* Login - cookie: varchar(16) - id: int - login_dt: date - login_id: int 1..* varchar(256) - firstname: varchar(32) - id: int - lastname: varchar(32) - locale: varchar(16) - password_pw: varchar(32) - password_slt: varchar(16) - superuser: bool - textarea: varchar(2048) - timezone: varchar(32) - uniqueid: varchar(32) - validated: bool 1..* Label - id: int - label: varchar(64) - label_nm: varchar(16) - lang_id: int - operation_id: int 1..* 1..* 1..* Page_elements - actual: int - control_id: int - data_id: int - id: int - label_nm: varchar(16) - maxlength: int - note: varchar(256) - order_c: int - page_id: int - size_c: int 1..* 1..* 1..* Page - delete_fg: int - id: int - login_nm: varchar(16) - operation_id: int - organization_nm: varchar(16) - page_nm: varchar(16) - page_tp: int - panel_id: int - status: int - update_dt: date 1 1..* Organization - delete_fg: int - organization_full_nm: varchar(64) - organization_nm: varchar(16) - status: int 1..* 1..* 1..* 1..* Table_contents - element_id: int - id: int - mode_c: int - order_c: int - panel_id: int 1..* 1 Panel 1 - id: int - order_c: int - page_id: int 1..* Message Operation - delete_fg: int - description: varchar(64) - id: int - login_nm: varchar(16) - operation_nm: varchar(64) - organization_nm: varchar(16) - status: int - update_dt: date 1..* 1 Operation_data - actual: int - data_nm: varchar(16) - data_type: int - id: int - null_allowed: int - operation_id: int - order_c: int - size_c: int Language - id: int - lang_id: int - lang_nm: varchar(16) * 1..* - id: int - lang_id: int - message: varchar(1024) - message_nm: varchar(16) - operation_id: int Figura 7. Diagrama de clases 1 Login_user - date_format: int - id: int - lang_id: int - login_id: int - login_nm: varchar(16) - logout_dt: date - organization_nm: varchar(16) - password: varchar(16)

34 Diagrama de Base de Datos class DDL Control «column» id: int mode_c: int *PK controlid: Integer «PK» + PK_Control(Integer) +PK_Control (controlid = controlid) «FK» +Control 1..* Control_x_page «column» FK controlid: Integer FK pageid: Integer «FK» + Control(Integer) + Page(Integer) User «column» id: int firstname: varchar(32) lastname: varchar(32) varchar(256) locale: varchar(16) password_pw: varchar(32) password_slt: varchar(16) superuser: bool textarea: varchar(2048) timezone: varchar(32) uniqueid: varchar(32) validated: bool *PK userid: Integer FK loginid: Integer «PK» + PK_User(Integer) Panel «column» id: int order_c: int page_id: int *PK panelid: Integer «PK» + PK_Panel(Integer) Table_contents «column» id: int element_id: int mode_c: int order_c: int panel_id: int *PK table_contentsid: Integer FK panelid: Integer «PK» + PK_Table_contents(Integer) «FK» + FK_Table_contents_Panel(Integer) +Page 1..* «FK» + FK_User_Login(Integer) +PK_Panel +PK_Panel 1 1 (panelid = panelid) «FK» +FK_Table_contents_Panel 1..* (pageid = pageid) «FK» +FK_User_Login (loginid = +PK_Login loginid) 1 «FK» 1 (panelid = panelid) «FK» +FK_Page_Panel 1..* +PK_Page Login «column» id: int cookie: varchar(16) login_dt: date login_id: int *PK loginid: Integer FK pageid: Integer «PK» + PK_Login(Integer) «FK» + FK_Login_Page(Integer) Operation_data «column» id: int operation_id: int data_nm: varchar(16) data_type: int actual: int null_allowed: int order_c: int size_c: int *PK operation_dataid: Integer «PK» + PK_Operation_data(Integer) Page «column» id: int delete_fg: int login_nm: varchar(16) operation_id: int organization_nm: varchar(16) page_nm: varchar(16) page_tp: int panel_id: int status: int update_dt: date *PK pageid: Integer FK panelid: Integer «PK» + PK_Page(Integer) «FK» + FK_Page_Panel(Integer) +PK_Page +PK_Page 1 1 (pageid = pageid) «FK» +FK_Login_Page 1..* (pageid = pageid) «FK» +FK_Organization_Page 1..* Organization «column» delete_fg: int organization_full_nm: varchar(64) organization_nm: varchar(16) status: int *PK organizationid: Integer FK pageid: Integer «PK» + PK_Organization(Integer) «FK» + FK_Organization_Page(Integer) (operation_dataid = +FK_Operation_Operation_data +PK_Operation_data operation_dataid) 1 +PK_Page (pageid = pageid) «FK» +PK_Page (pageid = +PK_Page pageid) «FK» «FK» +Page +Page 1..* 1..* (pageid = pageid) «FK» 1..* Operation_x_page «column» FK operationid: Integer FK pageid: Integer «FK» + Operation(Integer) + Page(Integer) Message_x_page «column» FK messageid: Integer (messageid +Message +PK_Message = FK pageid: Integer messageid) 1..* «FK» «FK» + Message(Integer) + Page(Integer) Operation «column» id: int login_nm: varchar(16) operation_nm: varchar(64) organization_nm: varchar(16) status: int update_dt: date delete_fg: int description: varchar(64) *PK operationid: Integer FK operation_dataid: Integer «PK» + PK_Operation(Integer) «FK» + FK_Operation_Operation_data(Integer) +PK_Operation (operationid = operationid) «FK» +Operation 1..* +Page 1..* Elements_x_page «column» FK page_elementsid: Integer FK pageid: Integer «FK» + Page_elements(Integer) + Page(Integer) +FK_Language_Login_user 1..* Language «column» id: int lang_id: int lang_nm: varchar(16) *PK languageid: Integer FK login_userid: Integer «PK» + PK_Language(Integer) «FK» + FK_Language_Login_user(Integer) +PK_Language 1 (languageid = languageid) «FK» +FK_Message_Language 1..* Figura 8. Diagrama de Base de Datos Message «column» id: int lang_id: int message: varchar(1024) message_nm: varchar(16) operation_id: int *PK messageid: Integer FK languageid: Integer «PK» + PK_Message(Integer) +PK_Login_user 1 (login_userid = login_userid) «FK» «FK» + FK_Message_Language(Integer) +Page_elements+PK_Page_elements 1..* (page_elementsid = page_elementsid) «FK» Login_user «column» id: int date_format: int lang_id: int login_id: int login_nm: varchar(16) logout_dt: date organization_nm: varchar(16) password: varchar(16) *PK login_userid: Integer «PK» + PK_Login_user(Integer) +PK_Language (languageid +FK_Label_Language = languageid) 1 «FK» 1..* Label «column» id: int label: varchar(64) label_nm: varchar(16) operation_id: int lang_id: int *PK labelid: Integer FK system_validationid: Integer FK languageid: Integer «PK» + PK_Label(Integer) Label_x_page_elements «FK» + FK_Label_System_Validation(Integer) + FK_Label_Language(Integer) «column» FK page_elementsid: Integer FK labelid: Integer «FK» + Page_elements(Integer) + Label(Integer) +Page_elements 1..* (page_elementsid = page_elementsid) «FK» +PK_Page_elements Page_elements «column» id: int control_id: int data_id: int actual: int label_nm: varchar(16) maxlength: int note: varchar(256) order_c: int page_id: int size_c: int *PK page_elementsid: Integer «PK» + PK_Page_elements(Integer) +FK_Label_System_Validation +PK_Label 1..* (labelid = labelid) «FK» +Label 1..* (system_validationid = system_validationid) «FK» +PK_System_Validation 1 System_Validation «column» id: int explain_c: varchar(256) label_nm: varchar(16) validation_nm: varchar(16) value: int *PK system_validationid: Integer «PK» + PK_System_Validation(Integer)

35 Diccionario de Datos Tabla 1. Diccionario de Base de Datos

36 Tabla 2. Diccionario de Base de Datos

37 Tabla 3. Diccionario de Base de Datos

38 Tabla 4. Diccionario de Base de Datos

39 Codificación e implementación Las siguientes pantallas son una muestra de la programación que se logró alcanzar durante el tiempo de planificado para el desarrollo del prototipo de Framework Colibrí. Para la compilación del proyecto se tiene que utilizar Apache Maven. La Compilación se realiza de la siguiente manera, ejecutamos el símbolo del sistema y nos ubicamos en la carpeta donde tenemos nuestro proyecto, luego de esto ejecutamos el comando mvn jetty:run para realizar la compilación y la detección de errores. Figura 9. Compilación de proyecto Figura 10. Proyecto compilado y sin errores

40 Cuando el proyecto se ejecuta por primera vez esta crea las tablas de la base de datos con la que se trabajará por este motivo dura un poco de tiempo cuando se realiza la compilación. Si se detecta errores Maven indica en que parte del código están los errores, una vez que se realizó la compilación satisfactoriamente muestra un mensaje (Starting scanner at interval of 5 seconds), luego debemos escribir en el navegador web la dirección localhost:8080 este es la dirección local y el 8080 indica el puerto que se está utilizando para ejecutar la aplicación. Nota: Mientras la aplicación se esté ejecutando, no se debe cerrar el símbolo del sistema debido a que a través de este se está ejecutando Maven quien realiza todas las operaciones de la aplicación, si este se cierra la aplicación deja de funcionar. Página principal de la aplicación desarrollada bajo el prototipo de Framework Colibrí, esta página contiene los menús a través de los cuales se puede realizar la navegación y acceder a las diferentes opciones que presenta esta aplicación. Figura 11. Página principal

41 Menú Operation Esta opción permite realizar modificaciones en la operaciones que el usuario ha creado, a través de este menú se puede crear operaciones nuevas, modificar operaciones existentes, eliminar operaciones, deshacer cambios realizados sobre operaciones y aplicar cambios a las operaciones. Figura 12. Contenido del menú operación

42 Referencia de Operación (Ref) Esta opción permita buscar y visualizar una operación en especifico. Figura 13. Opción referencia de operación

43 Agregar Operación (Add) A través de esta opción se pueden crear nuevas operaciones. Figura 14. Opción agregar operación

44 Menú AdminPage (Add) Esta opción permite visualizar las páginas que han sido creadas, muestra todas las operaciones que contiene cada página. Figura 15. Menú administración, opción agregar página

45 AdminPage (Add) Esta opción permita agregar nuevas paginas. Figura 16. Opción agregar operaciones a página

46 Integración y pruebas del sistema Plan de Pruebas Unitarias y de Integridad de Datos La siguiente tabla es una muestra del formato de pruebas que se implementó para documentar las pruebas realizadas, cabe mencionar que no es la única tabla, esto es solo una muestra del plan de pruebas implementado. Figura 17. Formato utilizado para documentar plan de pruebas Para visualizar de forma más detallada el plan de pruebas se recomienda ver Anexo N 2.

47 VI. CONCLUSIONES El desarrollo de aplicaciones web cada vez se está agilizando más, debido a la gran cantidad de herramientas como los web Framework y las metodologías de desarrollo de software que permiten que los programadores realicen buenas prácticas de programación para obtener software de calidad. Durante el desarrollo de este proyecto se logro completar cada fase de desarrollo, que la metodología utilizada indicaba, en la fase de análisis se lograron identificar los requerimientos funcionales y la especificación de los mismos. En la fase de diseño se realizo el modelado UML y se estableció la arquitectura del Framework, la cual es Modelo Vista Controlador (MVC) y para lograr la codificación del proyecto se Implemento la tecnología de programación Scala y el Framework de desarrollo Lift. Dando como resultado un prototipo de Framework que permitirá a los programadores agilizar los procesos de desarrollo de software.

48 VII. REFERENCIAS BIBLIOGRAFICAS ApacheMavenProject. (2011). Apache Maven Project. Recuperado el Septiembre de 2011, de Biancha, D. (2009). Obtenido de Camacho Sánchez, G. D. (2008). Obtenido de Eclipse, F. (2010). eclipse.org. Recuperado el 2011, de Goette, E. (19 de Septiembre de 2010). Obtenido de Gutiérrez, J. J. (2006). cssblog. Recuperado el 2011, de Iteisa. (2009). Recuperado el 2011, de Larman, C. (2003). UML y Patrones. Una introducción al análisis y diseño orientado a objetos y al proceso unificado. Madrid: Pearson Educación. Lockhart, T. (2001). Tutorial de PostgreSQL. The PostgreSQL Administrator s Guide, 1-2. Martínez villalobos, G. (2010). Recuperado el Agosto de 2011, de queesunframework Oracle. (2011). oracle.com. Recuperado el Septiembre de 2011, de Pollak, D. (2009). Beginning Scala. New York: Springer-Verlag New York, Inc. Pressman, R. (2005). Ingeniería del Software. Un enfoque práctico. México: McGraw-Hill. Royce, W. (1970). Managing the developmet of large software systems: Concepts and technique.

49 Sommerville, I. (2002). Ingenieria de Software. Pearson Educación. Stapleton, J. (1997). Dynamic Systems Development Method-The Method in Practice. Addison Wesley. Venkman. (2010). debugmodeon. Recuperado el 2011, de webdeveloperjuice. (2011). Recuperado el Agosto de 2011, de

50 VIII. ANEXOS Anexo 1 Modelado UML Diagramas de Casos de Uso Figura 18. Caso de uso aprobar página

51 Figura 19. Caso de uso aprobar operación

52 1.2 Diagramas de Secuencia Figura 20. Diagrama de secuencia modificar datos de operación

53 Figura 21. Diagrama de secuencia eliminar datos de operación

54 Figura 22. Diagrama de secuencia modificar operación

55 Figura 23. Diagrama de secuencia eliminar operación

56 Figura 24. Diagrama de secuencia modificar elementos de página

57 Figura 25. Diagrama de secuencia eliminar elementos de página

58 Figura 26. Diagrama de secuencia eliminar página

59 Anexo 2 Plan de pruebas Introducción Este plan de pruebas tiene como finalidad establecer la forma en la que se realizaron las pruebas del prototipo de Framework Colibrí. Las pruebas expuestas en este documento tienen como finalidad demostrar la funcionalidad que se puede alcanzar al integrar este prototipo de Framework al desarrollo de una aplicación, para este tipo de prueba se comprobará que las entradas y salidas sean correctas y que la integridad de los datos se preserva. Las pruebas fueron realizadas por un equipo de 3 personas, que participó en el desarrollo del sistema. Los casos de prueba realizados son los siguientes: Enfoque Referencia de operaciones. Agregar operaciones. Modificar operaciones. Eliminar operaciones. Deshacer cambios. Las pruebas realizadas son de tipo Caja Negra, debido a que una gran parte de la funcionalidad del sistema se debe a la información de la base de datos. Por tanto, la evaluación de flujos de código no es de mayor trascendencia. Visión El sistema Colibrí, es un sistema que permite a entidades bancarias facilitar el manejo de operaciones y páginas, almacenando información relacionada a operaciones y el contenido de las páginas, necesario para la ejecución correcta de las operaciones. Alcance Las pruebas ejecutadas consisten en un grupo de condiciones determinadas por ciertos valores. Para ello, se evaluará que la entrada y/o salida sea la correcta y se guardarán capturas de pantalla como evidencia de las pruebas ejecutadas. Estrategia de pruebas Los tipos de pruebas que se realizaran son 2:

60 Diseño de página El objetivo de esta prueba es verificar que se muestran todos los elementos correspondientes para la ejecución de una operación. Funcionamiento Estas pruebas tienen como objetivo verificar que al ejecutar una acción, la salida sea la correcta y los cambios en la base de datos se hagan de forma satisfactoria. Para la ejecución de todas las pruebas, es necesario tener conexión al servidor de base de datos. Formato de pruebas El formato de las pruebas realizadas se detalla a continuación: Para la documentación de las pruebas, se utilizó la herramienta Microsoft Excel. En la parte superior de la hoja, se encuentra un cuadro en el cual se cuentan la cantidad de condiciones de verificación, el total de confirmaciones a realizar, la cantidad de resultados correctos y la cantidad de errores detectados. Posteriormente se detallan las políticas de verificación por cada caso, notas adicionales y la forma de la preparación de evidencias. Para todos los casos de prueba, la evidencia consiste en capturas de pantalla, resaltando todos los elementos a confirmar. Luego, se detalla una tabla con las condiciones que se tomaran en cuenta para la ejecución de las pruebas, y los resultados esperados para cada ejecución. Para cada condición, deben revisarse ciertos elementos de los que se espera obtener un resultado determinado. Por último, se detalla la tabla de confirmaciones, donde se colocarán los resultados obtenidos. Cada celda, contiene 2 opciones, verdadero o falso. Por cada opción seleccionada como verdadera, un contador aumentara en el cuadro superior de resultados correctos, y por cada opción seleccionada como falsa, aumentara el contador en el cuadro de errores. Para interpretar la evidencia, se marcaran los cuadros por cada caso, con el número de la ejecución seguido de un guión y el número de elemento a verificar. Para los casos en los que se revisaron varias ejecuciones en una sola, solo se colocará el número del elemento a verificar. Este formato de pruebas fue diseñado por el creador del sistema, el profesor Kaoru Sato. Este es un ejemplo de un caso de prueba:

61 Figura 27. Formato de plan de pruebas Nombre de caso Nombre de Prueba Contenido de las verificaciones PageDesign(Ref) Prueba 1 Confirmar página de Operation Data en mode Ref Funcionamiento(Ref) Prueba 2 Confirmar mensajes y transiciones de Operation Data mode Ref PageDesign(Add) Prueba 3 Confirmar página de Operation Data en mode Add Funcionamiento(Add) Prueba 4 Confirmar mensajes y transiciones de Operation Data mode Add PageDesign(Mod) Prueba 5 Confirmar página de Operation Data en mode Mod Tabla 5. Ejecución de casos de prueba

62 Prueba # 1 Comprobar que se muestran los elementos correctos en la pantalla principal Cantidad de resultado Cantidad de verificaciones 13 Cantidad de confirmaciones 359 Cantidad de ejecuciones Normales 339 Cantidad de Errores 8

63 Prueba # 2 Compruebe que se muestren los elementos correctos en la pantalla principal Cantidad de resultado Cantidad de verificaciones 5 Cantidad de confirmaciones 27 Cantidad de ejecuciones Normales 2 Cantidad de Errores 0

64 Prueba # 3 Cantidad de resultado Cantidad de verificaciones 12 Cantidad de confirmaciones 381 Cantidad de ejecuciones Normales 352 Cantidad de Errores 32

65 Prueba # 4 Cantidad de resultado Cantidad de verificaciones 12 Cantidad de confirmaciones 210 Cantidad de ejecuciones Normales 206 Cantidad de Errores 3

66 Prueba # 5 Cantidad de resultado Cantidad de verificaciones 14 Cantidad de confirmaciones 470 Cantidad de ejecuciones Normales 424 Cantidad de Errores 46

67

68