Diferencia entre revisiones de «Cabina de votaciones - 17 18»

De Wiki de EGC
Saltar a: navegación, buscar
(Mejorado de nuevo el estilo, para permitir que la sección de especificación de la API quede con estilo de código, al igual que las plantillas HTML)
(Eliminada la especificación de la API (se encuentra en el espacio de trabajo) y añadida la descripción del modelo de uso)
Línea 5: Línea 5:
  
 
'''
 
'''
== Objetivo del subsistema ==
+
== Modelo de uso del repositorio ==
 
'''
 
'''
Nuestro trabajo consistirá en realizar el apartado de cabina de votación que consiste en permitir mediante el uso de un conjunto de métodos la posibilidad de que los usuarios puedan votar anónimamente teniendo en cuenta las restricciones posibles que puedan existir.
+
En esta sección se describirá cómo se gestionará el código fuente y otros productos resultados del trabajo realizado por el grupo.
  
'''Tecnologías que se usarán''':
+
Se dispone de dos repositorios, en uno de ellos se guardará la documentación del proyecto (
Subsistema: Cabina de votación<br/>
+
== Commits ==
Lenguaje/Herramienta: Node.js 9.2 (Javascript v8)<br/>
+
Los commits se realizarán cada día que se realice alguna tarea correspondiente con el proyecto y deben tener el siguiente formato:
Bibliotecas: <br/>
 
- restify: 6.3.4 <br/>
 
- rest: 2.0.0 <br/>
 
- lodash: 4.17.4 <br/>
 
- async: 2.6.0 <br/>
 
Sistema de gestión de bibliotecas: npm<br/>
 
Base de datos: No (Aunque es necesaria alguna forma de verificar los votos a partir del usuario encriptado).<br/>
 
  
'''
+
  <razón>:<título>
== APIs y datos que se usarán y devolverán ==
+
  (<colaboradores>)
'''
+
  <cuerpo>
 
+
  (IMPORTANTE
'''Estructura de un voto''':
+
  <detalles importantes>)
 
 
id: (int) identificador del voto [pk, autoincrementable]
 
encrypted_user: (string) identificador del usuario que ha votado de forma encriptada, es única y es posible verificar el voto (voto anónimo) [unique, not null]
 
id_election: (int) identificador de la votación [fk, not null]
 
encrypted_answers: (string) es un string con el contenido de la votación cifrado.
 
 
 
'''Obtención de un voto''':
 
Tipo: GET
 
URL: http://egc-cabina.es/api/get/vote.json?id=x&id_election=y
 
Parámetros: id_vote: Identificador del voto (x)
 
            id_election: Identificador de la elección del voto (y)
 
Formato JSON Ejemplo: Obtención del voto 1
 
 
 
    {
 
        "vote": {
 
            "id": "1",
 
            "encrypted_user": "xgs5fdy2",
 
            "id_election": "165",
 
            "encrypted_answers": "..."
 
        }
 
    }
 
 
 
'''Consulta de votos''':
 
Tipo: GET
 
URL: http://egc-cabina.es/api/get/votes.json?encrypted_user=x&id_election=y
 
Parámetros: encrypted_user: (opcional) Identificador del usuario encriptado. (x)
 
            id_election (opcional) Identificador de la votación (y)
 
Formato JSON Ejemplo: Buscando la votación 165
 
 
 
    {
 
        "votos": {
 
            "vote1": {
 
                "id": "1",
 
                "encrypted_user": "xgs5fdy2",
 
                "id_election": "165",
 
                "encrypted_anwers": "..."
 
            },
 
 
 
            "voto2": {
 
                "id": "2",
 
                "encrypted_user": "whedvsg3",
 
                "id_election": "165",
 
                "encrypted_anwers": "..."
 
            }
 
        }
 
    }
 
 
 
'''Creación de voto''':
 
Tipo: POST
 
URL: http://egc-cabina.es/api/create/vote.json
 
Parámetros: id_user: (int) Identificador del usuario (sin encriptar)
 
            id_election: (int) Identificador de la votación
 
            answers: (list[string]) Lista con las respuestas de la votación de forma ordenada (en la posición 1 estará la respuesta a la pregunta 1 de la votación)
 
Formato JSON Ejemplo: Creando un voto por el usuario 23, la votación 34, el grupo de usuarios 13.
 
 
 
    {
 
        "result": true,
 
        "vote": {
 
            "id": "1",
 
            "encrypted_user": "as5d8gr4",
 
            "id_election": "34",
 
            "id_group": "13",
 
            "encrypted_answers": "..."
 
        }
 
    }
 
 
 
== Plantillas HTML ==
 
 
 
Se tiene pensado que el formato de la cabina de votación sea el siguiente:
 
 
 
Leyenda:
 
- <-- variable --> Esta sección será reemplazada por un texto que sea más cercano a lo especificado en el interior de la sección
 
- <% Comentario %> Comentario
 
- <hX> Un texto de alto tamaño
 
- <\hr/> Una barra horizontal u alguna otra forma de separación.
 
- <\p/> Un parrafo, preferible de una única linea
 
- <\span/> Un parrafo de varias lineas
 
 
 
'''Votación de la pregunta X'''
 
  
    <hX><-- Nombre de la encuesta --></hX><br/>
+
Se describirán cada componente del formato ahora:
    <\hr/><br/>
+
- razón: Consitirá en la causa de la subida del commit, que puede ser uno de los siguientes: fix (arreglo), add (funcionalidad añadida), doc (documentación de código o otros).
    <\p><-- Descripción de la encuesta --><\/p><br/>
+
- título: Resumen, de menos de 20 palabras del commit.
    <\hr/><br/>
+
- colaboradores: Miembros del grupo que han ayudado en la realización del trabajo.
    <\p>Pregunta <-- X --><\/p><br/>   
+
- cuerpo: Explicación más en profundidad del contenido del commit.
    <\span><-- Texto de la preguna X --><\/span><br/>
+
- IMPORTANTE: Sección donde se describe un detalle importante
    <% En el caso de que se trate de una lista de posibles opciones donde sólo se selecciona una %><br/>
+
- detalles importantes: Detalles a destacar para otros miembros del grupo.
        <select><br/>
 
            <option value="<-- Valor de la respuesta -->"><-- Texto de la respuesta --><br/>
 
        </select><br/>
 
    <% En el caso de que se trate de una respuesta donde habrá que poner texto %><br/>
 
        <label...><-- Texto de la pregunta --></label><br/>
 
        <input value="<-- Valor de la pregunta -->" /><br/>
 
    <% En el caso de existir una pregunta donde se requiera una selección y también un input de pregunta, mezclar las dos disposiciones anteriores %><br/>
 
    <\hr/><br/>
 
    <button <% Botón de siguiente pregunta %>>Siguiente pregunta</button><br/>
 
  
'''Final de la votación de la encuesta'''
+
== Ramas ==
 +
La gestión de ramas será la siguiente:
 +
- master: Contendrá una versión funcionando y con las funcionalidades confirmadas por el equipo de integración. Se considera usable para producción
 +
- dev: Contendrá una versión en funcionamiento, pero puede contener problemas de código o conflictos con otras funcionalidades, necesitará un testeo en entorno de pre producción.
 +
- <funcionalidad>: Esta rama contendrá una versión master del código y desarrollará una funcionalidad para la próxima versión del programa.
 +
- <miembro>: Esta rama será personal para cada uno de los desarrolladores y no será modificada por otros miembros del grupo. Podrá contener código en cualquier estado (por ejemplo sin compilar correctamente).
  
    <hX><-- Nombre de la encuesta --></hX><br/>
+
El funcionamiento para pasar de una rama a otra será el siguiente.
    <\hr/><br/>
+
- miembro a funcionalidad: Los miembros que tengan asignada la funcionalidad podrán modificar y realizar merge de la rama personal a la funcionalidad.
    <\p><-- Descripción de la encuesta --><\/p><br/>
+
- funcionalidad a dev: Para poder actualizar dev, se deberá realizar un pull request y se realizarán pruebas de que el funcionamiento de la funcionalidad es correcta).
    <\hr/><br/>
