Frontend y Visualización

Evolución y Gestión de la ConfiguraciónGrado de Ingeniería del Software

Número de grupo (Opera): 10 Tutor: David Benavides

Enlace de proyecto en projETSII: https://projetsii.informatica.us.es/projects/t6xqetftwntyzke2yd4

Enlace wiki:https://1984.lsi.us.es/wiki-egc/index.php/Frontend_y_visualizaci%C3%B3n_de_resultados

1

Integrantes del equipo:

Barquero Sauci, Valentín (valentinbarquero@gmail.com)Bellido Millán, Miguel A. (migbelmil@alum.us.es)Llamas García, Moisés (moillagar@alum.us.es)Martín Rodrigo, Daniel (danmarrod@alum.us.es)Sánchez Navarro, Daniel (dansannavl@alum.us.es)

AUTOEVALUACIÓN

Dedicación en el proyecto en cada uno de los entregables.

Alumno Entregable 1 Entregable 2 Final

Barquero Sauci, Valentín

Bellido Millán, Miguel A.

Llamas García, Moisés

Martín Rodrigo, Daniel

Sánchez Navarro, Daniel

0% = No he podido participar y por tanto debo aceptar tener un cero en el entregable.

50% = He trabajado aproximadamente la mitad que mis compañeros y por tanto merezco la mitad de la nota del trabajo.

100% = He trabajado como el que más y merezco la nota dada al trabajo.

HISTORIAL DE VERSIONES

2

Fecha Versión Detalles Participantes

27/11/2015 1.0 Versión inicial Daniel Martín Rodrigo

16/12/2015 1.1 Realizados la introducción, resumen y gestión del código fuente

Moisés Llamas García

Índice General3

1 Resumen.................................................................................................................. 5

2 Introducción.............................................................................................................5

3 Diario de grupo........................................................................................................5

3.1 Lorem................................................................................................................5

3.2 Ipsum.................................................................................................................5

4 Relación de Hitos.....................................................................................................6

5 Descripción del sistema...........................................................................................6

5.1 Descripción General..........................................................................................7

5.2 Descripción Técnica...........................................................................................7

5.3 Planificación......................................................................................................7

6 Elementos de Control..............................................................................................7

7 Entorno de Desarrollo..............................................................................................7

8 Gestión del código fuente........................................................................................7

9 Gestión de la construcción e integración continua.................................................8

10 Gestión del cambio, incidencias y depuración........................................................8

11 Gestión de liberaciones, despliegue y entregas......................................................8

12 Gestión de la variabilidad........................................................................................8

13 Mapa de herramientas............................................................................................8

14 Conclusiones............................................................................................................8

Referencias......................................................................................................................9

Índice de Tablas4

Tabla 1: Relación de Hitos..............................................................................................10

Índice de FigurasIlustración 1: Arquitectura de Agora@US........................................................................7Ilustración 2: Estructura Organizativa..............................................................................9

5

1 Resumen

6

En el presente docoumento se detalla toda la información acerca del subsitema Frontend y Visualización de resultados. Dicho subsistema pertenece al proyecto Agora@US, aplicación que ofrece un servicio de votaciones de forma segura online.

Este subsistema se realizará con la finalidad de aprender a trabajar en grupo y llevar una gestion de la configuracion del proyecto mencionado anteriormente, que se llevará a cabo dentro de la asignatura Evolución y Gestión de la Configuración, incluida en la titulacion de Grado de Ingeniería del Software.

El sistema Agora@us es un proyecto que se divide en varios subsitemas, de forma que tanto el desarrollo como la gestión del código se realiza de forma independiente en cada subsitema. En nuestro caso, el subsistema a desarrollar es el de Frontend y Visualización de resultados, cuyo objetivo es comunicarse con los subsistemas de Recuento y Moodificación de Resultados, para procesar los datos y posteriormente, visualizarlos para informar al usuario de los resultados de las votaciones.

Las herraminetas usadas para el trabajo son las siguientes:

