| Requisito | Descripción |
|---|---|
| R01 | Los dispositivos deben alojar un servidor Web. |
| R02 | El sistema debe permitir comunicarse con un dispositivo en específico mediante un identificador único. |
| R03 | El sistema debe permitir controlar los dispositivos mediante una interfaz web. |
| R04 | Cada dispositivo debe poder responder con una lista que contenga las URL hacia sus funcionalidades. |
| R05 | Los dispositivos deben alojar un servidor Web. |
| R06 | Deben existir roles de usuarios: visitante, administrador y supervisor. |
| R07 | Todos usuarios deben poder ver la agenda de la sala mediante el dispositivo panel o algún cliente Web conectado a Internet. |
| R08 | Los usuarios con rol de administrador y/o supervisor deben poder configurar la agenda de la sala mediante el dispositivo panel o algún cliente Web conectado a Internet. |
| R09 | Los usuarios con rol de supervisor deben poder configurar los dispositivos mediante el dispositivo panel o algún cliente Web conectado a Internet. |
| R10 | El sistema debe permitir configurar y administrar los permisos de usuario. |
| R11 | El sistema debe permitir configurar y administrar la BD. |
| R12 | El sistema debe permitir la configuracion y administracion de la simulación de dispositivos. |
| R13 | El sistema debe permitir monitoreo y logging de su funcionamiento. |
| Requisito | Descripción | Tipo | |
|---|---|---|---|
| RN1 | El sistema debe poder soportar al menos 200 dispositivos. | Escalabilidad | Cantidad estimada por el cliente, de dispositivos en el sistema. |
| RN2 | El sistema debe poder extenderse a 23 pisos. | Escalabilidad | Escalabilidad esperada por el cliente. |
| RN3 | Todos los dispositivos se comunican con el servidor a través de un misma interfaz, para permitir integrar nuevos dispositivos. | Flexibilidad | Debe ser fácil lograr incorporar un dispositivo nuevo al sistema. |
| RN4 | El servidor se comunica con los dispositivos utilizando una API REST. | Flexibilidad y Escalabilidad | Permite incorporar dispositivos fácilmente con operaciones estándar y recursos identificados. |
| RN5 | El sistema posee una lista de dispositivos conocidos, con los cuales intercambia información. | Testeabilidad | Se considera como porcentaje razonable para el desarrollo del sistema. |
| RN6 | El sistema posee una lista de dispositivos conocidos, con los cuales intercambia información. | Seguridad | Dispositivos desconocidos no deben participar en el sistema. |
| RN7 | El sistema debe exigir autenticación de usuarios, con protocolo de seguridad SSL. | Seguridad | Se debe asegurar que los dispositivos no sean modificados por usuarios desconocidos. |
| RN8 | El sistema debe permitir ser configurado por el administrador. | Configurabilidad | Es necesario para poder configurar el sistema y probar |
| RN9 | El tiempo de recuperación no debe ser mayor a 2 horas. | Disponibilidad | Se considera como tiempo razonable para no atentar contra los usuarios, ni el funcionamiento de los demás dispositivos. |
| RN10 | El sistema debe permitir mantenibilidad por parte de usuarios administradores, permitiendo agregar o modificar datos de configuración al sistema. | Mantenibilidad | Necesario para los cambio futuros del sistema. |
Estilos arquitectónicos
- Cliente Servidor
- 3 Capas (Dispositivo, Servidor, Cliente)
Conectores
- (1): Llamada a procedimientos, Parámetros (transferencia de datos)
- (2): Árbitro, Planificación
- (3): Árbitro, Seguridad: Autentificación
- (4): Acceso a datos (disponibilidad persistente)
Identificación de Riesgos
Al momento de tomar las decisiones arquitectónicas, se generan distintas problemáticas que pueden generar conflictos. Por un lado se genera un riesgo al generar un componente común con su respectiva interfaz para todos los dispositivos, considerando la diversidad de estos, y los distintos niveles de complejidad hay decidir abstraerse por una interfaz, sin embargo, ¿Con que nivel de profundidad se debe generar?
Por otro lado está el tema de los componentes que podrían verse afectado al momento de escalar. El servidor debe ser capaz de procesar gran cantidad de información por ende el “Controlador dispositivo” y su respectivo conector con la API de data-in deben ser identificados como un factor de riesgo claro. En este caso, la capacidad de leer información, va verse restringida por el ancho de banda y por la cantidad máxima de request, sin embargo hay que tener en cuenta posibles opciones de replicar esta lógica de modo de procesar información simultánea.
Puntos Sensibles
- Escalabilidad: capacidad de aumentar los request sin que el servidor colapse y pierda datos.
- Flexibilidad: Elegir una interfaz común para todos los dispositivos, que no sea necesario hacer cambios cada vez que se quiera agregar un tipo de dispositivo nuevo.
- Seguridad: Los datos deben ser de los dispositivos inscritos y no de dispositivos ajenos al sistema. Por otro lado el control de los dispositivos debe ser restringido, es de suma importancia que los dispositivos no sean manipulados externamente sin autorización.
TradeOffs La complejidad se va a ver afectada claramente con las decisiones tomadas tanto en escalabilidad, flexibilidad y seguridad. Por un lado, en caso que se desee escalar ocupando replicaciones, claramente va a generarse mayor complejidad debido a tener que coordinar distintos componentes en paralelo que procesan información y modifican la base de datos de manera concurrente. En el caso de la flexibilidad también hay un trade-off con complejidad ya que a medida que aumento la flexibilidad de los dispositivos, más complejo va a ser mi componente dispositivo. El aumentar la seguridad va a afectar por un lado la escalabilidad, debido a que protocolos de seguridad más complejos involucran una sobrecargar mayor en el servidor y a su vez un aumento de complejidad.