Vistas
9.1. Contexto
9.2. Vista de Loader
9.3. Vista de Agents
9.4. Vista de InciManager
9.6. Vista de Paquetes
9.7. Vista de Despliegue
En los próximos párrafos se describirán algunas de las vistas identificadas y se documentarán de acuerdo con las instrucciones definidas en la guía de aprendizaje.
| Vista | Stakeholders | Restricciones | Atributos de calidad | Escenarios |
|---|---|---|---|---|
| Context | ST-01, ST-02,ST-03, ST-04, ST-05, ST-06 | TC001, TC002, TC006 | AT008, AT011, AT013 | 8, 11, 13, 24, 30 , 32 |
| Loader | ST-01, ST-02 ST-03,ST-04, ST-06 | TC001, TC002, TC004, TC005, TC006, OC002 | AT003, AT004, AT007, AT008, AT010, AT011, AT013, AT023 | 3, 4, 7, 8, 10, 11, 13, 15, 24, 29, 30 , 32 |
| Agents | ST-01, ST-02, ST-03,ST-04, ST-06 | TC001, TC002, TC003, TC006, TC007 | AT001,AT002, AT006, AT008,AT009, AT011, AT012,AT013, AT014, AT015 | 1,2,6,8,9,11, 12,13,14,16,24, 27, 30, 32, 33 |
| InciManager | ST-01, ST-02,ST-04, ST-06 | TC001, TC002, TC006, TC007, TC008 | AT001,AT008, AT011, AT013, AT014,AT015, AT016, AT021, AT022 | 1,8,11,13,14,16,17,18, 22,23,24,30,31, 32, 33 |
| InciDashboard | ST-01, ST-02,ST-05, ST-06 | TC001, TC002, TC006, TC007, TC008 | AT001,AT008, AT011, AT013, AT014,AT016, AT019, AT021,AT023, AT024, AT025 | 1, 8, 11, 13, 14, 17,18, 20, 21, 22, 24, 25, 26, 30, 31, 32, 33 |
| Paquetes | ST-01, ST-02, ST-06 | TC002, TC008, OC003 | AT023 | 24, 31 |
| Despliegue | ST-01, ST-02, ST-06 | TC008 | AT001, AT014, AT016 | 1, 14, 18, 31 |
La vista de sistema describe los dos subsistemas en interacción, así como sus interfaces.
| Elemento | Propiedades |
|---|---|
| Loader | Se encarga de la introducción de las listas de agentes, así como sus tipos, en el sistema. Lee un fichero xls con los datos de los agentes y un fichero csv con los tipos de estos. Crea las claves. Añade los emails para los usuarios dados de alta. |
| Agents | Es el módulo usado por los agentes para comprobar que han sido dados de alta y opcionalmente para hacer el cambio de clave u otros datos. También lo utilizarán para enviar las incidencias al sistema. |
| DataBase | Este módulo encapsula los accesos a la base de datos. |
| IncidenceManager | Módulo encargado de enviar (producir) incidencias a través de Kafka. Se comunica con Agents para recoger agentes de la base de datos a través de peticiones POST en formato JSON. |
| StreamKafka | Módulo que conecta, en tiempo real, el módulo IncidenceDashboard e IncidenceManager |
Los datos de los agentes se introducen en el sistema a través de la interface ReadList del módulo Loader. Para cada usuario, se crea una clave y se emite un email con todos los datos del usuario. Los tipos de agentes se cargan desde un fichero en formato CSV.
Posteriormente se envían a la base de datos a través del servicio AgentService.
El módulo Agents permite al usuario entrar en sesión pidiendo los datos al módulo DataBase a través de la interfaz AgentsService. Agents también permite cambiar datos de agentes enviando peticiones web a través del controlador ChangeInfoController.
InciManager, por su parte, envía peticiones POST a métodos del controlador AgentController del módulo Agents. Por ejemplo, el método showInfo del controlador devolverá un agente que encontrará en la base de datos. Permitirá, por tanto, loguearse a agentes a través de peticiones web en el controlador HomeController, permitiéndoles enviar incidencias a través de la interfaz KafkaProducer, y ver un histórico de todas las incidencias que ha enviado.
El módulo InciDashboard muestra la lista de incidencias que tiene cada operario asignadas, y les permite gestionarlas. El módulo InciManager será el encargado de enviar las incidencias a través del producer de Kafka, y Dashboard, a través de la interfaz KafkaConsumer, las guardará en la base de datos y las asignará a los operarios.
Se podrán ver estadísticas, de forma gráfica, de las incidencias almacenadas en el sistema.
| Interface | Tipo | Tecnología | Propiedades |
|---|---|---|---|
| ReadList | Interface | Invocación mediante línea de comandos | Se invocará como un programa en consola |
| Interface | Tipo | Tecnología | Propiedades |
|---|---|---|---|
| AgentController | Interface | Servicio Web | Controlador que implementa métodos para peticiones HTTP relacionadas con mostrar información de agentes. |
| ChangeInfoController | Interface | Servicio Web | Controlador que implementa métodos para peticiones HTTP relacionadas con el cambio de datos en agentes. |
| Interface | Tipo | Tecnología | Propiedades |
|---|---|---|---|
| AgentService | Interface | Invocación a Método | Inserta agentes en la base de datos. |
| AgentsService | Interface | Invocación a Método | Devuelve datos de agentes en la base de datos. |
| ChangeInfoService | Interface | Invocación a Métodos | Actualiza datos de agentes en la base de datos. |
| OperadorService | Interface | Invocación a Método | Devuelve operarios de la base de datos. |
| IncidenceService | Interface | Invocación a Método | Devuelve o inserta incidencias en la base de datos. |
| Interface | Tipo | Tecnología | Propiedades |
|---|---|---|---|
| HomeController | Interface | Invocación a Método | Permite, a través de peticiones HTTP, entrar en la vista principal del agente logueado. |
| Interface | Tipo | Tecnología | Propiedades |
|---|---|---|---|
| KafkaProducer | Interface | Invocación a Método | Produce mensajes al stream de Kafka |
| KafkaConsumer | Interface | Invocación a Método | Consume mensajes al stream de Kafka. |
Permite cargar agentes desde un archivo Excel, y guardarlos en la base de datos. Se ejecuta de forma totalmente independiente del resto de módulos.
Permite a los usuarios poder acceder al sistema para comprobar que han sido dados de alta, usando la información recibida en el email. Los usuarios podrían no acceder directamente mediante un navegador Web, sino a través de un sistema externo que invoca el módulo como un servicio Web.
Este módulo encapsulará las operaciones de acceso a la base de datos así como la tecnología a utilizar.
Permite enviar incidencias en tiempo real a agentes registrados en la aplicación. A los agentes que las envían se les pedirá cierta información de las incidencias, como la localización, el título, la descripción, una lista de campos clave-valor o etiquetas.
Permite asignar incidencias a operarios para su posterior gestión por estos. Permite, además, gestionar qué campos de incidencias son críticos (solo los administradores). Las incidencias enviadas en tiempo real actualizan la lista de incidencias de los operarios. Además, se permiten ver estadísticas de las incidencias del sistema.
Módulo que permite enviar incidencias en tiempo real, entre el módulo IncidenceManager (producer) e IncidenceDashboard(consumer).
Las decisiones que han llevado a este diseño son:
| Escenario | Atributos de calidad | Justificación |
|---|---|---|
| 8 | AT008 | Las contraseñas de todos los usuarios de la aplicación están debidamente encriptadas con funciones hash de Java, con una sal concreta. |
| 13 | AT013 | El procesamiento y envío de incidencias debe hacerse de forma rápida, permitiendo enviar varias de forma continuada y por distintos agentes. |
| 24 | TC002 | Escenario obvio. |
| 30 | TC006 | Cada módulo tiene sus propias pruebas. Los módulos que tienen interfaz gráfica de usuario, tienen pruebas de Selenium y de Cucumber, además de pruebas con Junit para probar repositorios y modelo. Los que no tienen, contienen una serie de pruebas unitarias que comprueban el correcto funcionamiento de los servicios y repositorios de acceso a datos, así como las clases del modelo. |
La vista de Loader muestra el primer nivel de descripción de los componentes.
| Elemento | Propiedades |
|---|---|
| Parser | Lee los datos de entrada del Excel (así como del fichero CSV que contiene los tipos de agentes), y los transforma en un contenedor de objetos que puede ser recorrido para su inserción en la base de datos. También crea el usuario/password de los agentes, y el identificador usado para la comunicación. Durante el diseño y la implementación hay que partir este componente en los subcomponentes necesarios para separar todos estos servicios y hacerlo de manera que se cumplan los atributos de calidad AT002, AT003, AT004 y AT007. |
| Business | Encapsula todas las operaciones de base de datos usando interfaces parapermitir el acceso a la base de datos. |
| ReportWriter | Recibe cadenas de información con los datos del usuario que fue imposible de dar de alta y las razones de dicho fallo y escribe un registro en un fichero de texto secuencial, indicando toda la información necesaria para poder revisar visualmente los fallos. |
El componente Parser recibe los ficheros de entrada Excel y CSV y, mediante un parser específico para cada fichero, los convierte en objetos. Añade a estos objetos el identificador (usuario) y el password, y lo añade a la base de datos.
Si se producen errores en la carga de datos (DNI duplicados, campo DNI vacío, etc.) o si el componente de la base de datos devuelve un error, esta información se escribe en un fichero de LOG mediante la interface LogWriter y el componente ReportWriter.
Si aparecen otras situaciones de error se pueden documentar usando el mismo componente ReportWriter.
| Interface | Tipo | Tecnología | Propiedades |
|---|---|---|---|
| ReadList | Interface | Invocación a Métodos | Lee el fichero de Excel con los datos de una lista de ciudadanos. |
| Loader | Port | Crea los subcomponentes del parser necesarios para procesar el fichero de entrada. | |
| InsertAgent | Interface | Invocación a Métodos | Accede al servicio de AgentService para añadir el agente a la base de datos |
| Interface | Tipo | Tecnología | Propiedades |
|---|---|---|---|
| AgentService | Interface | Invocación a Métodos | Recibe un objeto con la información para insertar/modificar/eliminar en la base de datos. |
| AgentServiceImpl | Port | En cada método llama a los métodos execute de lainterfaz Command. | |
| Command | Interface | Invocación a Métodos | Interfaz encargada de definir el método execute, que redefinirán las clases definidas en AgentService. |
| CommandExecutor | Port | Clase que se encarga de ejecutar el método execute() de una clase de tipo Command, de tal manera que las operaciones llevadas a cabo por el execute() queden persistentes en la base de datos, abriendo un contexto de persistencia. |
| Interface | Tipo | Tecnología | Propiedades |
|---|---|---|---|
| LogWriter | Port | Clase estática que añade al fichero log una línea pasada por parámetro. |
Introduce las listas de ciudadanos en el sistema a partir de ficheros Excel formados por filas de ciudadanos, cada una con la siguiente información (excepto la primera fila que contiene las cabeceras):
- Nombre (y apellidos para las Personas) : String
- Email (con un formato acorde a las convenciones de correo electrónico) : String
- Tipo (representa el tipo de agente) : int
- Identificador (será único para cada agente, así como su nombre de usuario) : String
- Localización (opcional para las Personas y Entidades) : String
La invocación se hará mediante un programa batch ejecutado en línea de comando por el administrador del sistema. Durante la importación las listas de ciudadanos, se creará un usuario por cada ciudadano, cuyo nombre de usuario coincidirá con el correo electrónico y se generará una contraseña aleatoria. La combinación adecuada de email/contraseña permitirá al usuario entrar al sistema, acceder a su información y participar en el portal.
Este componente también creará los emails personales comunicando al usuario que ha sido añadido al Sistema de Incidencias, e informando de su clave de acceso.
Actualiza la base de datos. Ver 9.1.2.4.3.
Guarda en un fichero de texto la información de los errores producidos en el proceso de conversión. La información básica a guardar es:
- Identificador del usuario del que se ha obtenido el error
- Descripción del error (con toda la información necesaria)
Ver 9.1.
Las decisiones que han llevado a este diseño son:
| Escenario | Atributos de calidad | Justificación |
|---|---|---|
| 3 | AT003 | Prever una interfaz y un objeto que pueda estar vacío para el informe de errores (WriteReport) facilita la modificabilidad en caso de añadir nuevos tipos de registros posteriormente. |
| 4 | AT004 | Prever el posible cambio a otro formato de salida. |
| 7 | AT007, TC004 | Está diseñado para cargar los datos un fichero Excel y un fichero CSV.El Parser recibe estos ficheros y los parsea. |
| 8 | AT008 | La utilización de una base de datos relacional con acceso mediante SQL puede permitir a los alumnos verificar que los datos han sido cargados adecuadamente |
| 10 | AT010 | El sistema permite al administrador chequear que los usuarios se han cargado correctamente mediante la ejecución de las pruebas. |
| Elemento | Propiedades |
|---|---|
| Agents | Se accede a través de una petición POST (usuario, contraseña, kind) y devuelve una cadena de texto en formato JSON cuyo contenido será diferente en caso de que exista o no. Además, también implementa la posibilidad de cambiar la clave del agente y ver su información mediante una interfaz de usuario. |
| Repository | Componente que accede a la base de datos. |
El Sistema de Incidencias invoca Agents enviando una petición POST (usuario, contraseña y kind) y se comprueba si dicho usuario existe. Para ello, se invoca al servicio AgentsService que, a su vez, llama al repositorio, que busca el agente en la base de datos. Se devuelve un JSON con los datos del agente o un código de error en caso de no haya tenido éxito la petición.
Además, se incluye la opción de que un agente pueda cambiar su contraseña (clave) si así lo desea mediante el servicio ChangeInfoService, que al igual que el AgentsService, accede a la base de datos a través de la interfaz Repository.
Se pueden crear tantas interfaces como elementos a modificar o usar la anterior con algún tipo de código para definir los datos a modificar.
| Interface | Tipo | Tecnología | Propiedades |
|---|---|---|---|
| AgentController | Interface | Invocación a Métodos | Recibe una petición POST y genera una cadena de texto en formato JSON con los datos del agente en caso de éxito o un código de error en caso contrario. |
| AgentsService | Interface | Servicio Web | Implementa la lógica de negocio a la hora de buscar un agente. |
| ChangeInfoController | Interface | Invocación a Métodos. | Permite el cambio de contraseña (clave) de un agente. |
| ChangeInfoService | Interface | Servicio Web | Implementa la lógica de negocio para actualizar la contraseña de un agente. |
| showInfo | Port | Recoge los datos de la petición POST y se los envía al servicio AgentsService. Además lanza código de error en caso de que los parámetros no sean válidos o no exista el agente. | |
| findAgent | Port | Implementado en el servicio AgentsService, llama al repositorio que accede a la base de datos para buscar el agente especificado. | |
| updateAgent | Port | Implementado en el servicio ChangeInfoService, actualiza la contraseña de un agente haciendo una llamada al método correspondiente en AgentRepository. | |
| changePassword | Port | Recoge los datos de la petición para el cambio de contraseña y se la manda al servicio ChangeInfoService. |
| Interface | Tipo | Tecnología | Propiedades |
|---|---|---|---|
| AgentRepository | Interface | Repositorio | Se encarga de comunicar el módulo agents con la base de datos. |
| findAgent | Port | Implementado en el repositorio AgentRepository busca un agente en la base de datos a partir de su nombre de usuario, contraseña y kind. Si tiene éxito devuelve el agente especificado | |
| save | Port | Actualiza la información del agente (contraseña) |
Ver 9.3.2.2.
Implementa un servicio web REST para gestionar las peticiones de información sobre los usuarios. La petición principal será una petición HTTP POST que se realizará a la dirección:
http://35.180.34.205:8070/info
La petición POST contiene datos JSON con la siguiente estructura:
{“login”: email, “password”: password, “kind”: tipo usuario}
En caso de que la combinación login/password/kind aparezca en la base de datos, la respuesta será 200 OK con el cuerpo JSON de la forma:
{
"id": "id_usuario" (long),
"password": "password",
"kind": "tipo_usuario",
"kindCode": "id_kind" (long),
"dni": "dni",
"nombre": "nombre",
"apellidos": "apellidos",
"email": "email",
"username": "nombre_usuario"
}En caso de que la combinación (email, password, kind) no aparezca, la respuesta será “404 Not Found”. Si los parámetros no son correctos se devuelve un código de error HTTP 406.
Se ha implementado un interfaz HTML para que el servicio Web pueda también ser utilizado por personas a través de un navegador Web convencional.
El servicio Web ha sido extendido para permitir a los usuarios cambiar su password.
Encapsula todos los accesos a la base de datos, buscar agente por usuario, contraseña y kind y actualizar la clave.
Ver 9.1.
Las decisiones que han llevado a este diseño son:
| Escenario | Atributos de calidad | Justificación |
|---|---|---|
| 1 | AT001 | La utilización de un servicio web REST aprovecha de la tecnología HTTP y facilita el despliegue del sistema en infraestructuras de alta disponibilidad como pueden ser servidores Web, tanto locales como en la nube. |
| 2 | AT002 | Debido al buen diseño del Parser, realizar un cambio en dicho elemento resultaría una tarea bastante sencilla. |
| 6 | AT006 | La utilización del framework Spring Boot facilitará el desarrollo posterior de características comunes de la web como la negociación de contenido, dado que el framework ya contiene herramientas para su implementación. |
| 8 | AT008 | La restricción de acceso mediante email/password/kind se considera suficientemente segura para este proceso. Las claves deberán almacenarse encriptadas. |
| 9 | AT009 | El desarrollo de un servicio web REST basado en formatos JSON facilitará la creación de pruebas. El framework Spring Boot contiene varias herramientas para pruebas unitarias y de integración. |
| 11 | AT011 | La utilización de una aplicación batch que pueda ser ejecutada manualmente o configurada para su ejecución automatizada es una práctica común entre los administradores de sistemas. |
| 12 | AT012 | El uso de un servicio web REST permitirá el acceso automático al sistema a través de software cliente. |
| 13 | AT013 | El sistema ha sido diseñado de tal forma que su implementación ha sido bastante sencilla |
| 14 | AT014 | La utilización del framework Spring Boot facilita el despliegue. Hay varios ejemplos que muestran cómo desplegar aplicaciones basadas en Spring Boot en servidores de producción. |
| 16 | AT015 | Si la combinación usuario, contraseña y kind no es correcta, se redirige a una página de error al iniciar sesión. |
| 24 | TC002 | El sistema usa una base de datos relacional para almacenar los datos. Ya que el equipo de desarrollo está más familiarizado con este tipo de base de datos. |
| 27 | TC003 | El Formato de entrada debe ser un fichero JSON, ya que se trata de un formato muy sencillo , fácil de entender y de lo más utilizado hoy en día |
| 30 | TC006 | El sistema tiene una batería de pruebas, entre las que se incluye Selenium, Cucumber, Junit y pruebas de carga con Gatling. Entre todas se consiguen probar las entidades del modelo de la aplicación, los controladores, los servicios de acceso a datos, el parseador de incidencias y la estabilidad del sistema ante el acceso de un cierto número de usuarios simultáneos. |
| 33 | TC007 | Spring-boot proporciona una arquitectura impuesta Modelo Vista Controlador, que permite definir una estructura bien definida en el sistema. |
| Elemento | Propiedades |
|---|---|
| Manager | Envía una petición al módulo Agents para comprobar que el agente está registrado, y si existe, permite crear nuevas incidencias y consultar el historial de las enviadas por este. |
| StreamKafka | Se envía una cadena de texto al módulo InciDashboard con todos los datos de una incidencia. |
El componente Manager, se comunica con Agents para chequear que un agente esté registrado en el sistema. Para ello se envía una petición POST al módulo Agents a través de GetAgentService. Una vez que el agente es chequeado de forma correcta, éste puede enviar una incidencia a través de Apache Kafka mediante la interfaz KafkaProducer para que el módulo InciDashboard la gestione. Por último un agente puede hacer un seguimiento de las incidencias que ha enviado.
| Interface | Tipo | Tecnología | Propiedades |
|---|---|---|---|
| GetAgentService | Interface | Servicio Web | Envía una petición al módulo Agents para comprobar que el agente está registrado en el sistema. |
| HomeController | Interface | Controlador | Punto de entrada al módulo InciManager. |
| showView | Port | Muestra la vista para que un agente inicie sesión. | |
| findAgent | Port | Implementado en GetAgentService, se encarga de hacer la petición al módulo Agents para validar que el agente está registrado en el sistema. | |
| addIncidencia | Port | Un agente crea una incidencia que será enviada por ApacheKafka |
| Interface | Tipo | Tecnología | Propiedades |
|---|---|---|---|
| KafkaProducer | Interface | Invocación a Métodos | Se encarga de enviar la incidencia al módulo inciDashboard. |
| send | Port | Implementado en KafkaProducer, se encarga de enviar la incidencia por ApacheKafka al módulo inciDashboard. |
Realiza una petición POST con los datos de un agente, al módulo Agents, para comprobar que efectivamente, el agente se encuentra registrado en el sistema. Una vez la petición ha tenido éxito, el agente inicia sesión en el módulo.
Cuando el agente ya se encuentra en el sistema, podrá crear una nueva incidencia indicando su nombre, descripción, una lista de etiquetas y campos y la localización (manual o automáticamente). Además, también podrá consultar el listado de incidencias que ha realizado hasta ese momento.
StreamKafka se encarga de enviar la cadena de texto que contiene los datos de la incidencia, del componente Manager al módulo InciDashboard, para su posterior gestión.
Ver 9.1.
Las decisiones que han llevado a este diseño son:
| Escenario | Atributos de calidad | Justificación |
|---|---|---|
| 1 | AT001 | La utilización de un servicio web aprovecha de la tecnología HTTP y facilita el despliegue del módulo en servidores Web que garantizan alta disponibilidad como en la nube. |
| 8 | AT008 | La restricción de acceso mediante email/password/kind se considera lo suficientemente segura para este proceso. Las claves deberán almacenarse encriptadas |
| 11 | AT011 | La utilización de una aplicación batch que pueda ser ejecutada manualmente o configurada para su ejecución automatizada es una práctica común entre los administradores de sistemas. |
| 13 | AT013 | El API del servicio web es simple y contiene la funcionalidad mínima necesaria. La utilización del framework Spring Boot facilitará el desarrollo por los estudiantes dado que el framework tiene soluciones para toda la funcionalidad requerida. |
| 14 | AT014 | La utilización del framework Spring Boot facilita el despliegue. Hay varios ejemplos que muestran cómo desplegar aplicaciones basadas en Spring Boot en servidores de producción. |
| 16 | AT015 | Un agente que no se encuentre registrado en el sistema no podrá enviar incidencias al mismo. Se consigue, por tanto, que solo usuarios autorizados puedan interaccionar con el sistema, denegando el acceso a otro usuarios con malas intenciones (robo de datos, envío de incidencias fraudulentas, etc.). |
| 17 | AT016 | El procesamiento y envío de incidencias debe hacerse de forma rápida, permitiendo enviar varias de forma continuada y por distintos agentes. |
| 22 | AT021 | Ciertas incidencias deben poder tener una fecha de caducidad. Un ejemplo claro sería cuando un sensor envía datos con la temperatura en una hora específica. Se podría establecer que esos datos que envía el sensor tienen una hora de duración antes de caducar. |
| 23 | AT022 | Una vez que el agente se encuentre logueado en la aplicación, tendrá una opción en la vista para ver su historial de incidencias. |
| 24 | TC002 | El sistema usa una base de datos relacional para almacenar los datos. Ya que el equipo de desarrollo está más familiarizado con este tipo de base de datos |
| 27 | TC006 | El sistema tiene una batería de pruebas, entre las que se incluye Selenium, Cucumber, Junit y pruebas de carga con Gatling. Entre todas se consiguen probar las entidades del modelo de la aplicación, los controladores, los servicios de acceso a datos, el parseador de incidencias y la estabilidad del sistema ante el acceso de un cierto número de usuarios simultáneos. |
| 33 | TC007 | Spring-boot proporciona una arquitectura impuesta Modelo Vista Controlador, que permite definir una estructura bien definida en el sistema |
| 31 | TC008 | El sistema envía incidencias a través de Kafka. Para su despliegue online, se ha utilizado Cloud Karafka, que permite crear Topics en la nube y, de una forma sencilla, configurarlo en nuestra aplicación. Dicha configuración está contenida en la clase KafkaConsumerFactory |
| Elemento | Propiedades |
|---|---|
| InciDashboard | Componente que se comunica con Kafka para recibir incidencias, con la base de datos para almacenarlas y para recoger operarios de ella (para asignarles incidencias), y con el componente SseEmitter, encargado de enviar datos a los Emitter suscritos al Topic al que se ha enviado la incidencia. |
| StreamKafka | Componente encargado de enviar las incidencias al consumer de Kafka, para su posterior procesamiento por InciDashboard. |
| Repository | Componente que accede a datos de la base de datos. |
| SseEmitter | Componente encargado de “suscribirse” a Topics de Kafka, de tal forma que, cuando se envié nueva información a dichos Topics, se lanzará un evento automáticamente en la aplicación. |
El componente StreamKafka es el encargado de enviar incidencias al consumer de Kafka (KafkaConsumer), para su posterior procesamiento en InciDashboard.
Cuando la incidencia ha sido enviada, el componente InciDashboard recibe la información correspondiente a dicha incidencia, y se encarga de asignarle un operario a través del elemento Repository. El operario asignado será aquel con menos incidencias asignadas y abiertas hasta el momento.
También se envían ciertos datos de la incidencia a los Emitter suscritos al Topic al que se envió la información desde StreamKafka. A través de la interfaz DashboardAdminController, envía los datos anteriormente mencionados a la lista de Emitter, de tal forma que permitan realizar operaciones en tiempo real sobre la aplicación tales como, por ejemplo, actualizar la vista de incidencias sin tener que recargar la página.
El sistema ofrecerá un módulo de administración que permitirá al personal administrativo configurar el comportamiento del sistema de forma interactiva. Por ejemplo, podrá utilizarse para establecer qué tipos de incidencias se asignan a qué grupos de operarios, así como configurar los permisos que los diferentes operarios tienen para asignar o gestionar incidencias.
El sistema podrá ofrecer diferentes visualizaciones gráficas o estadísticas de las incidencias.
| Interface | Tipo | Tecnología | Propiedades |
|---|---|---|---|
| send | Port | Envía datos a un Topic. | |
| KafkaConsumer | Interface | Invocación a métodos | Recibe el envío de datos a Topics desde el componente StreamKafka. Las operaciones para el envío de los datos quedan registradas en un fichero log. |
| Interface | Tipo | Tecnología | Propiedades |
|---|---|---|---|
| KafkaConsumer | Interface (Requerida) | Invocación a métodos | Solicita los datos recibidos en el consumidor de Kafka, a un determinado Topic, para consumirlos posteriormente. |
| listen | Port | Permite interceptar todos los datos que se envían a determinados Topic, de tal forma que sean parseados y convertidos a incidencias. | |
| addIncidence | Port | Permite añadir incidencias a través de servicios. | |
| IncidenceService | Interface (Requerida) | Invocación a métodos | Solicita añadir una nueva incidencia. |
| obtainOperatorForIncidence | Port | Permite obtener un operario, para asignarlo a una incidencia. | |
| OperadorService | Interface (Requerida) | Invocación a métodos | Solicita recuperar un operario. En concreto, aquel con menos incidencias asignadas en estado “abierta”. |
| sendData | Port | Permite enviar ciertos datos de una incidencia (su estado, su título y su ID) a los Emitter. | |
| DashboardAdminController | Interface (Requerida) | Invocación a métodos | Solicita el envío de datos a cada elemento de la lista de Emitter. |
| Interface | Tipo | Tecnología | Propiedades |
|---|---|---|---|
| save | Port | Almacena una nueva incidencia. | |
| IncidenceService | Interface | Invocación a métodos | Permite añadir una incidencia. |
| findAll | Port | Devuelve una lista con todos los operarios del sistema. | |
| OperadorService | Interface | Invocación a métodos | Permite devolver el operario, de la lista completa de operarios, que menos incidencias asignadas tenga con estado “abierta”. |
| Interface | Tipo | Tecnología | Propiedades |
|---|---|---|---|
| send | Port | Envía datos de una incidencia a los Emitter suscritos a un determinado Topic. | |
| DashboardAdminController | Interface | Invocación a métodos | Permite enviar los datos de una incidencia a una lista de Emitter. |
Componente encargado del envío de incidencias a través de Apache Kafka. El producer envía los datos desde el módulo IncidenceManager, mientras que el consumer los recibe para su consecuente parseo y almacenamiento en la base de datos.
Se encarga de recibir las incidencias y parsearlas de una forma concreta.
Las incidencias recibidas tienen la siguiente forma:
Nombreagente@Nombreincidencia@Descripciondelaincidencia@Latitud$Longitud@Etiquetas@Listadecamposclavevalor@Fechaenmilisegundos
La lista de campos clave valor serán, por ejemplo, Fuego:Extremo. Si se añade más de un campo, se separarán con el símbolo $.
La fecha en milisegundos puede ser sacada de esta página web.
Un ejemplo de envío de una incidencia:
Juan@Fuego en Oviedo@El parque San Francisco está quemándose a causa de un cigarrillo mal [email protected]$5.8506767@Fuego$Parque@Temperatura:Alta$Fuego:Extremo@1521893518784
El sistema transformará esa cadena de datos en una incidencia, la guardará en la base de datos, y la asignará a un operario. Además, encapsulará el id, el estado y el título de la incidencia en una cadena JSON, que enviará a los Emitter suscritos a un determinado Topic, los cuales se encargarán de actualizar en tiempo real algunos aspectos de la aplicación.
El sistema ofrecerá un módulo de administración que permitirá al personal administrativo configurar el comportamiento del sistema de forma interactiva. Por ejemplo, podrá utilizarse para establecer qué tipos de incidencias se asignan a qué grupos de operarios, así como configurar los permisos que los diferentes operarios tienen para asignar o gestionar incidencias.
El sistema podrá ofrecer diferentes visualizaciones gráficas o estadísticas de las incidencias
Ver 9.1.2.4.3
Componente que se encarga de enviar datos a los elementos Emitter, encargados de lanzar eventos en tiempo real con los datos que les llegan. En este caso, la información que les llega viaja en formato JSON, con un ID, el estado y el título de la incidencia enviada por Kafka. Es necesario para actualizar las vistas de forma automática.
Ver 9.1.
Las decisiones que han llevado a este diseño son:
| Escenario | Atributos de calidad | Justificación |
|---|---|---|
| 1 | AT001 | Gracias a AWS, podemos disponer de una base de datos y un sistema siempre operativos. Además, Cloud Karafka también nos permite tener un sistema estable con respecto al envío de incidencias a través de Apache Kafka. |
| 8 | AT008 | Las contraseñas de los operarios del sistema serán encriptadas gracias al módulo de Spring-Boot Spring Security. |
| 11 | AT011 | El módulo Dashboard puede ejecutarse fácilmente desde línea de comandos sin que este módulo esté desplegado. Basta con tener Maven instalado, y ejecutar el comando mvn spring-boot:run. |
| 13 | AT013 | El sistema es sencillo de implementar, siguiendo la arquitectura Modelo Vista Controlador (MVC), de tal forma que su modificación y expansión se haga también siguiendo dicha arquitectura. |
| 14 | AT014 | El sistema se despliega de forma sencilla en AWS, con una instancia para cada módulo, haciendo que el despliegue sea ágil y rápido gracias a la separación de los módulos. |
| 17 | AT016 | Las incidencias enviadas a Topics por KafkaProducer son inmediatamente almacenadas en la base de datos tras pasar por la interfaz KafkaConsumer. CloudKarafka hace que este proceso se haga en la nube de una forma rápida y sencilla. |
| 18 | AT016 | Como se ha mencionado en el escenario anterior, CloudKarafka permite que se ejecute Kafka de forma transparente para el usuario. Además, Amazon Web Services nos permitirá desplegar los módulos y las bases de datos ágil y rápidamente. |
| 20 | AT019 | El sistema permitirá ver gráficamente distintas visualizaciones de las incidencias realizadas por los usuarios, ofreciendo también distintas estadísticas de estas. Todo ello se hará en la vista de estadísticas, y cualquier operario y administrador tendrá acceso a ella. |
| 22 | AT021 | El sistema provee a las incidencias de fecha de llegada para futuras gestiones |
| 24 | AT023, TC002 | El sistema guardará las incidencias en una base de datos relacional MySQL, obteniendo de la misma los operarios a los que se les asignarán dichas incidencias. De las incidencias recién almacenadas se recogerán ciertos datos, que serán enviados a los Emitter para que actualicen determinadas vistas de la aplicación. |
| 25 | AT024 | El sistema permite a los operarios gestionar las incidencias que tienen asignadas. Para ello, en la vista de listar incidencias, podrán cambiar el estado de cada una de ellas, así como ver sus detalles y escribir comentarios. |
| 26 | AT025 | El sistema está preparado para ser utilizado de forma ágil e intuitiva por los operarios, con un menú superior para listar incidencias y ver las estadísticas más importantes. |
| 30 | TC006 | El sistema tiene una batería de pruebas, entre las que se incluye Selenium, Cucumber, Junit y pruebas de carga con Gatling. Entre todas se consiguen probar las entidades del modelo de la aplicación, los controladores, los servicios de acceso a datos, el parseador de incidencias y la estabilidad del sistema ante el acceso de un cierto número de usuarios simultáneos. |
| 31 | TC008 | El sistema recibe incidencias a través de Kafka. Para su despliegue online, se ha utilizado Cloud Karafka, que permite crear Topics en la nube y, de una forma sencilla, configurarlo en nuestra aplicación. Dicha configuración está contenida en la clase KafkaConsumerFactory. |
| 33 | TC007 | Spring-boot proporciona una arquitectura impuesta Modelo Vista Controlador, que permite definir una estructura bien definida en el sistema. |
| Elemento | Propiedades |
|---|---|
| Loader | Encargado de gestionar la carga de agentes a la base de datos. |
| Agents | Comprueba que el agente que quiere enviar la incidencia está registrado en el sistema. |
| InciManager | Encargado de recibir las peticiones de envío de incidencias |
| InciDashboard | Se encarga de asignar la incidencia a un operario cuando es enviada por Apache Kafka. |
| Database | Base de datos donde se almacenan los datos |
| StreamKafka | Sistema que comunica los módulos InciManager y InciDashboard |
El módulo Loader carga los agentes en DataBase a través de la interfaz storeUsers.
Cuando una petición le llega al módulo InciManager este se comunica con el módulo Agents para validar al usuario a través de la interfaz AgentsControler.
El módulo InciManager, tras validar al usuario, coge la incidencia y la envía mediante 43etic al módulo InciDashboard.
El módulo InciDashboard, cada vez que le llega una incidencia por Kafka, este módulo parseará este objeto y enviará la incidencia a la base de datos mediante la interfaz storeIncidence.
Cuando un operario se conecta al DashBoard y hace una petición para ver sus incidencias el dashboard hará una 44etición a la base de datos findAllOpertors para validar al operador y findAllIncidences para listar sus incidencias.
N/A
N/A
Ver 9.1
Las decisiones que han llevado a este diseño son:
| Escenario | Atributos de calidad | Justificación |
|---|---|---|
| 24 | AT023, TC002 OC003 | Se emplea una base de datos relacional desplegada en AWS |
| 31 | TC008 | Se emplea Kafka como entorno de ejecución para comunicar el módulo InciManager e InciDashBoard. Se emplea Cloud Karafka como entorno web de uso de Apache kafka |
| Elemento | Propiedades |
|---|---|
| Amazon Web Service | Entorno de ejecución donde se desplegarán los 3 módulos que necesitan despliegue. |
| Loader | Modulo batch que se encarga de cargar los agentes a la base datos. |
| DataBase Server | Base de datos relaccional encargada de almacenar todos los datos de la aplicación |
| Cloud Karafka | Entorno de ejecución encargado de gestionar la comunicación entre el InciManager y el InciDashboard. |
| Database | Base de datos donde se almacenan los datos |
| StreamKafka | Sistema que comunica los módulos InciManager y InciDashboard |
El módulo Loader carga los agentes carga los agentes a la Database .
El entorno AWS se comunica con la base de datos para leer y escribir.
Los modulos InciDashBoard e InicManager se comunican mediante el entorno CloudKarafka
N/A
El módulo Loader carga los agentes carga los agentes a la Database comunicándose con ella a través de la interfaz StoreUsers. Los demas sitemas estan desplegados en un servidor de aplicaciones en amazon web service para su funcionamiento continuo
Ver 9.1
Las decisiones que han llevado a este diseño son:
| Escenario | Atributos de calidad | Justificación |
|---|---|---|
| 1 | AT001 | Haber desplegado en Amazon Web Service garantiza que realizar una petición contra el sistema ser procesada en un tiempo razonable. Además, garantiza una alta disponibilidad |
| 14 | AT014 | Al escoger el sistema de despliegue elegimos Amazon Web Service dado que el tiempo de despliegue es corto y es sencillo de desplegar |
| 18 | AT016 | Hemos escogido Cloud Karafka como sistema cloud de manejo de Apache kafka debido a que ofrece una alta disponibilidad y facilita el depliegue de kafka haciendolo automático. |
| 31 | TC008 | Se utiliza Apache Kafka Cloud (CloudKarafka). |
 |
 |
|---|---|
| Jesus García Minas. @JesusGarciaMinas | UO250999 |
| Pelayo García Torre. @Pelayo-Torre | UO251143 |
| José Antonio García García. @MrKarrter | UO251317 |
| César Camblor García. @cesarcamblor | UO251281 |
| Pablo Díaz Rancaño. @PablooD9 | UO251017 |
| Fernando De la Torre Cueva. @Ferpobe | UO245182 |
| Pablo Álvarez Álvarez. @PabloAlvarezUO251561 | UO251561 |