Casos de Uso

Casos de uso de la aplicación.

APLICACIÓN WEB

1 Público: registrarse como usuario

Los usuarios deben poder registrarse en la aplicación aportando un email, nombre y una contraseña (que deberá repetirse dos veces y coincidir entre sí).

El email del usuario no podrá estar repetido en el sistema, se debe informar al usuario de los errores en el proceso de registro.

Este caso de uso se soluciona con la ruta "/registro"

2 Público: iniciar sesión

Suministrando su email y contraseña, un usuario podrá autenticarse ante el sistema. Sólo los usuarios que proporcionen correctamente su email y su contraseña podrán iniciar sesión con éxito.

En caso de que el inicio de sesión fracase, será necesario mostrar un mensaje de error indicando el problema.

En caso de que el inicio de sesión sea correcto se debe dirigir al usuario a la vista que “lista todos los usuarios de la aplicación”

Este caso de uso se soluciona en la ruta "/login" a la cual se redirecciona automáticamente en caso de intentar acceder a una ruta sin estar logueado en la aplicación previamente.

3 Usuario registrado: listar todos los usuarios de la aplicación

Se visualizará en una lista todos los usuarios de la aplicación. Para cada usuario se mostrará su nombre y email.

La lista debe incluir un sistema de paginación y mostrar 5 usuarios por página.

Debe incluirse una opción de menú principal, visible solo para usuarios en sesión que permita acceder al listado de todos los usuarios de la aplicación.

Este caso de uso se soluciona en la ruta "/users/lista-usuarios", añadiendo la funcionalidad de poder buscar por nombre de usuario o email.

4 Usuario registrado: buscar entre todos los usuarios de la aplicación

Incluir un sistema que permita realizar una búsqueda por nombre y email de usuario. El cuadro de búsqueda contendrá un único campo de texto, la cadena introducida en ese campo utilizará para buscar coincidencias tanto en el campo nombre como en el email de los usuarios. Por ejemplo, si escribimos la cadena “mar” deberá retornar usuarios en los que la cadena “mar” sea parte de su nombre o su email.

El resultado de la búsqueda debe ser una lista que muestre las coincidencias encontradas, está lista debe incluir un sistema de paginación y mostrar 5 usuarios por página.

Este caso de uso se soluciona al igual que en el caso anterior en la ruta "/users/lista-usuarios"

5 Usuario registrado: enviar una invitación de amistad a un usuario

Junto a la información de cada usuario presente en la vista de “listar todos los usuarios de la aplicación” debe aparecer un botón con el texto “agregar amigo”. Al pulsar el botón el usuario en sesión esta enviando una invitación de amistad a ese usuario.

No se debe poder enviar una invitación a un usuario que ya es amigo o a un usuario al que ya se la ha enviado otra previamente.

Este caso de uso se soluciona mediante un botón en la lista de usuarios de la aplicación que permite agregar a un usuario como amigo (que no esté agregado como amigo ya)

6 Usuario registrado: listar las invitaciones de amistad recibidas

Se visualizará en una lista todas las invitaciones de amistad recibidas por el usuario identificado en sesión. Para cada invitación se mostrará el nombre del usuario de la aplicación que solicito la amistad.

Debe incluirse una opción de menú principal, visible solo para usuarios en sesión que permita acceder al listado de todas las invitaciones de amistad recibidas.

La lista de invitaciones debe incluir un sistema de paginación y mostrar 5 invitaciones por página.

Este caso de uso se soluciona con la ruta "/users/lista-peticiones"

7 Usuario registrado: aceptar una invitación recibida

Junto a cada invitación mostrada en la lista de invitaciones de amistad recibidas se debe incluir un botón con el texto “aceptar”, al pulsar este botón la invitación de amistad debe desaparecer de la lista de invitaciones y el usuario que la envió pasará a ser un amigo del usuario en sesión y viceversa (A es amigo de B, B es amigo de A).

Este caso de uso se soluciona en la misma ruta que el caso de uso anterior, pero mediante dos botones que permiten aceptar o rechazar peticiones de amistad.

8 Usuario registrado: listar los usuarios amigos

Se visualizará en una lista todos los usuarios amigos del usuario en sesión. Para cada usuario se mostrará su nombre y email.

La lista de amigos debe incluir un sistema de paginación y mostrar 5 usuarios por página.

Debe incluirse una opción de menú principal, visible solo para usuarios en sesión que permita acceder al listado de todos los amigos del usuario en sesión.

Este caso de uso se soluciona con la ruta "/users/lista-amigos"

SERVICIOS WEB

S.1 Identificarse con usuario – token

El servicio recibe un nombre de usuario y una contraseña, en caso de que exista coincidencia con algún usuario almacenado en la base de datos retornará un token de autenticación. Sí no hay coincidencia retornará un mensaje de error de inicio de sesión no correcto.

Este caso de uso se soluciona con la petición documentada aquí: https://redsocialsdi.gitbook.io/nodejs/api#autenticar-get-token

S.2 Usuario identificado: listar todos los amigos

El servicio retorna una lista con los identificadores de todos los amigos del usuario identificado.