+
- dev a master: Se realizará un nuevo pull request, donde se indicarán los cambios de una versión de master a otra. De nuevo pasará por un periodo de pruebas para asegurar que funciona de forma correcta.
    <\p>Gracias por responder a <-- Nombre de la encuesta --><\/p><br/>
 
    <button>Finalizar</button> <% Con este botón, se enviaría a la cabina de votación el voto y los credenciales del usuario que lo ha creado %><br/>
 

Revisión del 20:29 27 nov 2017

Resumen del trabajo

Nuestro trabajo consistirá en realizar el apartado de cabina de votación que consiste en permitir mediante el uso de un conjunto de métodos la posibilidad de que los usuarios puedan votar anónimamente teniendo en cuenta las restricciones posibles que puedan existir.

Modelo de uso del repositorio

En esta sección se describirá cómo se gestionará el código fuente y otros productos resultados del trabajo realizado por el grupo.

Se dispone de dos repositorios, en uno de ellos se guardará la documentación del proyecto (

Commits

Los commits se realizarán cada día que se realice alguna tarea correspondiente con el proyecto y deben tener el siguiente formato:

 <razón>:<título>
 (<colaboradores>)
 <cuerpo>
 (IMPORTANTE
 <detalles importantes>)

Se describirán cada componente del formato ahora: - razón: Consitirá en la causa de la subida del commit, que puede ser uno de los siguientes: fix (arreglo), add (funcionalidad añadida), doc (documentación de código o otros). - título: Resumen, de menos de 20 palabras del commit. - colaboradores: Miembros del grupo que han ayudado en la realización del trabajo. - cuerpo: Explicación más en profundidad del contenido del commit. - IMPORTANTE: Sección donde se describe un detalle importante - detalles importantes: Detalles a destacar para otros miembros del grupo.

Ramas

La gestión de ramas será la siguiente: - master: Contendrá una versión funcionando y con las funcionalidades confirmadas por el equipo de integración. Se considera usable para producción - dev: Contendrá una versión en funcionamiento, pero puede contener problemas de código o conflictos con otras funcionalidades, necesitará un testeo en entorno de pre producción. - <funcionalidad>: Esta rama contendrá una versión master del código y desarrollará una funcionalidad para la próxima versión del programa. - <miembro>: Esta rama será personal para cada uno de los desarrolladores y no será modificada por otros miembros del grupo. Podrá contener código en cualquier estado (por ejemplo sin compilar correctamente).

El funcionamiento para pasar de una rama a otra será el siguiente. - miembro a funcionalidad: Los miembros que tengan asignada la funcionalidad podrán modificar y realizar merge de la rama personal a la funcionalidad. - funcionalidad a dev: Para poder actualizar dev, se deberá realizar un pull request y se realizarán pruebas de que el funcionamiento de la funcionalidad es correcta). - dev a master: Se realizará un nuevo pull request, donde se indicarán los cambios de una versión de master a otra. De nuevo pasará por un periodo de pruebas para asegurar que funciona de forma correcta.