o Gestión del proyecto: Projetsii.o Gestión de la construcción: Maven, usado para la compilación.o Gestión del código fuente: Git, repositorio de codigo que ofrece un servicio

de control de versiones y centralización del código. o Gestion de despliegue: Openshift, usado para desplegar la aplicación.o Gestión de la calidad: Google CodePro Analytic, herramienta gratuita

ofrecida por Google para mejorar la calidad del software.

7

2 IntroducciónEn esta sección se presenta la arquitectura que tiene el proyecto Agora@US y a continuación, se describe el funcionamiento del subsistema Frontend y Visualización de resultados y de los subsistemas de los que depende.

2.1 Qué es Agora@USPara aprender a realizar la evolución y gestión de un código, se decidió usar

Agora@US, proyecto que surge como ejemplo para aprender la integración entre los subsistemas que forman esta aplicación.

Para el presente curso, cada subsistema debe de obtener el código realizado en el curso 2014/2015, evolucionarlo añadiendo nuevas funcionalidades y/o detectando y corrigiendo errores, integrando finalmente todos los subsistemas obteniendo de nuevo el mismo proyecto realizado en el curso 2014/2015, pero con nuevas funcionalidades y reduciendo los errores a nivel de codificación que se produjeron en el año pasado.

A continuación se muestran los subsistemas que se acordaron el pasado año y a los cuales, la clase debía de adaptarse:

Ilustración 1: Arquitectura de Agora@US

8

2.2 Frontend y Visualización de resultados

Nuestro grupo es el encargado de desarrollar el subsitema de Frontend y Visualización de resultados, cuyo propósito es recibir los recuentos de los votos de las distintas votaciones o referéndums para almacenarlos en una base de datos propia y posteriormente visualizarlos en forma de gráficas, para que el usuario de manera rápida e intuitiva pueda comprobar los resultados de las votaciones.

El recuento de votos (mencionado anteriormente) es realizado por los subsistemas de Modificación de resultados y Recuento de Votos, que se coordinan entre ellos para ofrecer la información adecuada a traves del subsitema de Recuento de Votos.

Desde principios del proyecto, nuestro grupo llegó al acuerdo con el grupo de Recuento de Votos de que la comunicación entre los dos subsitemas sería a traves del uso de API REST, por lo que los datros sería enviados como un JSON con formatos distintos, dependiendo de la API en cuestión.

2.3 Tecnología

Referente a las tecnologías, nos encontrabamos que el código heredado correspondiente a los subsistemas que nuestro grupo debía de desarrollar era diferente. Por un lado, el subsitema de Frontend de Resultados utilizaba el framework Spring e Hibernate mientras que el subsitema de Visualización de Resultados había desarrollado su proyecto usando HTML y JavaScript.

Por tanto, la primera decisión que debe de tomar el grupo es como desarrollar el proyecto que se nos planteaba. Había tres opciones:

Evolucionar el código de ambos subsistemas usando los frameworks usados en el anterior curso.

Migrar el código del subsistema de Frontend de Resultados al framework de Visualización de Resultados.

Migrar el código del subsistema de Visualización de Resultados al framework de Frontend de Resultados.

La primera opcion rapidamente fue descartada, ya que aunque es una opción viable, no estimamos que fuera la mejor opción, puesto que debíamos de integrarnos entre nosotros mismo, además que con el resto de subsistemas. Por tanto, la cuestión era hacia que framewok realizamos la migración.

Finalemente, se realizó la migración del código del subsistema de Visualización de Resultados al framework Spring e Hibernate.

9

10

3 Diario de grupo(Incluirlo en documento aparte)

3.1 LoremLorem ipsum dolor sit amet, consectetuer adipiscing elit. Maecenas porttitor congue massa. Fusce posuere, magna sed pulvinar ultricies, purus lectus malesuada libero, sit amet commodo magna eros quis urna.

Nunc viverra imperdiet enim. Fusce est. Vivamus a tellus.

