La siguiente vista permite visualizar el dominio del problema mostrando las entidades y relaciones más significativas. Este modelo permitió al equipo definir los servicios y clases que se encontrarán en Web API de la plataforma.
Ilustración 64: Vista lógica Catálogo de elementos
Elemento Descripción
OpenSpace Es la entidad que representa el evento del OpenSpace y tendrá relacionada las propuestas y todos los datos que se generan para un evento así como el resultado del mismo mediante la acción del Moderador.
Propuesta Es la entidad que tiene todos los datos de una propuesta que es ingresada por un usuario y pertenece a las categorías definidas para un OpenSpace.
Categoría Es la entidad que representa la categoría a la que pertenece una Propuesta dentro de un OpenSpace.
Voto Es la entidad que registra los votos de los Usuarios para una Propuesta.
168
Comentario Es la entidad que registra los comentarios de los Usuarios para una Propuesta.
Usuario Es la entidad que representa a los Usuarios del sistema.
Agenda Es la entidad que representa la Agenda del evento y tendrá relacionada, en Sesiones, los distintos Tracks que las componen y dentro de estos las Propuestas ganadoras del evento que serán el contenido del evento.
Sesión Es la entidad que refleja el cronograma de tiempos donde se ejecutan los Tracks que contiene.
Track Es la entidad que refleja el canal donde serán tratadas las propuestas que contiene.
Nota Es la entidad que registra las Notas que realiza el Moderador durante el evento.
Moderador Es la entidad que representa a los Moderadores designados para un OpenSpace.
Encuesta Es la entidad que representa las Encuestas modeladas para que sean realizadas por el Moderador.
Pregunta Es la entidad que representa las Preguntas que contiene una Encuesta.
Respuesta Es la entidad que registra las respuestas obtenidas por el Moderador al realizar una Encuesta.
Tabla 24: Catálogo de elementos de la vista lógica
Como se puede observar en el diagrama previo, la lógica de la plataforma se encuentra basada en las relaciones con la entidad OpenSpace que es el objeto inicial.
Sin embargo la mayor actividad de la aplicación se da entorno a la entidad Propuesta.
Por ello diremos que estas dos son las entidades que dan sentido a toda la plataforma.
En el ciclo de vida de un OpenSpace, un Usuario con rol Administrador genera el Open y selecciona un set de Categorías para registrar Propuestas. Luego, durante el marco de tiempo establecido para ingresar Propuestas, los Usuarios de la plataforma las registran y estas quedan relacionadas al Open.
Es importante destacar, que desde el momento que se registra una Propuesta, queda habilitado el registro de Comentarios para generar la dinámica entre los Usuarios y la persona que propone (sin límite para el registro de comentarios)
169 Llegado el marco de tiempo de votación establecido en el Open, las Propuestas quedan habilitadas para registrar Votos (con tantos Votos, como hayan sido definidos para el Open) y los usuarios registran su Voto.
Una vez cumplido el plazo para la votación establecido en el Open, un Usuario con rol Administrador genera una Agenda, registra el marco de tiempo con las Sesiones y dentro de las mismas registra los Tracks, que serán los contenedores para asociar las propuestas ganadoras. Las Propuestas son asociadas a los Tracks y la agenda es publicada para que los Usuarios con rol Usuario puedan ver la Agenda final.
Previamente al evento un Usuario con rol Administrador generó una encuesta para el evento. El día del evento el Moderador tiene la posibilidad de registrar Respuestas para la encuesta asociada al Open. A su vez también tendrá la posibilidad de registrar notas asociadas a los Tracks y la asistencia al evento.
Finalmente, los reportes de la plataforma se basan en los distintos registros realizados dentro de la misma, los cuales van a permitir a los administradores tomar decisiones o generar información resultante de la ejecución del evento.
Comportamiento
A continuación se presentan los flujos más significativos de la aplicación con el objetivo de brindar al lector una vista del comportamiento de la aplicación y un cierre de todos los elementos y conceptos vistos en la presente sección de arquitectura.
Ingreso al sistema y pantalla principal.
A continuación se presenta la funcionalidad de login, la cual está integrada a Azure Active Directory [52], tanto en la Aplicación Web como en la Web API. A su vez, como parte del flujo del login, se muestra la primera pantalla que recibe al usuario, luego de un login satisfactorio.
170 Ilustración 65: Diagrama de secuencia [124] Ingreso al sistema y Pantalla principal Para lograr la integración, se utilizaron librerías compatibles con los frameworks [28]
utilizados en ambas aplicaciones y a nivel de Azure Active Directory [52] se configuraron las aplicaciones para que se ejecute la autenticación y autorización. La autorización se encuentra definida a nivel de roles de Azure Active Directory [52], los cuales son asignados y en el portal de administración del cliente y luego son informados cuando se realiza la consulta de autenticación y autorización al realizar la comunicación para el login del cliente.
Otro aspecto importante en esta comunicación, es que se delega completamente la pantalla de login y como resultado en cada llamada a Azure Active Directory [52], se retorna un token que es validado en cada interacción desde ambas aplicaciones.
Con esto se resolvió el login y la administración de usuarios en un sistema consolidado para el cliente, no teniendo que administrar dos plataformas con información de los usuarios.
Para el usuario será de gran utilidad ya que no debería recordar otra contraseña más y no dependerá de un administrador cuando olvide la misma; ya que este proceso se encuentra comprendido en la funcionalidad nativa de Azure Active Directory [52].
171 Otro dato importante a destacar recae en el manejo de datos que son expuestos entre la Web API y la Aplicación Web. Notar que entre la interacción entre la Aplicación Web y la Web API se manejan DTO [61] con la información específica para cumplir con el requerimiento de la llamada sin exponer datos del modelo de negocio.
Generación de Agenda automática
En el siguiente diagrama, se presenta la funcionalidad de generación de Agenda automática. Esta opción le permite a un usuario con rol Administrador poder generar de forma sencilla una agenda en base a criterios definidos y que pueden ser
extendidos posteriormente.
Ilustración 66: Diagrama de secuencia [124] Generación de Agenda automática Para lograr el objetivo propuesto, se diseñó en base al patrón de diseño Strategy [125], las estrategias más utilizadas al día de hoy para la generación de la Agenda.
Esto permite al usuario seleccionar la estrategia y el sistema genera automáticamente la agenda y define el orden para las propuestas en base al criterio seleccionado.
Como se puede apreciar se separó la responsabilidad de ordenar las propuestas tanto de la Agenda como de la Propuesta en sí misma. Esto fue diseñado con el objetivo de que tanto la responsabilidad de las estrategias de ordenar, estén en entidades concretas y que puedan ser extendidas sin afectar el modelo primario de negocio, generando una alta cohesión en los elementos mencionados y favoreciendo el mantenimiento.
172 Como en el diagrama anterior, se puede mencionar que tanto los datos de entrada desde la UI [20] para generar la Agenda como los datos de salida para que se pueda mostrar la misma, son DTO [61] con los atributos específicos de la llamada, que en este ejemplo se ha de destacar que el DTO [61] de llamada contiene la selección de la estrategia a aplicar.
173