Repository navigation
Documentacion
- Introducción y Objetivos
- Requisitos
- Metodología usada
- Identificación de Stakeholders
- Atributos de calidad
- Restricciones
- Ámbito del sistema y contexto
- Escenarios de calidad
- Vistas
- Bibliografía
El objetivo de este documento es definir la estructura de una arquitectura para gestión de incidendias que pueda ser reutilizada. Aunque el sistema aquí descrito tiene funcionalidad propia, el objetivo es que pueda integrarse como parte de un sistema general de participación de diversos agentes. La arquitectura aquí descrita forma parte del primer entregable de la asignatura Arquitectura del Software, impartida en el grado de Ingeniería Informática del Software, Escuela de Ingeniería Informática, Universidad de Oviedo por los autores de este documento.
El contenido de este documento se puede consultar actualizado en la wiki del proyecto, para acceder a ello pincha
El sistema se ha descompuesto de cuatro partes:
- Loader, Este módulo se encarga de cargar los datos de los agentes que podrán enviar incidencias al sistema.
- Agents, que consiste en un servicio Web REST que permitirá consultar y obtener información de los agentes que participan en el sistema.
- InciManager Se encargará de tramitar las incidencias que serán enviadas por los agentes. Este se comunicará con Agents para comprobar que los agentes dados de alta en el sistema si tienen permisos para enviar incidencias.
- InciDashboard Se comunica con el módulo Incidence Manager para recibir las incidencias del sistema con sus propiedades, y de esta manera poder visualizarlas, gestionarlas y asignarlas a operarios.* InciDashboard Se comunica con el módulo Incidence Manager para recibir las incidencias del sistema con sus propiedades, y de esta manera poder visualizarlas, gestionarlas y asignarlas a operarios.
Los estudiantes deberán implementar el software descrito en este documento en dos equipos de 3-5 personas durante 3 semanas. Un equipo desarrollará el módulo Loader e InciManager y otro equipo desarrollará el módulo Agents y InciDashboard.
En los próximos entregables, los estudiantes crearán la arquitectura e implementarán un prototipo del resto del sistema de participación ciudadana del cual formará parte el sistema actual.
La gestión de usuarios se hará siguiendo un esquema de cuatro partes:
- Loader: Este módulo se encarga de cargar los datos de los agentes que podrán enviar incidencias al sistema.
- Agents: Este módulo consiste en un servicio Web REST que permitirá consultar y obtener información de los agentes que participan en el sistema.
- InciManager: Este módulo tranmitará las incidencias enviadas por los agentes y ademas comprobara que estos están dados de alta en el sistema y tienen permisos para el envio de las incidencias.
- InciDashboard, Este módulo sirve para visualizar y gestionar las incidencias que ocurren en el sistema.
A diferencia del curso pasado, hay diferentes tipos de agentes: personas físicas, entidades, sensores, etc. Cada tipo de usuario estará identificado por una palabra clave. Ejemplos de identificadores del tipo de agente son: "Ciudadano", "Entidad", "Sensor", etc.
La introducción de los datos se hará a partir de ficheros Excel. Los campos del fichero Excel son diferentes a los del sistema anterior, los campos son:
- Nombre (en el caso de personas, contendrá nombre y apellidos)
- Localización (coordenadas geográficas del agente). Este valor es opcional para personas y entidades. Si no hay localización el valor estará en blanco.
- Email: Correo electrónico de contacto. En el caso de sensores u otro tipo de agentes automáticos, puede ser el correo electrónico de la persona que lo administra.
- Identificador: Identificador del agente. En caso de personas físicas o entidades puede ser el CIF. Este identificador será único en el sistema y será el nombre de usuario.
- Tipo: Número entero que representa el tipo de agente.
Durante la importación de estos datos se creará un usuario y una clave que le permita acceder al sistema para comprobar que está dado de alta.
Además del fichero Excel que contiene los datos de cada agente, el sistema utilizará un fichero maestro en formato CSV que contiene los tipos de agentes disponibles. El fichero tiene 2 campos separados por comas donde el primer campos es el código numérico y el segundo el nombre del tipo de usuario. Por ejemplo:
1,Person
2,Entity
3,Sensor
Los códigos y tipos de agentes que aparezcan en este fichero maestro pueden variar, y el sistema de carga tendrá en cuenta los códigos numéricos para resolver el tipo de entidad que corresponda.
Este módulo analizará los datos de los agentes, creando un informe de errores, si se producen. Por cada agente, se almacenará la información proporcionada, junto con una clave de acceso que se generará aleatoriamente. Toda esa información será almacenada en una base de datos que será utilizada por el otro módulo.
Además, se creará una lista de cartas personalizadas para informar del usuario y clave introducido en el sistema y que se enviarán a los correos electrónicos que se han indicado. A diferencia del año pasado, el usuario del sistema será el campo identificador (el año pasado era el correo electrónico).
Por ultimo se plantearán posibles ampliaciones para este módulo:
- El sistema podría extenderse para emitir cartas en formatos como Word o PDF comunicándole a la persona su nombre de usuario y su clave de acceso.
- Si el fichero viniera con errores, se detectarían y se enviarían los datos a un fichero de LOG para su posterior tratamiento.
- El analizador de los datos de entrada debe ser configurable, ya que podrían venir los datos en diferentes formatos y no sólo en Excel. Es opcional permitir más de una entrada, pero es obligatorio que el sistema permita en el futuro una ampliación de manera sencilla.
- Se puede extender el sistema para contemplar aspectos de seguridad.
Este módulo consiste en un servicio Web REST que permitirá consultar y obtener información de los agentes que participan en el sistema. El servicio Web está pensado para ser utilizado por agentes que puedan conectarse al sistema, por lo que la entrada serán ficheros en formato JSON y las respuestas también serán en formato JSON.
Al igual que el año pasado, este sistema podrá disponer de un subsistema de acceso a través de Web para actualizar la clave de cada usuario. Opcionalmente, podrán actualizarse otros campos de los usuarios. El formato de las invocaciones al sistema es el siguiente (obsérvese que se han modificado 2 campos respecto al año pasado):
{ "login": Usuario,
"password": password,
"kind": tipo de agente,
}
En caso de que la combinación login/password/kind aparezca en la base de datos, se devolverá la siguiente información:
{ "name": Nombre,
"location": Coordenadas (opcional),
"email": Email,
"id": identificador,
"kind": tipo de usuario,
"kindCode": código numérico del tipo de usuario,
}
El campo "kindCode" se obtiene a partir de un fichero maestro en formato CSV que se ha descrito en la sección anterior.
Por ultimo se plantearán posibles ampliaciones para este módulo:
- Se puede crear un sencillo interfaz de acceso en HTML para que los usuarios puedan entrar en el sistema, consultar su información o incluso modificar algunos datos.
- Mediante negociación de contenido, se podrán devolver otros formatos como XML
- Se puede extender la funcionalidad para que el servicio web permita cambiar otros campos distintos del agente, además de la contraseña del mismo.
- Se puede extender el sistema para contemplar aspectos de seguridad.
Este módulo se encarga de tramitar las incidencias que serán enviadas por los agentes. El módulo se comunicará con el módulo Agent para chequear que los agentes están dados de alta en el sistema y tienen permisos para enviar incidencias.
Pueden existir diferentes tipos de agentes para enviar incidencias: personas, entidades, sensores, etc. El tipo de agentes no está predeterminado, sino que se obtendrá del mismo fichero maestro descrito en el primer entregable.
Cada incidencia puede contener los siguientes campos:
- Nombre de usuario.
- Password.
- Nombre de la incidencia .
- Descripción.
- Localización (se obtendrá automáticamente del dispositivo si es posible).
- Etiquetas(lista de palabras separadas por comas que permitirán categorizar las incidencias).
- Información adicional(fotos, vídeos, etc.).
Algunas incidencias podrán también contener una lista de campos con la forma "propiedad/valor", donde el campo propiedad indica un nombre de propiedad, y el campo valor, indica el valor de dicha propiedad.
En caso de que la combinación "nombre de usuario/password" sea incorrecta, las incidencias no serán procesadas y se informará del error. Si la combinación es correcta, se procesarán las incidencias y se enviará la incidencia procesada a Apache Kafka para su posterior análisis por parte del módulo InciDashboard.
Los sensores pueden estar enviando incidencias de forma continua dependiendo de cómo estén configurados.
Las incidencias adquirirán un estado (abierta, en proceso, cerrada, anulada) así como otra información generada por el sistema (persona/entidad asignada para resolver la incidencia), comentarios sobre la incidencia realizados por los operarios, etc. Las incidencias también pueden tener una caducidad.
El sistema solamente almacenará un subconjunto de las incidencias enviadas (por ejemplo las enviadas por personas o entidades, o algunos valores específicos enviados por los sensores). Las cuales podrán consultar las incidencias que han enviado utilizando el nombre de usuario y la clave asignadas en el módulo 1. Cada agente podrá tener acceso a todas las incidencias que ha enviado y realizar un seguimiento de las mismas.
Por ultimo se podrán realizar alguna ampliaciones a esto módulo, como:
- Crear una interfaz conversacional mediante un chat-bot que preguntará información sobre la incidencia al usuario.
- Desarrollar un sistema de notificaciones de incidencias para los operarios.
El cuadro de mandos está pensado para que sea utilizado por el personal de gestión de incidencias, que podrá visualizar y gestionar las incidencias que ocurren en el sistema.
Este módulo recibirá las incidencias suministradas por el módulo 3 (InciManager) a través de Apache Kafka. Ciertos agentes, como los sensores, estarán enviando continuamente incidencias, con los valores de ciertas propiedades. El cuadro de mandos se configurará indicando qué valores pueden permitirse en ciertas propiedades y cómo clasificar los valores de otras propiedades.
En caso de que los valores de ciertas propiedades sean peligrosos, el sistema enviará un aviso a los operarios para que comprueben dichos valores.
El sistema ofrecerá una monitorización continua de la evolución de los valores de las propiedades más representativas de los sensores, así como de las incidencias que estén siendo generadas por las personas o entidades. También se ofrecerá la posibilidad de visualizar las incidencias geolocalizadas en un mapa, así como los valores actuales, los estados y los históricos de algunas (por ejemplo, de la temperatura).
El sistema ofrecerá información a los operarios sobre las incidencias que tienen asignadas y les permitirá controlar dichas incidencias, cambiando el estado de las mismas según se hayan procesado o no.
Se podrán añadir las siguientes ampliaciones:
- 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.
Se va a realizar un estudio de arquitectura siguiendo el método de ADD (Atribute-Driven Design) (Bass, Clements, & Kazman, 2003) y la norma del SEI (ANSI/IEEE 1471, 2000).
La documentación sigue el esquema propuesto en la guía de aprendizaje de la asignatura y también se han tomado algunas secciones siguiendo las plantillas propuestas en arc42. Las plantillas actuales están en inglés y alemán, pero había una versión anterior con plantillas en español.
Existe un proyecto que usa esas plantillas para documentar una arquitectura de software sencilla sobre una aplicación de gestión de rutas de bicicleta. La documentación está disponible en la Web. Se puede ver aquí.
En este caso los stakeholders (personas interesadas) son:
- Alumnos que realizan la práctica
- Administrador del Sistema
- Ciudadanos
- Responsables políticos del portal
- Profesores de la asignatura
- Operarios
- Gestores del sistema
Así pues, la lista de stakeholders queda:
| Código | Stakeholder | Intereses (Módulos) |
|---|---|---|
| ST-01 | Alumnos que realizan la práctica (ambos grupos) | Ambos |
| ST-02 | Administrador del Sistema | Carga de ficheros |
| ST-03 | Agentes | Comprobaciones de los datos |
| ST-04 | Responsables políticos del portal | Comprobaciones de los datos |
| ST-05 | Profesores de la asignatura | Ambos |
| ST-06 | Operarios | Incidence Dashboard |
| ST-07 | Gestores del sistema | Incidence Dashboard |
Tabla 1. Lista de Stakeholders e intereses
Posteriormente se pasa a describir en más detalle cada uno.
Se trata de los equipos de desarrollo. Entre sus objetivos están:
- Utilizar tecnologías y metodologías conocidas, minimizando los riesgos relacionados con el aprendizaje de las nuevas.
- Aprender técnicas de desarrollo de software de forma colaborativa y profesional.
- Utilización de tecnologías similares a las del grupo con quien deberán integrarse posteriormente para evitar incompatibilidades.
Es la persona que carga los ficheros de datos. Entre sus objetivos están:
- Tecnologías sencillas de los ficheros de entrada.
- Ficheros que puedan leerse por los humanos.
- Ser capaz de automatizar el proceso de carga de listas de ciudadanos
- Ser capaz de depurar el proceso de carga en caso de errores
Son los usuarios finales del sistema. Entre sus objetivos están:
- Sencillez de acceso a los datos.
- Ser capaz de acceder desde su casa de una forma segura.
- Ser capaz de consultar el estado del sistema.
- Ser capaz de actualizar la clave de cada usuario.
- Ser capaz de actualizar otros campos de los usuarios.(Opcional)
Está formado por los diferentes organismos públicos que podrán usar el sistema para subsanar las incidencias presentadas por los distintos agentes.
- Disponer de información sobre lo que ocurre en el portal tan pronto como sea posible.
- Utilizar tecnologías fáciles de usar e interoperables con otros sistemas.
Son los responsables de los resultados de la práctica. Entre sus objetivos están:
- Proponer tecnologías que ayuden a los estudiantes a adquirir habilidades relacionadas con la arquitectura del software mediante el desarrollo de un proyecto práctico.
- Introducir a los estudiantes en el desarrollo de software de forma colaborativa y profesional, mediante desarrollo basado en pruebas (TDD, test-driven design)
- Proponer un trabajo de desarrollo a partir de una documentación que pueda realizarse en el tiempo asignado por los estudiantes de la asignatura
- Mostrar a los estudiantes un ejemplo de documentación de arquitectura.
Son los usuarios que van a interaccionar con el cuadro de mandos. Entre sus objetivos están:
- Tomar las decisiones adecuadas cuando haya algun valor de una propiedad peligroso.
- Cambiar el estado de las incidencias según se vayan procesando.
Son los que configuran el comportamiento del sistema de forma intereactiva. Entre sus objetivos están:
- Asignar el tipo de incidendias a cada grupo de operarios.
- Configurar los permisos de los diferentes operarios para asignar o gestionar incidencias.
Para el sistema se han identificado los siguientes atributos de calidad:
- Disponibilidad
- Disponibilidad del sistema para consultar datos 24x7.
- Disponibilidad del sistema para recibir incidencias 24x7.
- Modificabilidad
- Facilidad de cambio de diversas partes de la aplicación: Cambiar el parser de entrada de listas de agentes para ficheros con nuevos campos o incluso otro tipo de ficheros.
- Facilidad de cambio de diversas partes de la aplicación: Añadir nueva información al fichero de log.
- Facilidad para modificar partes de la aplicación: otros formatos de salida para las cartas personales.
- Facilidad de cambio de diversas partes de la aplicación: Permitir el cambio de contraseña, permitir el cambio de email, nombre y localización.
- Facilidad para modificar partes de la aplicación: otros formatos, mediante negociación de contenido.
- Rendimiento
- El rendimiento del proceso de carga de los ficheros es razonable.
- La consulta de información de un usuario por el servicio web debe ser rápida.
- Seguridad
- Garantizar la confidencialidad de los datos.
- Cada agente verá solo sus incidencias.
- Cada agente podrá seguir sus incidencias.
- Testabilidad
- Debe ser posible chequear automáticamente que los datos del fichero se cargan adecuadamente.
- Debe ser posible chequear que el servicio Web se comporta de forma adecuada.
- Usabilidad
- El sistema de carga de datos debe poder ser usado por usuarios administradores de sistema familiarizados con herramientas tipo Unix.
- (OPCIONAL) Habrá un chat-bot que ayude a las personas o entidades a rellenar la incidencia.
- (OPCIONAL) Sistema de notificaciones de incidendias que las enviará a los operarios que se asignen.
- Interoperabilidad
- El presente sistema será usado por el Sistema de Gestión de Usuarios, el cual delegará en el sistema actual la gestión de agentes. El subsistema Loader deberá ser utilizado por un proceso automático para consultar el estado de los usuarios que quieran publicar incidencias.
- Simplicidad
- Los cuatro sub-sistemas deberán ser simples y fáciles de desarrollar.
- Desplegabilidad
- El sistema debe ser fácilmente desplegable, especialmente en un servidor en la nube.
- Confiabilidad
- El usuario y la clave tienen que ser correctos para que la incidencia sea valida.
| Codigo | Descripción | Tipo de atributo | Módulo afectado |
|---|---|---|---|
| AT001 | Disponibilidad del sistema para consultar datos 24x7 | Disponibilidad | Agents |
| AT002 | Facilidad de cambio de diversas partes de la aplicación: Cambiar el parser de entrada de listas de ciudadanos. | Modificabilidad | Loader |
| AT003 | Facilidad de cambio de diversas partes de la aplicación: Añadir nueva información al fichero de log | Modificabilidad | Loader |
| AT004 | Facilidad para modificar partes de la aplicación: Añadir otros formatos de salida o de entrada | Modificabilidad | Loader |
| AT005 | Facilidad de cambio de diversas partes de la aplicación: Permitir el cambio de contraseña, y como opcional, permitir el cambio de email, nombre y localización. Permitir cambiar los campos JSON de entrada/salida | Modificabilidad | Agents |
| AT006 | Facilidad para cambiar partes de la aplicación: procesar y devolver información en otros formatos mediante negociación de contenido. | Modificabilidad | Agents |
| AT007 | El rendimiento del proceso de carga de datos de los ficheros es razonable (no demasiado lento, pero tampoco crítico) | Rendimiento | Loader |
| AT008 | El sistema debe garantizar la confidencialidad de los datos de los usuarios | Seguridad | Loader y Agents |
| AT009 | Debe ser posible chequear que el servicio web se comporta adecuadamente | Testabilidad | Agents |
| AT010 | Debe ser posible chequear el comportamiento del sistema de carga de datos | Testabilidad | Loader |
| AT011 | El sistema debe poder ser usado por administradores de sistemas familiarizados con herramientas tipo Unix | Usabilidad | Loader |
| AT012 | El servicio Web debe poder ser utilizado por procesos automáticos que consulten el estado de un usuario | Interoperabilidad | Agents |
| AT013 | El sistema debe ser sencillo y fácil de implementar | Simplicidad | Loader y Agents |
| AT014 | El sistema debe ser fácilmente desplegable | Desplegabilidad | Loader y Agents |
| AT015 | Disponibilidad del sistema para recibir incidencias 24x7 | Disponibilidad | InciManager |
| AT016 | Usuario y clave correcto para validar incidencia | Confiabilidad | InciManager e InciDashboard |
| AT017 | Cada agente verá solo sus incidencias | Seguridad | InciManager |
| AT018 | Cada agente solo seguirá sus incidencias | Seguridad | InciManager |
| AT019 | Chat-bot para rellenar incidencias | Usabilidad | InciManager |
| AT020 | Sistema de notificaciones a operarios con incidencia asignada | Usabilidad | InciManager e InciDashboard |
| AT021 | Personal de gestión de incidencias podrá visualizar y gestionar las incidencias del sistema | Usabilidad | InciDashBoard |
| AT022 | Los operarios seran capaces de controlar sus incidencias creadas, como cambiar su estado, según se hayan procesado o no | Usabilidad | InciDashBoard |
| AT023 | Si las incidencias tienen valores peligrosos, el sistema notificará a los operarios | Seguridad | InciDashBoard |
| AT024 | Monitorización continua por parte del sistema, de ciertos valores, tales como incidencias generadas por sensores, así como de incidencias que estén siendo generadas por las personas o entidades | Disponibilidad | InciDashBoard |
| AT025 | Ofrecer diferentes visualizaciones tanto gráficas como estadísticas de las incidencias (Opcional) | Disponibilidad | InciDashBoard |
| AT026 | El sistema tendrá un módulo de administracion para que el personal administrativo pueda configurar el comportamiento del sistema de forma interactiva (Opcional) | Usabilidad | IncDashBoard |
Los diferentes atributos de calidad son de interés para alguno de los stakeholders. La siguiente tabla muestra la lista de intereses para el proyecto actual:
| Atributos vs Interesados | ST-01 | ST-02 | ST-03 | ST-04 | ST-05 | ST-06 | ST-07 |
|---|---|---|---|---|---|---|---|
| AT001 | X | X | X | X | |||
| AT002 | X | X | X | ||||
| AT003 | X | X | X | ||||
| AT004 | X | X | X | ||||
| AT005 | X | X | X | ||||
| AT006 | X | X | X | X | |||
| AT007 | X | X | X | ||||
| AT008 | X | X | X | ||||
| AT009 | X | X | X | ||||
| AT010 | X | X | X | X | |||
| AT011 | X | X | X | ||||
| AT012 | X | X | X | ||||
| AT013 | X | X | X | ||||
| AT014 | X | X | X | ||||
| AT015 | X | X | X | X | |||
| AT016 | X | X | X | X | X | ||
| AT017 | X | X | X | ||||
| AT018 | X | X | X | ||||
| AT019 | X | X | X | ||||
| AT020 | X | X | X | X | |||
| AT021 | X | X | |||||
| AT022 | X | X | |||||
| AT023 | X | X | X | ||||
| AT024 | X | X | |||||
| AT025 | X | X | |||||
| AT026 | X | X |
Para realizar esta aplicación existen las siguientes restricciones:
| Codigo | Restricción | Motivación |
|---|---|---|
| TC001 | El lenguaje de programación será Java | Se asume que el equipo de desarrollo (ST001) tiene conocimientos de Java |
| TC002 | Se utilizará una base de datos relacional para almacenar los datos | Se asume que el equipo de desarrollo (ST001) tiene conocimientos de bases de datos relacionales y existen múltiples librerías para trabajar con bases de datos relacionales desde Java |
| TC003 | El servicio Web estará basado en estilo REST con formato de entrada JSON | El estilo REST es fácil de implementar y consumir. |
| TC004 | Los datos de entrada vienen en formato Excel | Excel es un formato de datos bastante popular y existen varias librerías Java para procesar ficheros Excel |
| TC005 | El formato de salida de los emails personalizadas será texto plano | Con el fin de facilitar la implementación se propone generar cartas personalizadas mediante texto plano. El equipo de desarrollo puede opcionalmente implementar otros formatos |
| TC006 | Pruebas automáticas y desarrollo basado en pruebas | Las pruebas deberán ser ejecutables automáticamente. Se propone un desarrollo basado en pruebas así como la utilización de técnicas de integración continua |
| TC007 | El servicio Web se implementará mediante el framework Spring Boot | El framework Spring Boot se basa en Spring, que es un framework Java muy popular en la industria. Existen muchos ejemplos y material de ayuda para facilitar el aprendizaje por parte de los estudiantes |
| TC008 | Incidence Manager enviará las incidencias a Incidence Dashboard mediante Apache Kafka | Apache Kafka es una plataforma distribuida de Streaming utilizada para construir plataformas de procesamiento en tiempo real y que permite publicar y suscribirse a flujos de información, guardar flujos de información en un modo tolerante a fallos y procesar los flujos de información en tiempo real |
| TC009 | El formato en el que se enviarán las incidencias será JSON | JavaScript Object Notation (JSON) es un formato basado en texto estándar para representar datos estructurados en la sintaxis de objetos de JavaScript. |
| TC010 | El formato en el que se enviarán las incidencias será JSON | JavaScript Object Notation (JSON) es un formato basado en texto estándar para representar datos estructurados en la sintaxis de objetos de JavaScript. |
| Codigo | Restricción | Motivación |
|---|---|---|
| OC001 | Cada sub-sistema será implementado por un equipo pequeño de estudiantes. | El tamaño de los equipos será de unos 4 ó 5 estudiantes con el fin de que los estudiantes puedan aprender a desarrollar software de forma colaborativa mediante un proyecto simple. |
| OC002 | La estructura de la base de datos será la misma para los 2 sub-sistemas | El "pegamento" entre los 2 sub-sistemas es la base de datos, cuya estructura debe ser acordada por los 2 equipos. |
| OC003 | El código fuente será gestionado mediante el sistema control de versiones Git en un repositorio público en github | Los sistemas de control de versiones son utilizados por la mayoría de las empresas de desarrollo de software. Github ofrece un software de gestión de proyectos muy potente |
Para describir la solución se utilizarán diagramas contextuales y texto. La aplicación está partida en cuatro procesos:
- Loader: Este módulo se encarga de cargar los datos de los agentes que podrán enviar incidencias al sistema.
- Agents: Este módulo consiste en un servicio Web REST que permitirá consultar y obtener información de los agentes que participan en el sistema.
- InciManager: Este módulo tramitará las incidencias enviadas por los agentes y ademas comprobará que estos están dados de alta en el sistema así como que tengan permisos para el envio de las incidencias.
- InciManager: Este módulo tramitará las incidencias enviadas por los agentes y ademas comprobará que estos están dados de alta en el sistema así como que tengan permisos para el envio de las incidencias.
Los cuatro se integran usando el sistema arquitectónico de datos compartidos. En el diagrama de contexto de la Figura 1, se muestran las principales interfaces de cada sistema. El subsistema DataBase es común a los modulos Loader y Agents, por tanto, hay que acordar la tecnología, el modelo de base de datos y el modo de acceso, por otra parte el modulo InciDashboard se comunicara con el modulo InciManager y esta a su vez se comunicará con Agents.
Figura 1. Contexto de negocio del sistema
A continuación, se incluye un diagrama BPMN que define el proceso completo de ambos subsistemas. A destacar:
- Hay una base de datos común.
- Los datos intercambiados usan formato JSON.
- Los procesos de Agent y de Loader son asíncronos.
Figura 2. Diagrama BPMN
Con toda la información anterior se procederá a definir los escenarios de calidad que influencian esta arquitectura.
A continuación se muestra una tabla con la lista de escenarios identificados.
| Escenario Nº | Fuente de estímulo | Estímulo | Entorno | Artefacto | Respuesta | Medición de la respuesta | Atributo de calidad afectado |
|---|---|---|---|---|---|---|---|
| 1 | Sistema de incidencias | Realiza una petición de información sobre sus datos | Tiempo de ejecución | Agents | El sistema recibe la respuesta adecuada | La información es recibida en menos de 15 seg. A cualquier hora del día. | AT001 |
| 2 | Desarrollador | Se introduce un nuevo Parser | Desarrollo | Parser | La modificación es introducida adecuadamente | El sistema es compilado y pasa todas las pruebas | AT002 |
| 3 | Desarrollador | Se implementan nuevos registros para la generación de informes de error | Desarrollo | ReportWriter, DBUpdate y Parser | La opción es implementada con cambios mínimos que solamente afectan al módulo de generación de informes | Menos de un día de trabajo | AT003 |
| 4 | Desarrollador | Se añade un nuevo formato de salida | Desarrollo | Agents y DBManagement | Se incluye el nuevo formato con cambios mínimos en el código | Menos de un día de trabajo | AT004 |
| 5 | Desarrollador | Se introduce la opción de cambio de información de los agentes | Desarrollo | Agents y DBManagement | La información se cambia adecuadamente o se genera el error identificando el problema | Menos de un día de trabajo | AT005 |
| 6 | Desarrollador | Se añade un nuevo formato a los web-services | Desarrollo | Agents | Se implementa el nuevo formato | Menos de dos días de trabajo | AT006 |
| 7 | Administrador del Sistema | Cargar una hoja excel en el sistema (DB) | Tiempo de ejecución | Parser, DBUpdate y ReportWriter | Se carga una Excel sin errores en un tiempo razonable | < 1 segundo por cada 10 ciudadanos | AT007 |
| 8 | Desarrollador | Cargar un sistema en el sistema (DB) | Desarrollo/Tiempo de ejecución | Parser, DBUpdate y ReportWriter (Opcional) | La carga debe hacerse de manera segura | No es posible acceder a los datos personales de los usuarios salvo el administrador del sistema, que tampoco puede acceder a las contraseñas. | AT008 |
| 9 | Agentes | Accede a la aplicación | Tiempo de ejecución | Agents | Cada agente puede acceder a sus datos, pero no a los datos de otros agentes | El acceso a los datos se permite solamente cuando la información de usuario/contraseña/tipo son correctas. | AT009 |
| 10 | Administrador del Sistema | Carga un fichero Excel en la base de datos | Tiempo de ejecución | Parser, DBUpdate y ReportWriter | El proceso de carga se realiza de una forma fiable y es posible chequear que los datos han sido cargados adecuadamente. | No hay errores en la base de datos ni registros duplicados. Ningún agente tiene menos información que la requerida. | AT010 |
| 11 | Administrador del Sistema | Carga un fichero Excel en la base de datos | Tiempo de ejecución | Parser, DBUpdate y ReportWriter | El proceso de carga se comporta de una forma habitual y las opciones son fáciles de comprender | El sistema muestra ayuda si el usuario la solicita. Los mensajes de error y otra información son comprensibles por personal técnico | AT011 |
| 12 | Sistema de Incidencias | Accede al servicio Web | Tiempo de ejecución | Agents | El sistema de incidencias solicita información sobre un usuario pasando una combinación de usuario, contraseña y tipo | Se envía respuesta 200 OK si la combinación aparece en el sistema o error en caso contrario | AT012 |
| 13 | Desarrollador | Implementa el sistema | Desarrollo | Agents, Loader | Los desarrolladores pueden implementar el sistema | El sistema puede implementarse en 2 semanas | AT013 |
| 14 | Administrador del Sistema | Despliega el sistema | Despliegue | Loader, Agents | El sistema es desplegado en un entorno de producción | El sistema puede desplegarse en menos de una hora | AT014 |
| 15 | Agentes | Envío de incidencia | Tiempo de ejecución | Agents, InciManager e InciDashboard | Se envía una incidencia con combinación nombre de usuario/password correcta | Se procesa la incidencia y se envia correctamente a Apache Kafka para su posterior análisis por parte del InciDashboard | AT015 |
| 16 | Agentes | Acceso a incidencias | Tiempo de ejecución | Agents, InciManager | Un agente accede a sus incidencias enviadas con combinación de nombre de usuario y clave | Se envía respuesta 200 OK si la combinación aparece en el sistema o error en caso contrario | AT016 |
| 17 | Agentes | Acceso a incidencias | Tiempo de ejecución | Agents, InciManager | Un agente accede a sus incidencias enviadas con combinación de nombre de usuario y clave | Sólo se muestran las incidencias enviadas por el agente que accedió a ellas | AT017 |
| 18 | Agentes | Seguimiento de incidencias | Tiempo de ejecución | Agents, InciManager | Un agente que haya accedido corectamente al sistema hace un seguimiento de sus incidencias | Sólo se permite hacer un seguimiento de las incidencias enviadas por el agente que accedió a ellas | AT018 |
| 19 | Sistema de incidencias | Se añade un chat-bot para rellenar incidencias | Desarrollo | InciManager | La modificación es introducida adecuadamente | Menos de dos días de trabajo | AT019 |
| 20 | Sistema de incidencias | Se añade un sistema de notificaciones a operarios con incidencia asignada | Desarrollo | InciManager | La modificación es introducida adecuadamente | Menos de dos días de trabajo | AT020 |
| 21 | Sistema de Incidencias | Petición de visualización y gestión de las incidencias | Tiempo de ejecución | inciDashBoard | El sistema recibe la información envidada mediante Apache Kafka | 5 segundos | |
| 22 | Sistema de Incidencias | Petición de cambiar el estado de las incidencias | Tiempo de ejecución | inciDashBoard | El estado se cambia adecuadamente o se genera el error identificando el problema | 5 segundos | AT022 |
| 23 | Sistema de Incidencias | Controlar los valores peligrosos de las incidencias | Tiempo de ejecución | inciDashBoard | El sistema envía un aviso del valor peligroso a los operarios | 5 segundos | AT023 |
| 24 | Desarrollador | Petición para poder monitorizar de forma continua las incidencias, el agente solo podrá seguir sus incidencias | Desarrollo | inciDashBoard | El sistema recibe la respuesta adecuada | 5 segundos | AT024 |
| 25 | Personal de gestión de incidencias | Visualización gráfica o estadística de las incidencias | Desarrollo | inciDashBoard | El sistema recibe la respuesta adecuada | 5 segundos | AT025 |
| 26 | Personal de gestión de incidencias | Cambiar la configuracion del comportamiento del sistema de forma interactiva | Desarrollo | inciDashBoard | El sistema recibe la respuesta adecuada | 5 segundos | AT026 |
Tabla 6. Lista de escenarios de calidad
En los próximos párrafos se describirán algunas de las vistas identificadas y se documentarán de acuerdo a las instrucciones definidas en la guía de aprendizaje.
| Vista | Stakeholders | Atributos de calidad | Escenarios |
|---|---|---|---|
| Context | ST-01, ST-02, ST-03, ST-04, ST-05 | AT011, AT013 | 11, 13 |
| Loader | ST-01, ST-02, ST-04, ST-05 | AT002, AT003, AT004, AT007, AT008 y AT010, AT011, AT013 | 2, 3, 4, 7, 8, 10, 11, 13 |
| Agents | ST-01, ST-03, ST-04, ST-05 | AT001, AT005, AT006, AT008, AT009, AT012, AT013 | 1, 5, 6, 8, 9, 12, 13 |
En los catálogos y en las vistas se han definido tanto los elementos obligatorios como opcionales (voluntarios). Es responsabilidad de cada equipo eliminar los que no vaya a implementar.
La vista de sistema describe los cuatro subsistemas en interacción, así como sus interfaces.
Vease Ambito del sitema y contexto
| Elemento | Propiedades |
|---|---|
| Loader | Se encarga de la introducción de las listas de agentes en el sistema. Lee un fichero con los datos de los agentes. Crea las claves. Añade los emails para los agentes 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. |
| DataBase | Este módulo encapsula los accesos a la base de datos. |
| InciManager | Este módulo se encarga de la recepción de incidencias así como de su validación |
| InciDashboard | Este módulo se encarga de mostrar información acerca de las incidencias y permitir configurar la aplicación desde un servicio Web |
Los datos de los agentes se introducen en el sistema a través de la interface ReadList del módulo Loader. Para cada agente, se crea una clave y se emite un email con todos los datos del agente.
Posteriormente se envían a la base de datos a través de la interfaz UpdateDB del módulo DataBase. El módulo Agents permite al usuario entrar en sesión a través del servicio web GetAgent para comprobar sus datos. Para ello, Agents pide los datos al módulo DataBase a través de la interfaz GetAgent.
Una vez que los agentes estén dados de alta en la aplicación y validados, podrán comenzar a enviar incidencias. Estas serán recibidas por el módulo InciManager, que las procesará y las verificará, usando para ello el módulo Agents. Una vez que las incidencias estén validadas, pasarán a enviarse al módulo InciDashboard, para su presentación y si fuese necesario su modificación.
Opcionalmente se puede implementar la interface ChangeInfo que permite al usuario cambiar otros datos,además de la contraseña, para este fin, el módulo Agents solicita al módulo DataBase el cambio de clave a través de la clase UpdateInfo.
| Interfaz | Tipo | Tecnología | Propiedades |
|---|---|---|---|
| ReadList | Interface | Invocación mediante línea de comandos | Se invocará como un programa en consola |
| Interfaz | Tipo | Tecnología | Propiedades |
|---|---|---|---|
| GetAgentInfo | Interface | Servicio Web | Este servicio se invocará a través de una petición HTTP |
| Interfaz | Tipo | Tecnología | Propiedades |
|---|---|---|---|
| GetAgent | Interface | Invocación a Método | Devuelve los datos de un agente. |
| UpdateDB | Interface | Invocación a Método | Inserta en la base de datos los datos de un agente, incluida su contraseña |
| UpdateInfo | Interface | Invocación a Método | Actualiza la clave del usuario en la base de datos. |
| Interfaz | Tipo | Tecnología | Propiedades |
|---|---|---|---|
| NotifyIncidence | Interface | Servicio Web | Permite notificar una incidencia |
Consultar aquí
Además, puede hacer las siguientes opciones:
- (Opcional) el subsistema que cree los emails debería implementarse de forma que permita emails o cartas en el futuro en diferentes formatos (Word, ODT, PDF, RTF, ETC.).
- Opcionalmente si el fichero viniera con errores, se detectarían y se enviarían los datos a un fichero de LOG para su posterior tratamiento.
- Opcionalmente el parser de los datos de entrada debería ser configurable para permitir datos en diferentes formatos (Excel, TXT, etc.)
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.
Permite a los agentes notificar incidencias, mediante el uso de un servicio web. Enviará las incidencias en un fichero JSON, con la información adecuada. Una vez validadas estas serán procesadas por el sistema.
Permitirá a los administradores de la aplicación monitorizar las incidencias del sistema, así como configurar la aplicación, con diferentes parámetros, como la frecuencia con la que los agentes que pueden enviar incidencias.
Este módulo encapsulará las operaciones de acceso a la base de datos así como la tecnología a utilizar.
La vista de Citizen Reader muestra el primer nivel de descripción de los componentes.
Figura 4. Vista Loader
| Elemento | Propiedades |
|---|---|
| Parser | Lee los datos de entrada en Excel 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 del ciudadano y el email 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. |
| DBUpdate | Encapsula todas las operaciones de base de datos usando interfaces para permitir el acceso a la base de datos. |
| ReportWritter | 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 el fichero de entrada en Excel y mediante un parser convierte éste en objetos. Añade a éstos objetos el email y el password, y lo añade a la base de datos utilizando el componente DBUpdate. 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 WriteReport y el componente ReportWriter. De manera opcional si aparecen otras situaciones de error se pueden documentar usando el mismo componente ReportWriter.
| Interfaz | Tipo | Tecnologia | Propiedades |
|---|---|---|---|
| ReadList | Interface | Invocación a Métodos | Lee el fichero de Excel con los datos de una lista de ciudadanos. |
| RList | Port | Crea los subcomponentes del parser necesarios para procesar el fichero de entrada. | |
| Insert | Interface (Requerida) | Invocación a Métodos | Llama a un método del componente DBUpdate para hacer la inserción en la base de datos. |
| InserR | Port | Verifica los datos y crea el objeto a enviar a DBUpdate. |
| Interfaz | Tipo | Tecnologia | Propiedades |
|---|---|---|---|
| Insert | Interface | Invocación a Métodos | Lee el fichero de Excel con los datos de una lista de ciudadanos. |
| InsertP | Port | Verifica los datos de entrada y si falta algún atributo obligatorio genera el correspondiente error. | |
| WriteReport | Interface (Requerida) | Invocación a Métodos | Llama a un método del componente ReportWriter para escribir una línea o registro en el fichero de log. |
| WreportR | Port | Verifica los datos a escribir. |
| Interfaz | Tipo | Tecnologia | Propiedades |
|---|---|---|---|
| WriteReport | Interface | Invocación a Métodos | Recibe los datos para escribir en el fichero de log. |
| WreportP | Port | Añade a los datos la hora y la fecha. |
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 (String)
- Apellidos (String)
- Fecha de nacimiento (Date)
- Email (String con un formato acorde a las convenciones de correo electrónico)
- NIF u otro número de documento identificativo (DNI, Tarjeta de residencia, etc.), (String formado por dígitos y letras)
- Residencia / Dirección postal (String)
- Nacionalidad (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 Portal de Participación Ciudadana, e informando de su clave de acceso.
Actualiza la base de datos. Ver .
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:
- Fecha
- Hora
- Fichero Excel de procedencia
- Descripción del error (con toda la información necesaria)
Ver el contexto aquí
| Escenario | Atributos de calidad | Justificación |
|---|---|---|
| 2 | AT002 | El acceso al parser mediante un patrón Adapter garantiza un cambio rápido de parser sin tocar el código ya realizado en otras partes de la aplicació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. |
| 5 | AT005 | La utilización de una base de datos relacional ofrecerá un acceso eficiente a la información de los usuarios |
| 6 | AT006 | Utilizar una base de datos con características de seguridad habilitadas podrá garantizar que los datos están aislados de accesos indebidos. El envío de la contraseña d manera individualizada evita que la información pueda ser leída por otros ciudadanos. |
| 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 | 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 |
| 14 | AT014 | Una aplicación batch independiente puede ser ejecutada directamente sin ninguna necesidad especial para su despliegue |
Figura 5. Vista Agents
| Elemento | Propiedades |
|---|---|
| Agents | Se accede a través de dos servicios web: GetAgent, que permite al agente acceder a sus datos en el sistema y ChangeInfo que permite al usuario cambiar su clave de acceso u (Opcional)otros datos. |
| DBManagement | Se accede a través de dos interfaces: GetAgentInfo, que devuelve los datos de un ciudadano en la base de datos y (opcional) UpdateInfo, para actualizar un cambio de clave en la base de datos. |
El Sistema de Incidencias invoca Agents utilizando una llamada a un servicio web que es procesada por GetAgentInfo (enviado usuario/contraseña/tipo) y éste accede a los datos encapsulados en DBManagement mediante la interface GetAgent. Si la combinación usuario/contraseña/tipo es correcta se devuelve la información del usuario en formato JSON.
El usuario (Agent) accede a Agents de forma manual al servicio web ChangeInfo enviado usuario/password/newPasswod y éste llama a la interface UpdateInfo para modificar la clave a través del componente DBManagement.
Además se podrán 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 |
|---|---|---|---|
| GetAgentInfoHTMLController | Interface | Servicio Web | Permite el acceso a los datos de un agente mediante la combinación usuario/contraseña/tipo. |
| GetPIP | GetPIP Port | Hace la validación del usuario antes de pedir los datos. | |
| ChangeInfoHTMLController | Interface | Servicio Web | Permite el cambio de clave u otra información a un agente mediante una combinación de datos: email/contraseña/nuevaContraseña, email/contraseña/nuevoEmail ... |
| ChangeInfoRESTController | Interface | Servicio Web | Permite el cambio en los datos mediante una petición REST y utilizando la combinación de email/contraseña/nuevaContraseña, email/contraseña/nuevoEmail ... |
| ChangeIP | Port | Hace la validación del usuario antes de solicitar el cambio de clave. | |
| UpdateInfo | Interface (Requerida) | Invocación a Métodos | Solicita el cambio de clave u otros campos para el usuario. |
| UInfoR | Port | ||
| GetAgent | Interface (Requerida) | Invocación a Métodos | Solicita la información para el usuario. |
| GetPR | Port |
| Interface | Tipo | Tecnología | Propiedades |
|---|---|---|---|
| UpdateInfo | Interface | Invocación a Métodos | Permite la solicitud de cambio de contraseña u otra información para el agente. |
| UInfoP | Port | ||
| GetAgent | Interface | Invocación a Métodos | Permite la solicitud la de información para el usuario. |
| GetPP | Port |
Consultar aquí
Implementa un servicio web REST para gestionar las peticiones de información sobre los agentes. La petición principal será una petición HTTP POST que se realizará a la dirección:
<URIServicioWeb>/user
Donde representa la URI en la que está desplegado el servicio Web. La petición POST contiene datos JSON con la siguiente estructura:
{"login": usuario, "password": password, "kind": tipo de agente}
En caso de que la combinación (email, password) aparezca en la base de datos, la respuesta será 200 OK con el cuerpo JSON de la forma:
{ "name": Nombre,
"location": Coordenadas (opcional),
"email": Email
"id": identificador,
"kind": tipo de usuario,
"kindCode": código numérico del tipo de usuario,
}
En caso de que la combinación (usuario, contraseña y tipo) no aparezca, la respuesta será “404 Not found”.
Opcionalmente se puede implementar un interfaz HTML para que el servicio Web pueda también ser utilizado por personas a través de un navegador Web convencional y ademas el servicio Web puede ser extendido para permitir a los usuarios cambiar su password.
Encapsula todos los accesos a la base de datos.
Consultar el contexto aquí
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. |
| 4 | AT004 | La encapsulación de las características del modelo que afectan a la base durante el desarrollo y la utilización de un framework basado en MVC facilitará el desarrollo de nuevas funcionalidades como las vistas basadas en HTML o el cambio de clave o nuevos servicios de los usuarios. |
| 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 usuario/contraseña/tipo se considera suficientemente segura para este proceso. Las claves deberían 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. |
| 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 API del servicio web es simple y contiene la funcionalidad mínima necesaria. La utilización del framework Spring Boot# Documentación de GestUsers: Sistema de Gestión de Usuarios. |
| 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. |
Figura 6. Vista InciManager
| Elemento | Propiedades |
|---|---|
| Agents | Se encargará de verificar los datos del Agente que envía la Incidencia. Se utilizará la interfaz CheckAgent para confirmar la identidad del agente así como los permisos del mismo. |
| InciProcessor | Recibirá las incidencias y se encargará de verificarlas, haciendo uso del modulo Agents. En el caso de que la incidencia sea correcta y el Agente que la envía tenga los permisos adecuados, el componente usará la interfaz ProcessIncidence para comunicar la incidencia y que la misma sea procesada por el sistema |
| KafkaAdapter | Se encargará de publicar las incidencias una vez estén verificadas. Servirá de adaptador para el uso de Apache Kafka. |
Los agentes se comunicarán con el sistema de incidencias a través del componente InciProcessor, usando la interfaz NotifyIncidente. El componente InciProcessor, que como se ha comentado anteriormente, se encarga de validad la incidencia enviada, se comunicará con el módulo Agents utilizando la interfaz "CheckAgent". Una vez que haya validado la incidencia, haciendo uso de la interfaz ProcessIncidence, enviará al componente KafkaAdapter la información necesaria de la incidencia, para que este componente la comunique con el restro del sistema utilizando Apache Kafka.
| Interface | Tipo | Tecnología | Propiedades |
|---|---|---|---|
| NotifyIncidente | Interface | Servicio Web | Permite comunicar las incidencias mediante el envio de un archivo JSON. |
| Interface | Tipo | Tecnología | Propiedades |
|---|---|---|---|
| CheckAgent | Interface | Llamada a métodos | Se encarga de validar que el agente tenga los permisos adecuados para enviar la incidencia. |
| Interface | Tipo | Tecnología | Propiedades |
|---|---|---|---|
| ProcessIncidence | Interface | Llamada a métodos | Notifica al sistema la incidencia. |
Implementa un servicio web REST para gestionar el envio de las incidencias al sistema. La petición principal será una petición HTTP POST que se realizará a la dirección:
<URIServicioWeb>/notify
Donde representa la URI en la que está desplegado el servicio Web. La petición POST contiene datos JSON con la siguiente estructura:
{ "login": usuario,
"password": password,
"name": nombre de la incidencia,
"description": Descripción de la incidencia,
"location": Localización del agente,
"labels": Etiquetas para categorizar las incidencias,
"aditionalInfo": Información adicional
"mapInfo" : {
key:value
key:value
...
}
}
En caso de que la combinación (email, password) aparezca en la base de datos, la respuesta será 200 OK con el cuerpo JSON de la forma:
{ "name": Nombre,
"location": Coordenadas (opcional),
"id": identificador,
"state": estado de la incidencia
}
En caso de que la combinación (usuario, contraseña) no aparezca, la respuesta será “404 Not found”.
Opcionalmente se puede implementar un interfaz conversacional mediante un chat-bot que irá preguntando información al usuario sobre la incidencia que construirá el JSON con los valores proporcionados por el usuario.
Tendrá la funcionalidad necesaria para validar la existencia de los usuarios.
Adaptará la información de la incidencia recibida para enviarla al sistema utilizando Apache Kafka.
Consultar el contexto aquí
Las decisiones que han llevado a este diseño son:
| Escenario | Atributos de calidad | Justificación |
|---|---|---|
| 15 | AT015 | El uso de una webapp ejecutándose en un servidor en funcionamiento continuo permite poder atender incidencias en cualquier momento. |
| 16 | AT016 | Validar el acceso a la aplicación para poder validar una incidencia con usuario y clave protege a la aplicación ante incidencias falsas o de orígenes desconocidos. |
| 17 | AT017 | Restringir las incidencias que puede ver un usuario a únicamente las suyas proporciona una seguridad con respecto a la privacidad de los usuarios así como favorece la usabilidad de la aplicación (a un usuario solo le interesan sus incidencias enviadas). |
| 18 | AT018 | Restringir las incidencias que puede seguir un usuario favorece tanto a la privacidad del resto de usuarios como a la usabilidad de la aplicación, ya que un usuario solo está interesado en sus propias incidencias. |
| 19 | AT019 | El uso de un Chat-bot ayuda al usuario a rellenar las incidencias de manera que facilite el uso de la aplicación. |
| 20 | AT020 | Permitir notificar a los operarios por cada incidencia que se les asigne agiliza la organización y el tratamiento de estas. |
| Elemento | Propiedades |
|---|---|
| InciDashboard | Se encarga de recibir las incidencias ya verificadas por el módulo InciManager. Además, hace de controlador gestionando las incidencias recibidas para su posterior visualización en la web y la posible asignación de éstas a los operarios. |
| KafkaAdapter | Sirve de adaptador para el uso de la tecnología Apache Kafka. Se encarga de notificar las incidencias al InciDashboard. |
El componente KafkaAdapter recibe la información de las incidencias enviadas por el resto del sistema, utilizando Apache Kafka y se comunica con el componente InciDashboard, notificándole estas incidencias.
Tras comprobar la información recibida de la incidencia, el componente InciDashboard enviará una notificación mediante WarningIncidence a los operarios del sistema en caso de que alguno de los valores de sus propiedades sea peligrosa. También utiliza la interfaz IncidenceManage para que los operarios puedan cambiar el estado de la incidencia.
Esta información será mostrada y monotorizada mediante la interfaz WebService y se podrá visualizar en la web.
| Interface | Tipo | Tecnología | Propiedades |
|---|---|---|---|
| WebService | Interface | Servicio Web | Visualización continua de los datos más relevantes de los sensores, así como los de las incidencias generadas por personas o entidades. |
| WarningIncidence | Interface | Envía un aviso a los operarios del sistema notificando del valor peligroso de la incidencia. | |
| IncidenceManage | Interface | Permite a los operarios gestionar las incidencias asignadas, cambiando el estado de la misma. |
| Interface | Tipo | Tecnología | Propiedades |
|---|---|---|---|
| GetIncidence | Interface | Recibe las incidencia del sistema y se la comunica al cuadro de mandos. |
Recibe las incidencias del KafkaAdapter y se encarga de gestionarlas. Implementa la interfaz WebService, que mediante tecnología Backed y Fronted, se encarga de la visualización en la web, de la monotorización y visualización de los datos de las incidencias, así como de su geolocalización mediante el consumo de servicios web. Se implementa también la interfaz WarningIncidence, en la que se mandará un aviso a los operarios de manera interna en el sistema, de que la incidencia asignada contiene valores peligrosos. Por último, la interfaz IncidenceManage permite a los operarios cambiar el estado de la incidencia asignada, que tendrá que cambiar en consecuencia en la base de datos.
Adaptará la información de la incidencia enviada por el sistema utilizando Apache Kafka, para la posterior comunicación con el componente InciDashboard.
Consultar el contexto aquí
| Escenario | Atributos de calidad | Justificación |
|---|---|---|
| 21 | AT021 | El uso de un servicio web REST nos permitirá mostrar y gestionar las incidencias del sistema de una manera clara y precisa. |
| 22 | AT022 | Mediante elementos Web ofreceremos a los operarios la posibilidad de controlar y cambiar el estado de sus incidencias con un sistema sencillo y práctico. |
| 23 | AT023 | La utilización de un sistema de mensajería nos permitirá notificar a los operarios mediante una señal de aviso que les sera enviada en caso de alguno de los valores de una incidencia sea peligroso. |
| 24 | AT024 | Mediante la utilización de Apache Kafka podemos mantener un flujo constante de mensajes con la información de las incidencias poder mantener así el sistema motorizado en todo momento. |
| 25 | AT025 | Al usar HTML como sistema para visualizar los datos de las incidencias podemos generar gráficas con los datos requeridos de una manera sencilla y adaptable. |
| 26 | AT026 | El crear un nuevo módulo proporciona al personal administrativo el poder configurar el comportamiento del sistema de una manera fácil, eficiente y adaptada para este tipo de usuario. |