3.2 IpsumPellentesque habitant morbi tristique senectus et netus et malesuada fames ac turpis egestas. Proin pharetra nonummy pede. Mauris et orci.

Aenean nec lorem. In porttitor. Donec laoreet nonummy augue.

Suspendisse dui purus, scelerisque at, vulputate vitae, pretium mattis, nunc. Mauris eget neque at sem venenatis eleifend. Ut nonummy.

Ilustración 2: Estructura Organizativa

4 Relación de Hitos

Fecha Nombre

11

Equipo 10

P.Manager 5

P.Manager 4

P.Manager 3

P.Manager 2

P.Manager 1

23 de Noviembre 2015 Revisión 01

02 de Diciembre 2015 Revisión 02

09 de Diciembre 2015 Revisión 03

14 de Diciembre 2015 Revisión 04

07 de Enero 2016 2015 Revisión 05

Tabla 1: Relación de Hitos

5 Descripción del sistemaSe explicará el sistema desarrollado desde un punto de vista funcional. Se hará una descripción tanto descriptiva como técnica de sus componentes y su relación con el resto de subsistemas. Habrá una sección que enumere explícitamente cuáles son los cambios que se han desarrollado para el proyecto. En otra sección se presentará la planificación del trabajo y qué tareas se han hecho. Haciendo hincapié en el reparto de tareas. Tenga muy en cuenta lo expresado en la sección 2.2.2 en cuánto a división de tareas.

5.1 Descripción General

5.2 Descripción Técnica

5.3 PlanificaciónPlanificación y Tareas. Hacer hincapié en el reparto de tareas y tener en cuenta el siguiente punto:

“Todos los componentes del equipo deben ser desarrolladores en el proyecto. No se puede dividir el equipo para que unos hagan desarrollo y otros hagan documentación por ejemplo. Para poder poner en práctica los conocimientos debe todo el mundo ser desarrollador/a y trabajar en paralelo. Se podrá cargar más en una persona u otra la parte de desarrollo pero en ningún caso se podrá quitar a alguien de esta labor”.

6 Elementos de ControlSe enumerarán cuáles son los elementos que estarán bajo gestión de la configuración y cómo se va a gestionar la configuración de cada uno de ellos. Es decir, se explicitará la primera tarea de identificación de los Configuration Items (CI) que definan la base line.

12

7 Entorno de DesarrolloSe debe explicar cuál es el entorno de desarrollo que ha usado, cuáles son las versiones usadas y qué pasos hay que seguir para instalar tanto su sistema como los subsistemas relacionados para hacer funcionar el sistema al completo.

8 Gestión del código fuenteSe explicarán los procesos, técnicas y herramientas para la gestión del código del

proyecto. Evite poner información de las herramientas en sí que se pueda encontrar en fuentes bibliográficas o internet. Si es del caso haga referencia a ellas. Céntrese en los aspectos particulares de su proyecto, por ejemplo, ¿cómo se gestionan las ramas en el código? ¿Cómo se aplica un parche (patch)? ¿Cómo se aprueban los cambios? ¿Qué roles existen en la gestión del código?, ¿qué políticas de nombre y estilo se utilizan en el código fuente? ¿Cuál es el usage model del repositorio de código? Cada uno de estos apartados debe estar divididos en secciones.

A la hora de gestionar el código fuente, existen varias herramientas gratuitas que pueden ser de gran utilidad. Primero, lo más importante sería elegir una herramienta en la cual, podamos crear tareas, asignarles un recurso y además, tener un espacio común de comunicación entre los integrantes del equipo.

8.1 Gestores de proyectos Projetsii: es una herramienta online, con la que el equipo se encuentra muy

familiarizado, debido al uso de la herramienta a lo largo de la carrera. Esta herramienta puede ser de gran ayuda a la hora de gestionar los recursos necesarios para este proyecto, y además, gestionar y planificar las tareas, crear diagramas de Gantt, foros, repositorio de código…

