Embed Size (px)
Citation preview
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
HISTORIAL DE VERSIONES
1
Fecha Versión Detalles Participantes
27/11/2015 1.0.0 Versión inicial Daniel Martín Rodrigo
16/12/2015 1.1.0 Realizado la introducción Moisés Llamas García
16/12/2015 1.2.0 Realización del mapa de herramientas Miguel Ángel Bellido Millán
17/12/2015 1.3.0 Realizado resumen y la gestión de cambios, incidencias y depuración.
Moisés Llamas García
18/12/2015 1.4.0 Realizado gestión del código fuente Moisés Llamas García
21/12/2015 1.5.0 Realizado el entorno de desarrollo Moisés Llamas García
22/12/2015 1.5.1 Cambiado la resolución del ejercicio sobre la gestión del código fuente
Moisés Llamas García
22/12/2015 1.5.2 Cambiada la imagen del mapa de herramientas
Miguel Ángel Bellido Millán
23/12/2015 1.6 Añadido la descripción sobre la funcionalidad de Angular
Daniel Sánchez Navarro
2
Índice General
1 Resumen.................................................................................................................. 8
2 Introducción.............................................................................................................9
2.1 Qué es Agora@US.............................................................................................9
2.2 Frontend y Visualización de resultados...........................................................10
2.3 Tecnología.......................................................................................................10
3 Relación de Hitos...................................................................................................11
4 Descripción del sistema.........................................................................................11
4.1 Estado anterior................................................................................................11
4.2 Cambios que se proponen...............................................................................13
4.3 Cambios de AngularJS.....................................................................................15
4.4 Historias de usuario.........................................................................................17
5 Elementos de control.............................................................................................18
5.1 Gestión del cambio para componentes...........................................................20
6 Entorno de Desarrollo............................................................................................20
6.1 Máquina Virtual...............................................................................................21
6.2 Java..................................................................................................................21
6.3 Eclipse.............................................................................................................21
6.4 Maven.............................................................................................................22
6.5 EGit..................................................................................................................24
6.6 MySQL.............................................................................................................26
6.7 Tomcat............................................................................................................27
7 Gestión del código fuente......................................................................................29
7.1 Gestores de proyectos....................................................................................29
7.2 Gestión del código...........................................................................................29
7.3 Procedimientos para trabajar con el control de versiones..............................30
7.3.1 Pautas para realizar un commit...............................................................30
7.3.2 Pautas a la hora de crear una incidencia..................................................31
7.3.3 Gestión de conflictos................................................................................31
7.4 Roles................................................................................................................31
3
7.5 Sintaxis del código fuente...............................................................................32
7.6 Ejercicio...........................................................................................................33
7.6.1 Enunciado................................................................................................33
7.6.2 Solución....................................................................................................33
8 Gestión de la construcción e integración continua...............................................39
9 Gestión del cambio, incidencias y depuración......................................................40
9.1 Gestión del cambio..........................................................................................40
9.2 Gestión de incidencias.....................................................................................40
9.3 Gestión de depuración....................................................................................41
9.4 Ejercicios......................................................................................................... 42
9.4.1 Ejercicio 1.................................................................................................42
9.4.2 Ejercicio 2.................................................................................................43
10 Gestión de liberaciones, despliegue y entregas....................................................44
11 Gestión de la variabilidad......................................................................................45
12 Mapa de herramientas..........................................................................................46
13 Conclusiones..........................................................................................................50
Referencias....................................................................................................................51
4
Índice de TablasTabla 1: Relación de Hitos..............................................................................................11Tabla 2: Historia de usuario Donación...........................................................................17Tabla 3: Historia de usuario Interfaz móvil....................................................................17Tabla 4: Historia de usuario Encuestas ciudad...............................................................17Tabla 5: Historia de usuario Encuestas más votadas.....................................................18Tabla 6: Historia de usuario Comentarios......................................................................18Tabla 7: Elementos de configuración.............................................................................19Tabla 8: Dependencias de Maven..................................................................................20
5
Índice de FigurasIlustración 1: Arquitectura de Agora@US........................................................................9Ilustración 1: Comunicación del subsistema de visualización........................................12Ilustración 2: Diagrama de componentes de subsistemas.............................................13Ilustración 3: DIAGRAMA DE COMPONENTES TRAS INTEGRACIÓN...............................14Ilustración 4: Estructura de AngularJS; Scripts de AngularJS; Estructura de las vistas...15Ilustración 5: Fichero app.js con el modo HTML5..........................................................16Ilustración 6: Ejemplo de controlador en controllers.js.................................................16Ilustración 7: Ejemplo de redirección a través de un método en un controlador de Spring.............................................................................................................................16Ilustración 3: VirtualBox.................................................................................................21Ilustración 4:Java...........................................................................................................21Ilustración 5: Eclipse......................................................................................................22Ilustración 6: Importando Maven..................................................................................22Ilustración 7: Configuración del archivo setting.xml......................................................23Ilustración 8: Maven......................................................................................................23Ilustración 9: Instalación EGit........................................................................................24Ilustración 10: Añadir vista de Git..................................................................................25Ilustración 11: Clonando un repositorio existente.........................................................25Ilustración 12: Creación de base de datos.....................................................................26Ilustración 13: MySQL....................................................................................................26Ilustración 14: Configuración Tomcat............................................................................27Ilustración 15: Configuración Tomcat II.........................................................................28Ilustración 16: Apache Tomcat......................................................................................28Ilustración 17: Creación de ramas..................................................................................30Ilustración 18: Creación de rama DevelopmentPaypal..................................................34Ilustración 19: Cambio a la rama DevelopmentPaypal..................................................35Ilustración 20: Publicando la rama DevelopmentPaypal en el servidor.........................36Ilustración 21: Añadiendo los commits a la rama DevelopmentPaypal.........................37Ilustración 22: Uniendo la rama DevelopmentPaypal....................................................38Ilustración 23: Creación de incidencia...........................................................................41Ilustración 24: Historial de incidencias..........................................................................41Ilustración 25: Creación de incidencia...........................................................................42Ilustración 26: Cerrar incidencia....................................................................................42Ilustración 27: Spring.....................................................................................................46Ilustración 28: Hibernate...............................................................................................46Ilustración 29: Java........................................................................................................46Ilustración 30: Java Development Kit (JDK)....................................................................47Ilustración 31: Maven....................................................................................................47Ilustración 32: eclipse....................................................................................................47
6
Ilustración 33: JSON.......................................................................................................47Ilustración 34:git............................................................................................................47Ilustración 35:MySQL.....................................................................................................48Ilustración 36: Apache...................................................................................................48Ilustración 37: Openshift................................................................................................48Ilustración 38:Jenkins....................................................................................................48Ilustración 39:SonarQube..............................................................................................49Ilustración 40: Slack.......................................................................................................49Ilustración 41: Mapa de herramientas...........................................................................49
7
1 Resumen
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.
8
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
9
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.
10
Finalemente, se realizó la migración del código del subsistema de Visualización de Resultados al framework Spring e Hibernate.
3 Relación de Hitos
Fecha Nombre
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
4 Descripción del sistemaSe presenta detalles técnicos y funcionales de los subsistemas heredados y los
cambios a nivel estructural y funcional que se pretenden introducir.
4.1 Estado anterior
Los subsistemas de Visualización y de Frontend de los resultados se encontraban separados pues fueron desarrollados por grupos diferentes en el curso anterior. Visualización se comunicaba mediante peticiones asíncronas al subsistema Frontend y con el subsistema de Creación y administración de censos para obtener los datos que se iban a mostrar. En concreto solicitaba dos formatos de JSON correspondientes a la lista de encuestas y a los recuentos con las respuestas. Visualización para mostrar las gráficas hacia uso de la librería Highcharts en javascript.
11
Por otro lado, tenemos que Frontend se comunica con Recuento que es el que envía información sobre los recuentos realizados de los votos en una encuesta. Estos datos son persistidos y accesibles a Visualización.
A continuación, presentamos un diagrama de secuencia de la comunicación que se producía en el sistema heredado desde la perspectiva de visualización.
Se presenta también un diagrama de componentes en el que se muestra la conexión entre subsistemas.
12
Ilustración 2: Comunicación del subsistema de visualización
4.2Ca
mbios que se proponen
Se analiza el estado actual de los subsistemas de Visualización y Frontend de resultados, y se procede a la integración del código de Visualización con el de Frontend para aprovechar la utilidad que ofrece el framework de Spring y Hibernate en el que ha sido desarrollado este último.
13
Ilustración 3: Diagrama de componentes de subsistemas
Ilustración 4: DIAGRAMA DE COMPONENTES TRAS INTEGRACIÓN
Se pretenden realizar algunos cambios de funcionalidad como de estructura, los cuales destacamos a continuación:
- En primer lugar, se estudia la posibilidad de que la aplicación se haga responsive, esto es, que pueda la interfaz de usuario ajustarse a las pantallas de los dispositivos móviles. Para ello se investigan diferentes tecnologías y se opta por la integración de Bootstrap en la aplicación.
- Se decide añadir código haciendo uso de “Apache Tiles” mediante JSP, pero es más tarde se explora la alternativa de usar “AngularJS”. La aplicación funcionaba con el componente “Apache Tiles” que facilitaba el funcionamiento del Modelo Vista Controlador. Los cambios de “AngularJS” se detallan más adelante.
- Se decide estudiar la posibilidad de usar postgreSQL como SGBD en lugar de MySQL.
- Se estudia la posibilidad de añadir la funcionalidad de que los usuarios puedan realizar donaciones a la aplicación. Se estudian diferentes formas de hacerlo y se decide el uso de “Paypal”.
14
- Se pretende añadir nuevas estadísticas sobre las encuestas y sus resultados como:
Número de encuestas realizadas por ciudad o lugar Las preguntas con más respuestas
- Se desea añadir comentarios a los resultados de una encuesta.
4.3 Cambios de AngularJSA continuación se detallan los cambios realizados para la correcta integración y
funcionamiento de “AngularJS” con los componentes ya existentes en el proyecto del año pasado.
Uno de los cambios más importantes fue la eliminación de “Apache Tiles” de nuestro proyecto, eliminando la configuración que permitía el mapeo de las vistas y se cambión la página de inicio a “index.html” con un formato que permite el uso de “AngularJS” con sus correspondientes módulos y variables. Tras realizar este cambio teníamos que añadir un nuevo mecanismo que nos permitiese mapear las vistas, por lo que se creó una nueva estructura para que “AngularJS” pudiese mapear correctamente las vistas:
Ilustración 5: Estructura de AngularJS; Scripts de AngularJS; Estructura de las vistas
El fichero “index.html” es el fichero principal, en el cual mediante “AngularJS” insertaremos las diferentes vistas que se quieran mostrar, teniendo además incluidos en la cabecera los scripts correspondientes para el correcto funcionamiento de “AngularJS”.
En el fichero “app.js” se encuentra la definición de la aplicación de angular y como se mapean las rutas de las url dentro del contexto de la aplicación de “AngularJS”. Aquí es donde se decide, en función de la url, que vista se va a cargar y con qué controlador.
15
Ilustración 6: Fichero app.js con el modo HTML5
En el fichero “controllers.js” es donde se definen los controladores que se cargarán y ejecutarán en función del fichero “app.js” y la url de dirección. Además es necesario decirle a “AngularJS” que use el “modo HTML5”, el cual ayuda a la redirección.
Ilustración 7: Ejemplo de controlador en controllers.js
Tras realizar esto, nos dimos cuenta de que no era suficiente, ya que si se introducía manualmente la url en el navegador, obteníamos un “404 page not found” (ya que no había interacción con el servidor) por lo que fue necesario crear un controlador con “Spring framework” que redireccione al controlador de “AngularJS” a través de la url (incluyendo /#/ justo antes de la url para decirle a “AngularJS” que se encargue de la redirección. Esto es posible gracias al “modo HTML5”.
Ilustración 8: Ejemplo de redirección a través de un método en un controlador de Spring
También se cambiaron los controladores a controladores rest, de forma que devuelvan objetos JSON para que angular se encargue de usarlos en las vistas. Para realizar pruebas se han creado otros controladores de Spring que devuelven JSONs, de forma que podemos probar la aplicación como si consumiésemos una API externa.
Respecto a las pruebas con “AngularJS”, aún no podemos realizarlas de forma automática, ya que la forma de probar AngularJS se realiza mediante Karma.js y Protractor.js, los cuales necesitan Node.js para funcionar. Esta opción se ha descartado de momento debido al aumento considerable de tamaño del proyecto y las
16
dificultades que planteaba a la hora del despliegue. Aun así se están buscando alternativas.
4.4 Historias de usuarioA continuación, se hace una descripción de las historias de usuario referentes a los cambios citados con anterioridad:
Tabla 2: Historia de usuario Donación
ID: 1 Nombre: DonaciónPrioridad: 4Estimación: 4Descripción: Como administrador quiero poder recibir donaciones para que los
usuarios contribuyan al mantenimiento de la aplicaciónDependencias:
Ninguna
Pruebas de aceptación:
Realizar donación y comprobar que se ha ingresado en la cuenta
Tabla 3: Historia de usuario Interfaz móvil
ID: 2 Nombre: Interfaz móvilPrioridad: 1Estimación: 4Descripción: Como usuario quiero poder acceder a la visualización de los resultados
desde un dispositivo móvil para consultar los resultados en cualquier parte.
Dependencias:
Ninguna
Pruebas de aceptación:
Realizar donación y comprobar que se ha ingresado en la cuenta
Tabla 4: Historia de usuario Encuestas ciudad
ID: 3 Nombre: Encuestas ciudad
Prioridad: 2Estimación: 4
17
Descripción: Como usuario quiero poder visualizar la frecuencia de encuestas por ciudades para que poder conocer cuáles son las ciudades con más actividad.
Dependencias:
Ninguna
Pruebas de aceptación:
Visualizar el número de encuestas por ciudad
Tabla 5: Historia de usuario Encuestas más votadas
ID: 4 Nombre: Preguntas más votadas
Prioridad: 3Estimación: 4Descripción: Como usuario quiero poder ver las preguntas que más participación han
tenido para conocer en qué temas se suele votar más.Dependencias:
Ninguna
Pruebas de aceptación:
Listar las preguntas con más respuestas
Tabla 6: Historia de usuario Comentarios
ID: 5 Nombre: ComentariosPrioridad: 5Estimación: 4Descripción: Como usuario quiero poder comentar los resultados de una votación para
realizar un análisis de los resultados.Dependencias:
Ninguna
Pruebas de aceptación:
Comentar los resultados de una encuesta y comprobar que el comentario se ha almacenado.
5 Elementos de controlLos elementos de configuración se identifican en la siguiente tabla:
18
Elementos de configuraciónMemoria del proyectoMáquina virtual de desarrollo y despliegueCódigo fuente integrado de Frontend y visualizaciónComponentes(depedencias .jar de maven)
Tabla 7: Elementos de configuración
Con respecto a la nomenclatura a utilizar, podemos definir el formato para los elementos de configuración. El formato será el de X.Y.Z donde X identifica cambios relevantes y mayores en el elemento como solución de un problema de integración o la adición de un nuevo apartado, Y cambios medios que necesiten un pequeño análisis y Z cambios menores de errores locales que se corrigen de manera rápida.
A continuación, se enumeran los artefactos (componentes de terceros) que se deben tener en cuenta para la gestión de la configuración. Cabe destacar que la nomenclatura que se utiliza para los componentes es la usada por maven.
Artefacto Versiónspring-context 3.2.4.RELEASEspring-webmvc 3.2.4.RELEASEspring-orm 3.2.4.RELEASEspring-tx 3.2.4.RELEASEspring-aspects 3.2.4.RELEASEspring-data-jpa 1.3.4.RELEASEspring-security-web 3.1.4.RELEASEspring-security-config 3.1.4.RELEASEspring-security-taglibs 3.1.4.RELEASEspring-test 3.2.4.RELEASEjackson-databind 2.6.2jackson-annotation 2.6.2jackson-core 2.6.2javax.inject 1aspectjrt 1.7.4tiles-core 2.2.2tiles-servlet 2.2.2tiles-jsp 2.2.2mysql-connector-java 5.1.26hibernate-entitymanager 4.2.3.Finalhibernate-c3p0 4.2.3.Finalhibernate-validator 4.3.1.Finalservlet-api 2.5jsp-api 2.0jstl 1.2displaytag 1.2
19
standard 1.2.2junit 4.11joda-time 2.2slf4j-log4j12 1.7.5
Tabla 8: Dependencias de Maven
5.1 Gestión del cambio para componentes
En el caso de que sea necesario añadir o modificar un componente se deberá:
1. buscar la versión más actualizada2. realizar pruebas para comprobar y verificar que todo funciona como
anteriormente usando esa versión3. en el caso de incompatibilidad, buscar una versión más antigua compatible con
el resto de y realizar pruebas4. verificar que el problema se ha solucionado5. documentar los cambios realizados
20
Ilustración 10:Java
Ilustración 9: VirtualBox
6 Entorno de DesarrolloA continuación, se detallan el entorno que hemos usado, además de otras
herramientas complementarias al entorno de desarrollo. Es importante prestar atención a las versiones instaladas, pues de lo contrario, no se puede asegurar el correcto funcionamiento de la aplicación.
6.1 Máquina VirtualEl equipo de desarrollo ha querido simular al máximo el entorno de desarrollo
que se encontrará en una empresa profesional. Es por ello que todo el trabajo ha sido desarrollado en una máquina virtual. Esto tiene una serie de ventajas, como que no desperdiciamos los recursos de nuestra máquina física. En cualquier momento, si necesitamos asignarle más recurso para la realización del proyecto, podremos asignárselos.
La máquina virtual usada para este proyecto ha sido VirtualBox, en la que debemos de instalar la versión 4.2 o superior. Podemos descargarnos esta máquina virtual desde su página oficial (https://www.virtualbox.org/wiki/Downloads).
6.2 JavaNecesitamos de un compilador Java. Para ello, vamos a usar JDK en su versión 1.7, el cual lo podemos encontrar en la siguiente página (http://www.oracle.com/technetwork/java/javase/downloads/jdk8-downloads-2133151.html?ssSourceSiteId=otnes)
21
Ilustración 12: Importando Maven
6.3 EclipseDebido a la gran familiarización de todos los desarrolladores con el entorno de desarrollo Eclipse, se ha decidido usar Eclipse, en su versión Eclipse Indigo. Lo podemos encontrar para descargárnoslo desde su página oficial (https://www.eclipse.org/downloads/)
Ilustración 11: Eclipse
6.4 MavenEsta herramienta es usada para la construcción de nuestro proyecto, en el cual
se encontrarán todas las dependencias que son necesarias para el desarrollo de éste. Maven lo podemos integrar con nuestro entorno de desarrollo mediante un plugin que se encuentra dentro del Marketplace de eclipse. Los pasos para instalar y configurar este plugin son los siguientes:
1. Debemos de dirigirnos a la página oficial de Maven (https://maven.apache.org/download.cgi) y descargarnos su última versión. Una vez descargado, debemos de descomprimir el paquete en el lugar que consideremos más adecuado.
2. Desde eclipse, debemos acceder al menú “Windows>Preference”, escribimos “maven” y seleccionamos en el submenú que nos aparece “Installation”. Nos mostrará la versión de maven que instalamos en el paso anterior. Debemos de seleccionar la versión de maven que descargamos en el paso anterior.
22
Ilustración 12: Importando Maven
Como podemos ver, se nos ha seleccionado el archivo setting.xml. Este archivo contiene la configuración global del entorno. En el siguiente paso veremos cómo configurar nuestro propio setting.xml
3. En el mismo submenú, debemos de seleccionar el apartado “User Setting”, para configurar el arhivo setting.xml con la configuración que deseemos.
Ilustración 13: Configuración del archivo setting.xml
4. Configuración del archivo pom.xml. Este archivo será el que contenga todas las dependencias que necesitemos para desarrollar el proyecto. Para ello, basta con ver el repositoriode maven (http://repo1.maven.org/maven2/) y ver qué dependencias tiene y añadir las dependencias de la forma: <dependency>
<groupID>…..</ groupID ><artefactID>….</artefactID><version>…</version><scope>….</scope>
</dependency>Nota: el scope puede ser compile, test o runtime, dependiendo de en qué fase queremos tener disponible la dependencia.
Ilustración 14: Maven
23
6.5 EGitEGit es un plugin, que podemos encontrar en el Marketplace de eclipse y sirve
para poder usar el repositorio de git, dentro del IDE eclipse, sin tener que usar la consola.
Para instalar esta herramienta, debemos de seguir lo siguientes pasos:
1. En el menú de eclipse, debemos de seleccionar “Help> Install New Software” y en buscador poner http://dowload.eclipse.org/egit/updates-2.3#sthash.Dv02tyGo0dpuf y seleccionar “Eclipse Git Tem Provider” y as continuación, seleccionamos “Next”
Ilustración 15: Instalación EGit
2. Una vez que tenemos descargado el plugin, debemos de conectarnos a nuestro repositorio de nuestra cuenta de git, para realizar nuestro primer “git clone” y poder empezar a trabajar en nuestro repositorio local. 2.1 Colocar la vista de git en nuestro entorno de desarrollo. Para ello, en el
menú, seleccionamos “Windows>Show View” y seleccionamos Git Repositories
24
Ilustración 16: Añadir vista de Git
2.2 Añadir un repositorio existente en Git. Para realizar este paso tendremos que realizar:- Añadir la URL de nuestro repositorio de Github- Añadir el correo y la contraseña de nuestro usuario de Github
Ilustración 17: Clonando un repositorio existente
25
6.6 MySQLPara almacenar los datos de las encuestas que son recibidos por el subsistema de
recuento, el equipo de desarrollo ha decidido usar una base de datos conocida, como es MySQL, en su versión 5.5. La podemos descargar en el siguiente enlace: (https://dev.mysql.com/downloads/windows/installer/5.5.html)
Para configurar la base de datos solo debemos de crear una instancia, a la que llamaremos localhost y crear una cuenta de administrador cuyas credenciales son:
- Usuario: root- Contraseña: V3rY=$tR0nG=P@$$w0rd$
Una vez que tenemos nuestra cuanta de administrador, el siguiente es un script para crear la base de datos. El script es el siguiente:
Ilustración 18: Creación de base de datos
Una vez que la base de datos ha sido creada, en el panel donde se encuentran las bases de datos podremos ver como se ha creado una nueva con el nombre “egc-frontend”.
Ilustración 19: MySQL
26
6.7 TomcatTomcat es un servidor de aplicaciones. Está muy bien integrado con eclipse, es por ello por lo que el equipo de desarrollo estimó oportuno usar este servidor. La versión que vamos a usar es la 7.0 y la podemos descargar desde el siguiente enlace (https://tomcat.apache.org/download-70.cgi). Los pasos para la instalación es la siguiente:
1. Buscar el servidor tomcat (previamente descargado y descomprimido en la carpetas elegida). Para ello, debemos de dirigirnos a Windows>preferences>servers>runtime enviroments:
Ilustración 20: Configuración Tomcat
27
2. Hacemos click en “add” y seleccionamos “Apache Tomcat v7.0” y pulsamos el botón “next”, en lo que tendremos que seleccionar la carpeta donde instalamos tomcat en el paso 1 y luego pulsaremos el botón “finish”
Ilustración 21: Configuración Tomcat II
3. Cuando tenemos el servidor iniciado, debemos de comprobar que el puerto usado es el correcto. Para ello, hacemos doble click en “Tomcat v7.0 Server” en la vista de servidores y seleccionamos el puerto como 8080 que es el que utiliza por defecto.
Ilustración 22: Apache Tomcat
28
7 Gestión del código fuente
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.
7.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.
7.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 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.
29
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 23: Creación de ramas
7.3 Procedimientos para trabajar con el control de versiones
7.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]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.
30
7.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.
7.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/).
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.
7.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).
31
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.
7.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.
1“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 código fuente, esta se ha recogido de la documentación del grupo Frontend de Resultados del curso 2014-2015
32
7.6 Ejercicio7.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.
7.6.2 Solución
Nos dirigimos a “Team>Switch To>New Branch” y en la vista que nos aparecerá creamos la nueva rama con nombre “DevelopmentPaypal” quedando la vista como la mostrada:
33
Ilustración 24: Creación de rama DevelopmentPaypal
Nota: debemos de esperar a que eclipse construya el workspace. Esto puede llevar un tiempo, dependiendo de la conexión a internet.
Nos dirigimos a “Team>Switch To>other” y marcamos la rama creada en el paso anterior y seleccionamos el botón “checkout”:
34
Ilustración 25: Cambio a la rama DevelopmentPaypal
Nos dirigimos a “Team>Push to Upstream” para publicar la nueva rama en el servidor:
35
Ilustración 26: Publicando la rama DevelopmentPaypal en el servidor
36
Para realizar los cambios oportunos hasta añadir la nueva funcionalidad, se hará commit sobre la rama creada. Para hacer commit, deberemos de dirigirnos a “Team>Commit”:
Ilustración 27: Añadiendo los commits a la rama DevelopmentPaypal
Nota: Para realizar un commit correctamente, debemos de seguir las pautas definidas en el presente documento (ver pautas para realizar un commit)
Para enviar los cambios realizados al servidor, debemos de dirigirnos a “Team>Push to Upstream”
Nos cambiamos a la rama “master”, realizando el mismo proceso que el seguido en el primer apartado.
Por último, debemos de realizar un “merge”. Para ello, debemos de dirigirnos a “Team>Merge” y seleccionamos la rama “DevelopmentPaypal” para fusionarla con la rama en la que estamos actualmente, que será siempre la “master”:
37
Ilustración 28: Uniendo la rama DevelopmentPaypal
38
8 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.
39
9 Gestión del cambio, incidencias y depuración
Dado el tipo de proyecto que se va a abordar, evolucionar un código heredado a une versión en la que incluya nuevas funcionalidades, el cambio es un hecho de que va a ocurrir. Además, al ser un proyecto en el que está dividido en varios subsistemas el cual, deben de integrarse, todo ello es sinónimo que en el futuro surgirán problemas
Por todo ello, es importante mantener definido una serie de pautas para realizar un cambio o como crear una incidencia y tener procedimientos de depuración para conseguir un código lo más correcto posible.
9.1 Gestión del cambioEn el presente documento, procedimos a explicar de forma breve como se
procedería en el caso que fuera necesario. En concreto, se hizo referencia al procedimiento para crear una rama (ver procedimiento).
Por otro lado, en la herramienta usada para la gestión del proyecto (projetsii), el desarrollador correspondiente deberá de asignarse la tarea correspondiente a la que vaya a realizar, que podrá ser, realizar una nueva funcionalidad (siguiendo los pasos de creación de ramas descritos anteriormente) o realizar una parte de la documentación, la cual deberá de explicar en la tarea el tiempo dedicado y en que versión de la documentación se realizó.
9.2 Gestión de incidenciasEs importante definir una serie de pautas a la hora de realizar una incidencia.
Esta es vista por todos los miembros del equipo, incluso por los miembros que están desarrollando otro subsistema. Para ello, con anterioridad se definió una pautas a seguir a la hora de crear una incidencia (ver pautas).
Las incidencias son creadas mediante la herramienta GitHub, en la opción “issues”, opción muy útil ya que al crear la incidencia, se envía una notificación al correo electrónico de todos los miembros que estén en dicho repositorio.
40
Ilustración 29: Creación de incidencia
Una vez que una incidencia ha sido resuelta, debe de cerrarse, quedando registrada en un historial de incidencias, que puede ser consultado por cualquier miembro del equipo, para posibles aclaraciones de futuras incidencias. A continuación se muestra una imagen del historial de incidencias, la cual podemos ver que podemos aplicar diversos tipos de filtros, que será de gran utilidad a la hora de listar cierpos tipos de incidencias.
Ilustración 30: Historial de incidencias
9.3 Gestión de depuraciónCuando existe una incidencia, es necesario solucionarla con la mayor brevedad
posible. Para tener claro que hay que hacer, es necesario definir un proceso para que cualquier persona, sin conocer el código que intenta corregir el error pueda resolverlo.
El primer paso es identificar la incidencia y cual es el motivo por el que se está produciendo. Para ello, es necesario reproducir los pasos descritos en la incidencia, para llegar al error.
Dado que el error puede ser de dos motivos, existen dos procedimientos a seguir:
1. Si el error es de ejecución, el procedimiento sería el estudio de la traza de errores mostrada, con el fin de reconocer el origen del fallo.
41
2. Si el error es de tipo lógico, se usará el depurador de Java, mediante puntos de ruptura.
Una vez que el error se ha corregido, debe de realizarse diferentes pruebas de modo que se pueda asegurar que el error ha sido corregido completamente.
9.4 Ejercicios9.4.1 Ejercicio 19.4.1.1Enunciado
Se tiene una versión totalmente funcional de la aplicación, y se quiere que esta esté desplegada en Internet. Esta tarea es asignada a un desarrollador, que tras varios intentos, crea una incidencia debido a que obtiene un error que no tiene la capacidad de solucionar. Otro desarrollador, lee la incidencia y decide ayudarle con su error, hasta que consigue solucionarlo y que finalmente, la aplicación quede desplegada en Internet.
9.4.1.2Solución El primer desarrollador, tras varios intentos, es incapaz de solucionar la tarea
que se le fue asignada, por lo que decide crear una incidencia.
Ilustración 31: Creación de incidencia
Otro desarrollador, al ver la notificación en su correo electrónico decide ver todas las incidencias que hay para poder ayudar a este desarrollador. Tras estudiar la traza arrojada, finalmente identifica el error, corrigiéndolo y finalmente, reportando como ha solucionado el error, cerrando la incidencia.
Ilustración 32: Cerrar incidencia
42
9.4.2 Ejercicio 29.4.2.1Enunciado
Se desea añadir una nueva funcionalidad a la aplicación. Esta funcionalidad es usar la librería AngularJS, para mejorar de esta forma el HTML.
9.4.2.2SoluciónEn primer lugar, es el coordinador del grupo quien decide si se lleva a cabo la
incorporación de la nueva funcionalidad, analizando el impacto que tendría el proyecto, analizando los posibles riesgos que puedan surgir, llegando finalmente a la conclusión si se hace o no.
Si el coordinador opta por añadir la nueva funcionalidad, este deberá de crear la tarea y/o subtareas correspondientes para la realización de dicha funcionalidad, asignándole a dicha tareas los recursos que él estime necesarios.
El desarrollador al que le has sido asignada la tarea, deberá de crear una rama correspondiente, uniéndola finalmente cuando la tarea asignada esté desarrollada completamente.
43
10 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?
44
11 Gestión de la variabilidad¿Qué mecanismos se usan? ¿Qué mecanismos se podrían usar? ¿En qué niveles se gestiona la variabilidad?
45
12 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
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
46
Ilustración 36: Java Development Kit (JDK)
Ilustración 35: Java
Ilustración 34: Hibernate
Ilustración 33: Spring
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.
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
47
Ilustración 41:MySQL
Ilustración 40:git
Ilustración 39: JSON
Ilustración 38: eclipse
Ilustración 37: Maven
subsistema.
Apache Tomcat
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
48
Ilustración 46: Slack
Ilustración 45:SonarQube
Ilustración 44:Jenkins
Ilustración 43: Openshift
Ilustración 42: Apache
Es una herramienta de comunicación empresarial con la que crear canales, salas de chat y enviar mensajes directos.
13.2 Mapa de herramientas
Ilustración 47: Mapa de herramientas
13 ConclusionesDurante el desarrollo del trabajo, el equipo ha podido comprobar que la mayor
dificultad que se puede encontrar de cara al desarrollo de cualquier aplicación software es la organización entre los distintos grupos de desarrollo.
La integración con los demás subsistema que forman el proyecto de Agora@US ha sido el principal problema, así como la utilización de diferentes tecnologías para su desarrollo. Ha faltado una organización, antes de que cada subsistema empezará a desarrollar nuevas funcionalidades en sus subsistemas correspondientes. Si esta organización se hubiera llevado a cabo, el proceso de desarrollo y su posterior integración hubiera sido más fácil.
Otro aspecto a destacar, ha sido el conocimiento de las nuevas herramientas conocidas a lo largo del curso. Antes de empezar la asignatura de Evolución y Gestión de la Configuración desconocíamos herramientas tan importantes de cara al mundo
49
empresarial, como puede ser un sistema de control de versiones como puede ser git, o un servidor de integración continua como Jenkins.
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.
50
