Iteración de propuesta de integración (Autenticación 2014-15)

Asistentes

Asistió	Miembro del grupo
✓	Daniel Ayala Hernández
✓	Daniel de los Reyes Leal
✓	Alejandro Sánchez Medina
✓	Juan Carlos Roldán Salvador
✓	Fidel Mazo Delgado
	Juan Luis Casal López

Resultado

Se han tomado las siguientes sobre la propuesta de integración de los subsistemas.

Mapa de integración

Realizar una integración "sandwich" es bajo nuestro punto de vista, la opción más viable.

En primer lugar, se ha mirado el espacio de grupos de cada uno de los subsistemas, elaborando esta tabla:

Subsistema	Servidor web	Base de datos
Autenticación	PHP	MySQL
Creación/administración de votaciones	POJOs (se importarán como un jar)	MySQL
Sistema de modificación de resultados	Java (servidor web no especificado)	MySQL
Almacenamiento de votos	Spring MVC	MySQL
Deliberaciones	Spring MVC	MySQL
Recuento	Spring MVC	MySQL
Creación/Administración de censos	Spring MVC	MySQL
Frontend de Resultados	Spring MVC (antes GWT)	MySQL
Visualización de resultados	HTML, CSS, JavaScript	-
Verificación	POJOs (creemos que se importarán como un jar)	-
Cabina de votación	Python (servidor web no especificado)	MySQL

Como podemos observar, todos los subsistemas utilizar MySQL, lo que permite usar una base de datos única realizando un acuerdo de nombres de tablas en la base de datos.

En segundo lugar, se ha observado que la UI se está haciendo por partes, siendo cada grupo el responsable de la vista que le corresponde. Por ello, debemos realizar un acuerdo de clases CSS para evitar posteriores conflictos. Así, cada grupo realizaría su subsistema sin prestar atención al CSS hasta llegada la integración. Hay casos especiales, como Visualización de resultados, cuyo trabajo depende en gran medida del CSS, en tal caso, se deberían definir clases CSS que no entraran en conflicto con las establecidas en el acuerdo.

Dado que la aplicación tendría una serie de vistas que redireccionarían a otras, se propone realizar un acuerdo de URIs, para que los nombres tengan una forma canónica en la medida de lo posible.

A continuación hemos de resolver la creación de un entorno de despliegue conjunto. Para ello, se propone usar una máquina virtual en la que se desplieguen todos los servicios necesarios.

Por último, tras disponer de todos los proyectos funcionales en un entorno conjunto, sería mucho más fácil realizar la integración con otros grupos de forma común, ya que esta actividad ya se ha realizado de manera aislada en algunos casos.

Acuerdo de nombres

Ya se han acordado los nombres de las tablas de la base de datos en el espacio de discusión de ProjEtsii, pero convendría unificarlo para evitar posteriores conflictos.

Acuerdo de clases

Para tener un único aspecto en la aplicación, esta debería compartir el CSS. Para ello, se podría acordar el uso de ciertas clases CSS y etiquetas HTML en los proyectos.

Por ejemplo, una propuesta podría ser:

   <html>
       <head>

           <title>Agora@US</title>
       </head>
       <body>
           <div class="wrapper">
               <div class="logo">Logo y título de la aplicación</div>
               <div class="menu">Menú de selección de opciones</div>
               <h1>Título de la página

<p>Poner aquí el contenido.

<div class="push">

           </div>
           <div class="footer">
               <p>Copyright</p>

</body>
</html>

Acuerdo de URIs

En la mayoría de los grupos esto se está haciendo de forma descentralizada, lo que puede provocar conflictos entre los subsistemas. Sería conveniente acordar las URIs a usar por cada uno de los grupos para evitar conflictos y tener cierta unidad en la nomenclatura.

Creación de un entorno de despliegue conjunto

Dado que la mayoría de los subsistemas utilizan Spring MVC, y más concretamente la plantilla utilizada el año pasado en Diseño y Pruebas, se podría partir de la máquina virtual Windows que se nos proporcionó en la asignatura. Con esto, los grupos que usaran Spring MVC ya dispondrían del software necesario.

Para los grupos Autenticación y Visualización de resultados se instalaría en un servidor XAMPP.

El grupo Cabina de votación instalaría Python y desplegaría su servidor web.

Los grupos cuyo resultado del proyecto es una librería se importarían a los proyectos (mediante algún método como el uso de un repositorio de dependencias).

En el caso de ser necesaria la instalación de ciertos programas o librerías por alguno de los grupos, estos se instalarían durante su integración.

Antes instalación inicial, hay que resolver algunos problemas:

Uso de varios servidores web en una misma máquina: Conflicto de puertos
Problemas en las versiones utilizadas: La mayoría de los grupos no especifican la versión del lenguaje, framework y base de datos que usan
Cómo comunicar los subsistemas una vez instalados en una misma máquina virtual

Integración con otros grupos

Tras la instalación del software necesario en el entorno, se podrían instalar los proyectos, integrándolos con los ya instalados. El orden que proponemos se basa en el flujo de vistas de la aplicación, desde el momento en el que se loguea un usuario.

El orden de subsistemas a integrar será el siguiente:

Autenticación
Creación/Administración de censos
Creación/Administración de votaciones
Cabina de votación
Almacenamiento de votos
Verificación
Modificación de resultados
Recuento
Frontend de resultados
Visualización de resultados
Deliberaciones

Así, todo grupo dispondría de una primera versión del código del resto de grupos.

Aun así, igual que en el punto anterior, hay algunas cuestiones que deben ser resueltas:

Cómo realizar pruebas durante la instalación de los subsistemas, para ver que no afecta a los subsistemas ya instalados
Posibilidad de creación de un escenario de pruebas (popular la base de datos) conjunto
Guía de realización del update de los proyectos a partir del repositorio compartido, o automatización si fuera posible