1Visión del problema






descargar 31.43 Kb.
título1Visión del problema
fecha de publicación25.09.2015
tamaño31.43 Kb.
tipoDocumentos
l.exam-10.com > Documentos > Documentos
Diseño de Sistemas de Software

Extensión a Virtual Scrum para dar soporte a la interoperabilidad con aplicaciones issue trackers

(Trabajo sometido como examen final de la materia)

Autores:

P. J. Barrios - pablojbarrios@alumnos.exa.unicen.edu.ar

M.S. Sosa - msosa@alumnos.exa.unicen.edu.ar

Tabla de contenido


1Visión del problema 3

2Organización del documento 3

3Especificación de requerimientos 4

4Análisis de componentes 4

4.1Virtual Scrum 4

4.2Issue trackers (Teamwork) 4

5Diseño 4

5.1Interoperabilidad entre VS y Teamwork 4

5.1.1Propuestas para la integración de Teamwork 4

5.1.2Implementación de la propuesta escogida como solución 9

5.2Tratamiento del flujo de datos 9

5.3Tratamiento de vistas dinámicas 10

5.4Integración de los componentes resultantes a VS. 10

5.5Mapeo de acciones y abstracción de comportamiento 10

6Arquitectura resultante 10

6.1Estructura 10

6.2Comportamiento 10

6.3Diseño detallado 11

6.4Análisis 12

6.5Extensibilidad: Proceso para cambiar el issue tracker 12

Apéndice A. Selenium. 13

Apéndice B. Contenedores de JavaBeans de Spring 14


1Visión del problema


El presente trabajo tiene como objetivo extender el sistema Virtual Scrum (VS) para que soporte la integración (o interoperabilidad) de herramientas que faciliten la gestión de proyectos (como Teamwork, Bugzilla, Mantis, etc.), también llamados issue trackers. De esta manera, las acciones que realiza un usuario dentro VS (como agregar o modificar los ítems del product backlog) refleja una acción que realiza automáticamente la herramienta integrada (como agregar o modificar las issues de un proyecto); manteniendo, así, sincronizados los objetos que se mapean de una aplicación a otra.

En el caso que el issue tracker integrado posea características adicionales para las acciones y/o datos que ofrece, las mismas deben ser reflejadas como funcionalidades y/o datos adicionales dentro de VS. Por ejemplo, un backlog ítem de VS y una issue de Teamwork poseen datos en común, como el nombre, fecha de creación, estado, etc.; si Teamwork posee otros datos adicionales, como prioridad o creador, VS también debe poder acceder a ellos.

Se pide, como principal requerimiento no funcional, flexibilidad para agregar o modificar el/los issue/s tracker/s configurados. Esto quiere decir que si se desea configurar una nueva herramienta (digamos cambiar Mantis por Bugzilla), dicha configuración pueda lograrse con la mínima generación de código posible.

2Organización del documento


En la sección 3 se pretende extender la visión del problema tratando de identificar los requerimientos funcionales y no funcionales solicitados para la resolución del presente trabajo. En la sección 4 se presenta un análisis de los componentes que componen la arquitectura actual, y de los nuevos que deben ser integrados.

En la sección 5, se muestran los pasos y decisiones de diseño que han tomado sido tomadas. Cada sub-sección 5.i, indica un sub-problema a atacar y se especifica, para el mismo, que alternativas se han tenido en cuenta para solucionarlo y los criterios por los cuales se eligieron o rechazaron las mismas. Tómese cada una de estas sub-secciones como una iteración de un método de diseño iterativo (tipo ADD).

Por último, en la sección 6, se muestra en detalle la arquitectura final obtenida, junto con ejemplos para el uso y extensión de la misma.

En los apéndices se presentan relevamientos de las características principales de las tecnologías utilizadas para la solución propuesta.

3Especificación de requerimientos



4Análisis de componentes

4.1Virtual Scrum



4.2Issue trackers (Teamwork)



5Diseño


En las secciones subsecuentes se detallan los pasos para realizar el diseño de la arquitectura. Se separan y muestran en orden los diferentes concerns que se ha decidido ir solucionando. El orden en que se eligen los diferentes concerns se ha tomado en base a los requerimientos solicitados y la importancia (en cuanto a dificultad, tiempo que pueda tomar su solución, cantidad de funcionalidad que añade su solución, etc.) que le ha proporcionado el equipo. Así la interoperabilidad (o comunicación) entre VS y Teamwork se ha tratado de resolver primero, dado que esta interfaz debe ser lo suficientemente fácil de extender para poder satisfacer el requerimiento extensibilidad.

5.1Interoperabilidad entre VS y Teamwork


La primera tarea para resolver consiste en definir la interfaz por la cual deben interactuar VS con Teamwork, teniendo en cuenta los atributos de calidad que guían la construcción de la arquitectura. Se ha escogido como el primer quehacer, debido a que se encuentra íntimamente ligado a la extensibilidad del sistema y a su importancia, complejidad y tiempo de investigación que lleva. Además, hay que tener en cuenta como regla empírica en el diseño de software, que las interfaces bien definidas son tan o más importantes que los componentes en sí: el desempeño de un sistema lo establecen sus componentes y cómo los mismos se relacionan. Podemos hacer una analogía con la literatura, si pensamos a los componentes de software como palabras: los poemas más lindos no usan las palabras más lindas; su elegancia recae en cómo las mismas se vinculan.