GitHub: es una herramienta en la que el grupo no está muy familiarizado, aunque si se conoce las funciones básicas como gestionar tareas del proyecto, uso de su wiki, un gestor de incidencias y un repositorio de código.

El equipo estimó que la planificación es una de las fases más importantes a la hora de abordar un proyecto software como este, por lo que sería necesario usar cuantas herramientas sean oportunas para una mejor planificación. Por consiguiente, se usó projetsii para la creación y asignación de tareas y también se usaría github para gestionar las incidencias, pues usaremos su repositorio de código para alojar el código del proyecto, y se consideró más cómodo usar dicho gestor de incidencias.

8.2 Gestión del códigoComo se mencionó en el apartado anterior, para la gestión del código el equipo

decidió utilizar la herramienta Git, herramienta muy potente, la cual se integra perfectamente con nuestro entorno de desarrollo, en este caso eclipse.

Tras varias sesiones prácticas llevadas a cabo en la asignatura de Evolución y Gestión de la Configuración, rápidamente el equipo se dio cuenta que trabajar

13

directamente sobre la rama master no era lo más recomendable, si no que debían de crearse ramas, en función de la funcionalidad que se fuera a desarrollar en ese momento y mantener en la rama master siempre una versión estable del proyecto.

En primer lugar, en el repositorio se encuentra la rama “Master”. En ella, siempre se mantiene una versión estable del proyecto, por si en alguna ocasión, se pide algún entregable que no esté provisto en el grupo.

Se creará una rama a partir de la rama “Master” y nunca sobre una rama que no sea esta. En esta nueva rama se experimentará nuevas funcionalidades propuestas para el proyecto o la integración de nuevas bibliotecas que supongan un cambio importante sobre la arquitectura de la aplicación.

Para la unión de ramas, se realizará cuando la rama sobre la que se está investigando este integrada la nueva funcionalidad y/o nueva librería y este cambio no puede afectar a la funcionalidad del proyecto.

A continuación, con el objetivo de explicar de forma gráfica para aclarar posibles dudas, se adjunta una imagen, representando lo antes mencionado sobre el proceso de creación y/o unión de ramas.

Ilustración 3: Creación de ramas

8.3 Procedimientos para trabajar con el control de versiones

8.3.1 Pautas para realizar un commitSe decidió de crear un procedimiento común a la hora de realizar los commits, de

forma que se estableció un convenio entre los integrantes del grupo a fin de que al leer el título y descripción de un commit que sea de otro miembro del equipo, fuese lo más claro posible. Los pasos a seguir son los siguientes:

1. Título del commit. Este debe de empezar por una palabra clave en mayúsculas que hará referencia al tipo de cambio que se trata:

i. ADICIÓN[título del commit]ii. CORRECCIÓN[título del commit]iii. APIGET[título del commit]

14

iv. PERSISTENCIA[título del commit]v. CONFIGURACIÓN[título del commit]vi. DESPLIEGUE[título del commit]

2. Una vez especificado el tipo de cambio, en la parte de [título del commit] se expondrá con un poco más de detalle el cambio lógico que supone dicho commit, sin superar los 80 caracteres.

3. Por último, se añadirá una descripción detallada que responda al porqué del cambio y que explique en qué consiste.

8.3.2 Pautas a la hora de crear una incidenciaSe decidió un procedimiento común para todos los integrantes del grupo, a fin

de detallar lo máximo posible una incidencia para que no dé lugar a confusiones por parte de los demás usuarios. Los pasos a seguir son los siguientes:

1. Indicar los pasos a seguir para reproducir el problema.2. Una vez llegado a donde se produce el error, indicar que error se

devuelve3. Explicar con el máximo detalle posible cual es el resultado esperado.4. Indicar la versión del software utilizado de desarrollo y sistema

operativo.

8.3.3 Gestión de conflictosA la hora de gestionar los conflictos que Git no puede resolver de manera

automática, se definió un procedimiento a seguir, para minimizar en la manera de lo posible. Al ser un equipo con una cantidad considerable de personas trabajable, es inevitable que aparezcan futuros conflictos en el código que se deba de solucionar de manera manual.

