Iteración de propuesta de integración (Autenticación 2014-15)
Contenido
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>
<meta charset="utf-8">
<link rel="stylesheet" href="layout.css" />
<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</h1>
<p>Poner aquí el contenido.</p>
<div class="push"><!-- Div utilizado para poner un footer fijo --></div>
</div>
<div class="footer">
<p>Copyright</p>
</div>
</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
