Diferencia entre revisiones de «Almacenamiento de votos - 17 18 - G2»
(→Comprobar voto) |
(→Comprobar voto) |
||
| Línea 108: | Línea 108: | ||
'''URL:''' | '''URL:''' | ||
| − | http://egc-votacion1718.es/api/get/comprobar_voto/ | + | http://egc-votacion1718.es/api/get/comprobar_voto/{id_usuario] |
'''Parámetros:''' | '''Parámetros:''' | ||
Revisión del 13:51 30 nov 2017
Contenido
Miembros
- Elena Camero Ruiz
- Marta Carmona Oliva
- José Luis Martínez Quiñones
- Pedro Serrano Ramos
- Jesús Vázquez Argumedo (Coordinador)
Consideraciones
- Debe comunicarse con otros submódulos para obtener los votos y guardarlos.
- Debe comunicarse con otros submódulos para entregar los votos.
- Repositorio donde puede encontrarse el código: https://github.com/AgoraUS-G1-1617/Almacenamiento
- Wiki de la asignatura referente al submódulo: http://1984.lsi.us.es/wiki-egc/index.php/Almacenamiento_1617_G1
Objetivo del subsistema
Su objetivo principal es el almacenamiento de los votos cifrados para garantizar su seguridad.
Enlaces
Enlaces de interés para acceder a toda la información sobre nuestro módulo:
Subsistemas relacionados
- Recuento.
- Cabinas de votación.
- Autenticación.
Gestión de la comunicación
La comunicación se realizará a través de un grupo de Telegram conformado por todos los miembros del equipo. Las reuniones no presenciales se realizarán telemáticamente mediante Skype.
Gestión del trabajo
La gestión del trabajo y la asignación de tareas se llevará a cabo a través de Trello. Se crearán 4 tableros:
* Tareas pendientes: en este tablero se añadirán las tareas que vayan surgiendo y que no estén asignadas ni realizadas aún. * Tareas en proceso: en este tablero estarán las tareas asignadas que estan en proceso de ejecución. * Tareas en revisión: en este tablero estarán las tareas acabadas para que sean revisadas antes de darlas por finalizadas. * Tareas realizadas: en este tablero estarán las tareas ya completadas.
Gestión del código
La gestión del código se realizará a través de GitHub.
Tendremos una rama master que será la que almacene las versiones estables y una rama dev en la que se desarrollará, y cuando el proyecto este listo para desplegar, se realizara un merge desde la rama dev a la rama master.
Gestión de incidencias
Usaremos la herramienta que nos ofrece Github para el control de las incidencias.
Herramientas
Tecnologías elegidas
Subsistema: Almacenamiento de votos Lenguaje/Herramienta: Python 2.7; IDE: Pycharm Sistema de gestión de bibliotecas: pip Bibliotecas: SQLite Nombre_Biblioteca1: <version> Necesita Base de datos: Sí (mysql)
Formato general para detallar incidencias
Las incidencias pueden emplearse no solo para fallos.
Título: <breve título sobre la incidencia> Descripción: <descripción detallada del error> La descripción puede incluir imagenes o la salida emitida por el fallo. Etiquetas: <etiquetas de GitHub para clasificar las incidencias> enhancement: propuesta de mejora bug: fallos encontrados en el sistema help wanted: incidencia que puede ser resuelta por un miembro del equipo pero que ha sido atendida previamente por otro question: (a usar solo entre miembros del equipo) dudas sobre un commit en concreto, hay que referenciar el commit en cuestión
Las incidencias pueden incluirse en Proyectos de GitHub.
Modelo de datos
Los datos que se van a almacenar en nuestra base de datos son:
- id: (int) identificador del voto [pk, autoincrementable]
- id_usuario: (int) identificador del usuario que realiza el voto [fk, not null]
- id_pregunta: (int) identificador de la pregunta a la que está respondiendo [fk, not null]
- id_respuesta: (int) identificador de la respuesta [fk]
Esta sería la estructura de las tablas sobre las que trabajaríamos, un usuario tendrá un voto para cada pregunta, pudiendo registrarse un voto con respuesta a null en el caso del voto en blanco.
API
Las especificaciones de la API podrían variar posteriormente, ya que es posible que alguno los grupos de los que depende este módulo hicieran modificaciones en su modelo de datos a lo largo del desarrollo, lo cuál afectaría al formato de nuestra API.
Dependencias
Este módulo tiene dependencias con los siguientes subsistemas:
- Autenticación: Necesitaremos obtener los datos de autenticación para que un usuario pueda verificar si su voto se registró correctamente,
- Cabinas de votación: Necesitaremos recibir información de todas las cabinas de votaciones para poder almacenar los votos en nuestra base de datos.
- Recuento: El módulo de recuento necesitará obtener todos los votos almacenados en nuestra base de datos para proceder a contabilizarlos.
Comprobar voto
Se hace una petición GET con los parámetros siguientes y se devolverá un JSON con la siguiente información.
URL:
http://egc-votacion1718.es/api/get/comprobar_voto/{id_usuario]
Parámetros:
* id_usuario: Identificador del usuario
Ejemplo:
GET http://egc-votacion1718.es/api/get/comprobar_voto/1
Respuesta:
{
"voto": {
"id": "...",
"id_usuario": "1",
"id_pregunta": "...",
"id_respuesta": "..."
}
}
Pedir voto
Se hace una petición POST con los parámetros siguientes y se devolverá un JSON con la siguiente información.
URL:
http://egc-votacion1718.es/api/post/pedir_voto.json
Parámetros:
* id_usuario: Identificador del usuario (y) * id_pregunta: Identificador de la pregunta (z) * id: Identificador del voto (x)
Ejemplo:
POST http://egc-votacion1718.es/api/post/pedir_voto.json?id=x&id_usuario=y&id_pregunta=z
Respuesta:
{
"voto": {
"id": "x",
"id_usuario": "y",
"id_pregunta": "z",
"id_respuesta": "..."
}
}
Obtener todo
Se hace una petición GET con los parámetros siguientes y se devolverá un boolean.
URL:
http://egc-votacion1718.es/api/get/obtener_todo.json
Parámetros:
*bd_id: Token para verificar que el usuario que realiza la petición tiene permiso de acceso a nuestra base de datos (x)
Ejemplo:
GET http://egc-votacion1718.es/api/get/obtener_todo?bd_id=x
Respuesta:
{
"voto1": {
"id": "...",
"id_usuario": "...",
"id_pregunta": "...",
"id_respuesta": "..."
}
"voto2": {
"id": "...",
"id_usuario": "...",
"id_pregunta": "...",
"id_respuesta": "..."
}
}
