Capa de dominio

La capa de dominio es la responsable de implementar las funcionalidades del sistema y de recibir las llamadas de los servicios correspondientes.[35]

9.3.1. DIAGRAMA DE CLASES DE DISEÑO

Debido a que en el diseño hay componentes de software y no conceptos del dominio, hace falta transformar el esquema conceptual mostrado anteriormente con tal de obtener el diagrama de clases de diseño que se muestra a continuación.

9.3.2. DIAGRAMAS DE SECUENCIA

Para elaborar los diagramas de secuencia de diseño se han de definir previamente los contratos de diseños de las operaciones. Los contratos de diseño siguen la siguiente plantilla: Contexto: [Nombre y parámetros de la operación]

Pre: [Condiciones que están garantizadas cuando se llama a la operación] Exc: [Condiciones que impiden la ejecución satisfactoria de la operación] Post: [Cambios de estado que se producen cuando la ejecución acaba

satisfactoriamente]

Es necesario decir que el concepto de precondición no es la misma en especificación que en diseño. En diseño la excepción o las excepciones son las precondiciones de la especificación. A continuación se muestra el contracto de diseño de la operación “Crear evento” a modo de ejemplo:

- Contexto: CapaDominio::newEvento(título: string, fechaHora: dateTime, lugar:string, inscripcionAbierta: boolean, presencial: boolean)

- Pre: El título no está vacío.

- Pre: La fechaHora no está vacío.

- Pre: La inscripcionAbierta no está vacío.

- Exc: Ya existe un evento con ese título.

- Exc: La fecha no es posterior a la fecha actual.

- Post: El sistema crea un nuevo evento con título, fechaHora, lugar,

inscripcionAbierta y presencial. En caso de no indicar lugar, el evento

no será presencial.

Es a partir de estos contractos mediante los cuales se han elaborado los diagramas de secuencia de diseño que se muestran a continuación. Los siguientes diagramas de secuencia son los más significativos del proyecto y son los que más información muestran sobre el sistema a desarrollar.

Figura 18. Diagrama de secuencia de “Iniciar Sesión”.

El primer diagrama corresponde al inicio de sesión. La particularidad que tiene dicho diagrama es que se puede observar todas las clases que intervienen en el inicio de sesión y al final gestiona la redirección de la página web, ya sea una por defecto o a la que el usuario quería acceder.

Figura 19. Diagrama de secuencia de “Consular evento”.

Este segundo diagrama corresponde al caso de uso de consultar un evento, el cual cómo podemos observar si el usuario no está autentificado le redirecciona a la página del login. Si esta autentificado, se lleva a cabo la tarea de obtener los datos pedidos por el usuario. Una vez obtenidos los datos se envía la petición de que genere la vista con los datos obtenidos para poderla visualizar desde un navegador.

En este documento no se van a mostrar el resto de diagramas de secuencias sobre consultas porque son muy similares al mostrado y no aportan mayor información que la ya mostrada.

Figura 20. Diagrama de secuencia de “Crear evento”.

El diagrama anterior muestra como gestiona el sistema para guardar información que proviene del usuario, en este caso un evento. Los datos se envían y lo gestiona Request, en caso de que no se disponga de todos los datos se enviará el error correspondiente y ya gestionará el error la parte de front end. En caso de que este todos los datos necesarios, se lleva la tarea de hacer la conexión con la base de datos y se guardan todos los datos necesarios en las tablas existentes. Por último, se crea una respuesta en formato JSON para el cliente.

En este documento no se van a mostrar el resto de diagramas de secuencias sobre guardar datos porque son muy similares al mostrado y no aportan mayor información que la ya mostrada.

Figura 21. Diagrama de secuencia de “Eliminar evento”.

En el diagrama anterior muestra como el sistema elimina un evento. Si el usuario esta validado se lleva al cabo la tarea de conectarse a la base de datos para verificar que el evento existe, que no dispone de ninguna votación y de que no dispone de ningún asistente. En caso de que suceda lo mencionado devolverá un mensaje indicando que hay datos asociados y que debe borrarlos antes, de esta forma aseguramos de que no se borra nada sin querer. En caso de que todo esté correcto borrará el evento y se notificará que se ha borrado satisfactoriamente. En este documento no se van a mostrar el resto de diagramas de secuencias sobre eliminar datos porque son muy similares al mostrado y no aportan mayor información que la ya mostrada.

Figura 22. Diagrama de secuencia de “Consultar información mediante la API”.

En el diagrama anterior se muestra la secuencia de una consulta de datos mediante la API. Es muy similar al diagrama de consulta de datos visto anteriormente. La única diferencia que hay es que en vez de hacer la tarea de crear una nueva vista con los datos obtenidos se tratan todos los datos obtenidos en la base de datos y se crea un JSON para enviarlo a la aplicación móvil y que dicha aplicación pueda gestionarlo de una manera rápida y eficiente.

Los diagramas de secuencia de la aplicación móvil se podrán ver en el siguiente capítulo. En este documento no se van a mostrar el resto de diagramas de secuencias sobre consultar datos mediante la API porque son muy similares al mostrado y no aportan mayor información que la ya mostrada.