En primer lugar, se definió un procedimiento para la interacción con el repositorio:

1. git clone. Esto se realizaría solo la primera vez, para obtener en local el código que hubiera en el repositorio.

2. Modificar los ficheros oportunos.3. git pull para actualizar la versión en local.4. git add con los ficheros quye se quiern incluir en el commit.5. git commit. Esto se realizaría utilizando el procedimiento previamente definido

(ver pautas para realizar un commit).6. git push, de la rama sobre la que se esté trabajando.

Tras definir estos pasos a seguir, se tomaron otras medidas con herramientas que faciliten la comunicación entre los integrantes. Para ello, se usó la aplicación web Slack, ya que unifica varios servicios que no oferce otras herramientas y es usado por la mayoría de las empresas para su comunicación interna (para más información, visitar https://slack.com/).

15

Como último recurso, se acordó que si seguidos estos pasos se produce algún conflicto, el desarrollador al que le aparezca dicho conflicto será el encargado de resolverlo.

8.4 RolesDurante el desarrollo del trabajo, podemos diferenciar los siguientes roles:

Coordinador: persona con capacidad para tomar decisiones sobre todos los miembros del equipo, encargado de la comunicación con el resto de coordinadores de los demás subsistemas y de solucionar los conflictos entre los miembros del grupo en caso de que existiesen).

Desarrollador: persona de realizar el código fuente que le han sido asignadas, tomando las decisiones de cuando crear una rama, cuando hacer merge, push, etc.Todos los integrantes tienen el rol de desarrollador, incluso el coordinador.

8.5 Sintaxis del código fuentePara la sintaxis del código fuente hemos usando la aprendida a lo largo de la titulación de Ingeniería Informática-Ingeniería del Software.

“En este apartado se detalla la política que se ha seguido a la hora de escribir el código fuente, con el fin de homogeneizar la sintaxis utilizada.

En primer lugar, los nombres de todas las clases empiezan por mayúscula, y en caso de tener más de una palabra, cada una de las que siguen a la primera también empezarán con mayúsculas.

Por otro lado, los servicios y los repositorios relacionados con las entidades del dominio se denominarán siguiendo el esquema NombreEntidadService yu NombreEntidadRepository respectivamente.

En lo que respecta a los métodos de cada clase, éstos comienzan con minúscula, pero en el caso de que tengan más de una palabra, de la segunda en adelante comienzan con mayúscula.

Por último, para la estructura general del código se ha seguido el esquema de programación indentada usando tabulaciones.”1

1 Para la sintaxis del codigo fuente, esta se ha recogido de la documentación del grupo Frontend de Resultados del curso 2014-2015

16

8.6 Ejercicio8.6.1 Enunciado

Tras realizar la integración de los subsistemas y se establece en la rama “Master” un versión estable de dicho proyecto. Se desea añadir una nueva funcionalidad al sistema heredado. La nueva funcionalidad consiste en permitir a los usuarios realizar donaciones a la aplicación Agora@US mediante la plataforma de pagos seguros Paypal.

En primer lugar, se debe crear una nueva rama sobre la rama Master, que se denominará “DevelopmentPaypal”. Una vez que la rama está creada, debemos de trabajar sobre dicha rama durante el desarrollo y finalmente, cuando la nueva funcionalidad este completamente desarrollada, unir la rama “DevelopmentPaypal” a la rama Master.

8.6.2 Solución

Creación de la nueva rama “DevelopmentPaypal”o $ git branch DevelopmentPaypal

Cambio a la rama “DevelopmentPaypal”o $ git checkout DevelopmentPaypal

Enviar rama al servidoro $ git push origin DevelopmentPaypal

Commit de los cambios realizadoso $ git commit –a

Enviar cambios realizados a la copia del servidoro $ git push

Cambios a la rama “Master”o $ git checkout DevelopmentPaypal

Inserción de la nueva característica a la rama “Master”o $ git merge DevelopmentPaypal