5.1.1Propuestas para la integración de Teamwork


Se detallan a continuación las posibles propuestas para en la integración de Teamwork con una aplicación cliente escrita en Java (en nuestro caso Virtual Scrum):

5.1.1.1Implementación de una API ofrecida por Teamwork


La primera idea consiste en investigar si existe una interfaz de Teamwork para acceder programáticamente, y, de esta manera, tener acceso a los servicios ofrecidos por dicha API tan solo importando las bibliotecas pertinentes.

Una vez implementados los servicios, se ha de proceder a realizar una abstracción del modelo obtenido para favorecer la permutación de diferentes aplicaciones. Es decir, obtener una arquitectura que sea posible extenderla de manera simple en el caso que se desee cambiar el Teamwork por otra herramienta que brinde la misma funcionalidad.

Hasta el momento, se ha buscado información acerca de si existe una API de Teamwork. La búsqueda se ha realizado en la página de documentación oficial, y en foros oficiales y no oficiales. Se ha obtenido que Teamwork no posee una API para acceder a sus servicios. No obstante, es importante mencionar que ofrece facilidades para el desarrollo de plugins y así integrar aplicaciones third party al mismo.

5.1.1.2Acceso a la Base de Datos de Teamwork


Una de las características de Teamwork es que es posible configurar la base de datos que el mismo utiliza. De esta manera, si se establece que dicha base sea externa a Teamwork1, existe la posibilidad de acceder a las tablas que el mismo crea y realizar operaciones ABM en las mismas.



Existen razones por las que esta idea puede ser objetada. En primer lugar contradice la idea de utilizar una aplicación externa para facilitar la implementación de servicios: el Teamwork sería obsoleto ya que tan solo serviría su modelo de datos y, la funcionalidad que ofrece sería desaprovechada; en su lugar habría que programarla desde cero. Por otro lado, un repositorio de datos es una entidad pasiva; si se modifica alguna tabla por un medio externo a Virtual Scrum, por ejemplo a través de un browser, solo sería posible enterarse de dichos cambios mediante un polling, lo cual desfavorecería notablemente la performance. Por último, la interoperabilidad sería mínima: si se desea, por ejemplo, cambiar de Teamwork a Red Mine, el trabajo sería altamente costoso debido a estar sujetos al modelo de datos.

5.1.1.3Acceso a Teamwork mediante http


Dado que Teamwork es una aplicación web, se ha pensado a la misma como una a la que es posible acceder a sus métodos mediante un protocolo http, tal cual lo hace un usuario a través de un browser. Para poder llevar a cabo este concepto, el browser es un componente necesario; puesto que las respuestas obtenidas por medio de http son documentos HTML, y estos, a su vez, pueden contener elementos embebidos en java script y cambiar dinámicamente el contenido. A este documento complejo se debe, de alguna manera, traducirlo a una representación más sencilla de procesar, como un árbol DOM; del cual es posible extraer los datos obteniendo el valor de las hojas pertinentes.

Una ventaja de este mecanismo de comunicación es que facilita el cumplimiento de la permutación de aplicaciones (requerimiento de extensibilidad): el único requisito es que la herramienta externa sea web; el comportamiento es para todas el mismo y solo cambiarían los parámetros como los nombres de los métodos, o la ubicación en el árbol DOM de donde se obtienen las respuestas. Estos parámetros podrían establecerse a través de un archivo de configuración sin necesidad de modificar el sistema ya implementado.
5.1.1.3.1Traducción de acciones a métodos POST y GET

Virtual Scrum cuenta con un browser interno que podría ser usado solicitar los servicios de Teamwork. Cabe aclarar que a dicho browser conviene realizar ciertas modificaciones para poder ser utilizado:

  • Debe proveer una interfaz para poder ejecutar directamente los métodos GET y POST.

  • Debe soportar inicio y cierre sesión para poder realizar el login y logout en Teamwork.



Dentro de Virtual Scrum, una acción que se debe realizar en Teamwork, se traduce como una solicitud POST o GET al browser del mismo. Este último debe ser modificado de manera que se agregue una capa de abstracción http que soporte inicio y cierre de sesiones (se ha estudiado la posibilidad de utilizar el framework Apache HttpClient para implementar la misma)2.

El mapeo de una acción a un método POST o GET puede realizarse a través de un archivo de configuración. Por ejemplo, puede tener la estructura del siguiente prototipo:



POST









<\action>

El sistema creará un objeto HttpPost con los valores pertinentes y ejecutará un método del mismo para realizar la acción de login.

Un problema con este mecanismo es que la traducción puede ser una tarea muy engorrosa, teniendo en cuenta deben seguirse todas las solicitudes http que realiza Teamwork para cada uno de los posibles servicios que ofrece.
5.1.1.3.2Traducción de acciones a acciones de Selenium