Para permitir listar los amigos el usuario debe de estar identificado en la aplicación, por lo tanto, la petición debe contener un token de seguridad valido.

Este caso de uso se soluciona con la petición documentada aquí: https://redsocialsdi.gitbook.io/nodejs/api#get-all-friends

S.3 Usuario identificado: Crear un mensaje

El servicio debe permitir crear nuevos mensajes.

Las propiedades del mensaje son: emisor, destino, texto, leído (true/false), por defecto el mensaje se crea como no leído.

Para permitir crear un nuevo mensaje, el usuario destino debe ser amigo del usuario identificado, por lo tanto, la petición debe contener un token de seguridad valido y el usuario identificado con el token debe ser amigo del usuario destino.

Este caso de uso se soluciona con la petición documentada aquí: https://redsocialsdi.gitbook.io/nodejs/api#add-mensaje

S.4 Usuario identificado: Obtener mis mensajes de una “conversación”

El servicio recibe el identificador de dos usuarios y retorna una lista con todos los mensajes para cuales esos usuarios son emisor y receptor o viceversa (mensajes enviados en ambos sentidos para esos dos usuarios).

Para permitir obtener los mensajes de una conversación el usuario identificado debe ser el emisor o receptor de los mensajes, por lo tanto, la petición debe contener un token de seguridad valido.

Este caso de uso se soluciona con la petición documentada aquí: https://redsocialsdi.gitbook.io/nodejs/api#get-all-mensajes

S.5 Usuario identificado: Marcar mensaje como leído

Este servicio permite marcar un mensaje como leído, la propiedad leído debe tomar el valor true. El servicio recibe el identificador del mensaje.

Para permitir cambiar el estado de un mensaje, el usuario identificado debe ser el receptor del mensaje, por lo tanto, la petición debe contener un token de seguridad valido.

Este caso de uso se soluciona con la petición documentada aquí: https://redsocialsdi.gitbook.io/nodejs/api#update-mensaje-leido

APLICACIÓN JQUERY

C.1. Autenticación del usuario

Debe permitir la autenticación a través de un formulario donde se solicite el correo y la contraseña del usuario, se debe informar si la autenticación no se realiza con éxito.

La solución a este caso de uso está explicada aquí: https://redsocialsdi.gitbook.io/nodejs/funcionalidad#autenticacion-del-usuario

C.2. Mostrar la lista de amigos

Una vez autenticado se debe redirigir al usuario a su lista de amigos (no aplicar ningún sistema de paginación). Dentro de esta lista se debe ofrecer la posibilidad de filtrar los amigos por su nombre. Por ejemplo, con un cuadro para insertar texto situado la parte superior de la lista.

La solución a este caso de uso está documentada aquí: https://redsocialsdi.gitbook.io/nodejs/funcionalidad#mostrar-la-lista-de-amigos

C.3. Mostrar los mensajes

Al pulsar sobre el nombre de un usuario de la lista de amigos se debe mostrar el chat, el cual incluye:

  • La lista con todos los mensajes relacionados con ese usuario y el usuario identificado en la aplicación.

  • Formulario para enviarle un nuevo mensaje a ese usuario (Funcionalidad en caso de uso C.4)

La lista de mensajes debe actualizarse en tiempo real, sin necesidad de recargar la página ni de pulsar ningún botón. Es decir, debe haber un proceso automático que compruebe cada segundo si hay nuevos mensajes en esa conversación cada N segundos.

La solución a este caso de uso está documentada aquí: https://redsocialsdi.gitbook.io/nodejs/funcionalidad#mostrar-los-mensajes

C.4. Crear mensaje

Desde la vista de chat el usuario debe poder crear un nuevo mensaje para ese amigo. Siendo el usuario el emisor y el amigo el destino.

La solución a este caso de uso está documentada aquí:https://redsocialsdi.gitbook.io/nodejs/funcionalidad#crear-mensaje

C.5. Marcar mensajes como leídos de forma automática

Al entrar en un chat de un amigo todos los mensajes no leídos deben ser marcados como leídos automáticamente. Junto a cada mensaje mostrado en el chat debe incluirse un <leído> al final (si tiene el estado leído).

Al igual que la lista de mensajes el estado de los mensajes debe actualizarse en tiempo real, sin necesidad de recargar la página ni de pulsar ningún botón. Es decir, debe haber un proceso automático que compruebe cada segundo si hay nuevos mensajes en esa conversación / o cambios en los estados leído.

C.6 Mostrar el número de mensajes sin leer

Se debe mostrar junto al nombre de cada amigo (en la lista de amigos) cuantos mensajes sin leer hay en esa conversación.

El número de mensajes sin leer debe actualizarse en tiempo real, sin necesidad de recargar la página ni de pulsar ningún botón. Es decir, debe haber un proceso automático que compruebe cada segundo si hay nuevos mensajes.

C.7 Ordenar la lista de amigos por último mensaje

Se debe incluir un mecanismo de ordenación automático de la lista de amigos, de forma que los amigos se ordenen por la antigüedad en la creación del último mensaje (teniendo en cuenta mensajes tanto enviados como recibidos). Las conversaciones más recientes deben tener prioridad respecto a las menos.

Last updated