17

9 Gestión de la construcción e integración continua

Similar al apartado anterior se definirán los procesos que se usan a la hora de construir el proyecto, ¿qué herramientas se usan? ¿Cómo se usan? ¿Cada cuánto tiempo se realiza una construcción del proyecto? ¿Qué mecanismos IC se usan? ¿Cómo?, etcétera.

10 Gestión del cambio, incidencias y depuración

¿Qué mecanismos de depuración se usan? ¿Cómo se gestionan los cambios? ¿Qué procesos? ¿Qué roles? ¿Qué estados se manejan? ¿Qué políticas para descartar, fomentar o retardar un cambio?

11 Gestión de liberaciones, despliegue y entregas

¿Qué elementos del proyecto son “entregables”? ¿Cómo se generan? ¿Cómo se identifican? ¿Cómo se gestiona la publicación, la liberación y entrega? ¿Dónde se entrega? ¿Qué roles existen en la entrega? ¿Qué mecanismos de despliegue se definen? ¿Qué procesos? ¿Qué plataformas? ¿Qué herramientas?

12 Gestión de la variabilidad¿Qué mecanismos se usan? ¿Qué mecanismos se podrían usar? ¿En qué niveles se gestiona la variabilidad?

13 Mapa de herramientasDebe dar un esquema de cómo se conectan las herramientas que se usan en el proyecto, qué relaciones tienen o qué relaciones propondría añadir. No olvide explicar bien el mapa de herramientas. Se trata del mapa de herramientas de gestión de la configuración. El mapa de herramientas que se usen para el desarrollo (como bases de datos u otros) no es necesario que aparezca aquí.

13.1 Lista de herramientas

Spring

18

Es un Framework de software libre para Java que está bastante extendido.

Es un Framework de inyección de dependencias y usa programación orientada a aspectos.

Hibernate

Es una herramienta de software libre de mapeo objeto-relacional para Java mediante archivos XML o anotaciones en los beans de las entidades que permiten establecer estas relaciones.

Java

Es un lenguaje de programación orientado a objetos, concurrente y de propósito general, diseñado para tener cuantas menos dependencias de implementación mejor.

Es el lenguaje que usaremos para el desarrollo de nuestro subsistema.

JDK

Java Development Kit (JDK) es un software que provee herramientas de desarrollo para la creación de programas en Java.

Maven

Es una herramienta software para la gestión y construcción de proyectos en Java. Tiene un modelo de configuración de construcción simple basado en XML.

19

Eclipse

Entorno de desarrollo de software libre que cuenta con multitud de plug-ins.

Es el que usaremos ya que permite la integración con Hibernate

JSON

Es un formato ligero para el intercambio de datos que usaremos para intercambiar datos con otros subsistemas.

Git

Es una herramienta de software libre de control de versiones distribuido, diseñado pensando en la eficiencia y confiabilidad del mantenimiento de versiones de grandes proyectos.

MySQL

Es un sistema de gestión de bases de datos relacional, multihilo y multiusuario. Es el que usaremos para nuestro subsistema.

Apache Tomcat

20

Es un servidor que funciona como contenedor web, de servlets y JSP.

OpenShift

Es un producto de computación en la nube de software libre. Sirve para desplegar nuestro subsistema en la nube.

Jenkins

Es un software de integración continua de código abierto escrita en Java. Soporta Git.

SonarQube

Es una plataforma para evaluar código fuente de software libre y usa diversar herramientas de análisis de código fuente.

Slack

21

Es una herramienta de comunicación empresarial con la que crear canales, salas de chat y enviar mensajes directos.

13.2 Mapa de herramientas

14 ConclusionesEnunciar conclusiones en 2 o 3 párrafos y no más de una página.

Referencias

[1] Wiki EGC. https://1984.lsi.us.es/wiki-egc/index.php/2015/2016

[2] J. Webber, S. Parastatidis y I. Robinson. REST in Practice: Hypermedia and Systems Architecture. O'Reilly Media. 2010.

22