Basándose en la idea de que una serie de métodos POST y GET son, a un nivel más abstracto, disparados por acciones o eventos que se aplican en un documento HTML (la vista de la aplicación web), éste concepto tiene como propósito traducir cada acción que se desea que ejecute Teamwork, por un objeto especial: una acción Selenium. Esto no significa que tengamos que correr una suite de test funcional para ejecutar una acción, sino que se utiliza una porción del framework ofrecido por Selenium RC para poder comunicarse con la aplicación WEB.



Es posible concebir a un objeto Selenium como un softbot que interactúa con un browser. Este softbot puede ser programable y mediante sus métodos es posible disparar eventos en el navegador. Por ejemplo, el método Selenium.click(String) dispara un evento de un click sobre el XPath pasado por parámetro en el documento que se encuentra actualmente sobre el browser en que se halla corriendo Selenium. U obtener datos de la página actual: el método Selenium.getAllLinks():String[] retorna todos los links del documentos en un arreglo (ver Apéndice A para más detalles). Luego, una acción se traduce en una serie de eventos y lecturas sobre un documento.

Si tenemos un documento HTML como sigue:



La serie de acciones Selenium:

  1. selenium.type("FLD_LOGIN_NAME", "vladimir");

  2. selenium.type("FLD_PWD", "correa");

  3. selenium.click("//input[@type='submit']");

Intentará iniciar sesión en Teamwork a “vladimir” con contraseña “correa”.

Una desventaja de este mecanismo es la potencial pérdida de performance, debido a que la comunicación entre los procesos se hace a través de un protocolo de red, y a la existencia de muchos filtros intermedios por los que pasan los mensajes. Aunque Teamwork resida en la misma máquina desde donde se hacen las peticiones (dirección IP loopback) , existen varios procesos que intermedian la petición: la aplicación java que corre el caso de test, el servidor Selenium, el browser, las capas TCP/IP, el servidor HTTP, y finalmente el Teamwork; todo esto de ida y de vuelta. No obstante, las pruebas realizadas hasta el momento pueden considerarse satisfactorias.

Para mejorar la performance de este mecanismo se pueden tener en cuenta los siguientes criterios:

  • Correr el browser en background: no es necesario iniciar la GUI del browser donde se ejecuta Selenium. Incluso es posible configurar el navegador para deshabilitar imágenes, flash, u otros flujos de datos que no ofrecen funcionalidad pero que aumentan considerablemente el tiempo de respuesta.

  • Realizar las acciones con un tiempo de espera mínimo: entre acción y acción que realiza Selenium, el tiempo de espera se puede reducir al mínimo haciendo un análisis del mismo.

  • Modificar el servidor Selenium: dado que el código fuente del servidor Selenium se encuentra disponible, es posible modificar el mismo para que sea un servidor de propósito especial y extraer toda la carga innecesaria, como las clases utilizadas para el test funcional.

Por último, cabe destacar que Selenium ofrece un plug-in para Firefox, el Selenium IDE, el cual permite capturar los eventos que realiza un usuario sobre un documento HTML y exportarlo en un archivo JAVA; facilitando así la creación de las acciones que se deben realizar.

5.1.2Implementación de la propuesta escogida como solución


, probar bien antes>

5.2Tratamiento del flujo de datos



5.3Tratamiento de vistas dinámicas



5.4Integración de los componentes resultantes a VS.



5.5Mapeo de acciones y abstracción de comportamiento



6Arquitectura resultante

6.1Estructura



6.2Comportamiento




c:\users\pablo\desktop\dibujo1.png

6.3Diseño detallado




c:\users\pablo\desktop\disenio\2\all.png

6.4Análisis




6.5Extensibilidad: Proceso para cambiar el issue tracker




Apéndice A. Selenium.



Apéndice B. Contenedores de JavaBeans de Spring




1 Durante la instalación es posible configurar si se utiliza una base de datos interna o una base MySQL.

2 Además de una abstracción del protocolo, el framework ofrece clases de utilidad para encapsular las solicitudes POST y GET, y soporte de cookies.

Añadir el documento a tu blog o sitio web

similar:

1Visión del problema iconHace un año por estas fechas el poeta Enrique Falcón andaba escribiendo...
«El problema es que quienes se postulan para resolver el problema son el problema.»

1Visión del problema iconEl problema no fue hallarte, el problema es olvidarte

1Visión del problema iconLa generación del 98 y el problema de España
«problema de España» por parte de todos o casi todos los que constituyeron el grupo: Unamuno, Ganivet, Azorín, Valle-Inclán, Baroja,...

1Visión del problema iconPlanteamiento del problema

1Visión del problema iconSíntesis del problema

1Visión del problema iconI. Actualidad del problema

1Visión del problema iconTema las tics en el proceso de elecciones del gobierno escolar planteamiento del problema

1Visión del problema iconPlanteamiento del problema del Derecho Internacional Privado

1Visión del problema iconSelección y detección del problema

1Visión del problema iconSintesis descriptiva de la necesidad del problema






© 2015
contactos
l.exam-10.com