1. Introducción y metas
Nos hemos propuesto desarrollar un chat descentralizado, siguiendo las caracteristicas de SOLID. Buscaremos desarrollar el proyecto para que tenga un sistema con una arquitectura descentralizada, que separe el amacenamiento de datos de la aplicación que estamos desarrollando. También, tenemos como objetivo que los usuarios puedan almacenar los datos de sus chats en sus pods. Los usuarios de la aplicación, pueden enviarse fotos, vídeos u otros archivos para comunicarse con sus amigos, u otras personas a través del chat. Estas conversaciones, van a poder ser realizadas de manera individual, o de manera grupal, en la que estén incluidos varios participantes. Un usuario de la aplicación, recibirá las notificaciones de la aplicación, cuando otro usuario o usuarios quieran comunicarse con él.
La aplicación, está pensada para todas aquellas personas que quieran mantener conversaciones sin que esa información quede almacenada en los servidores de la empresa proveedora de la aplicación.
1.1. Vista de requisitos
-
Los usuarios que utilicen la aplicación deberán de poseer un pod de SOLID.
-
El sistema deberá de notificar al usuario los mensajes que éste reciba.
-
El sistema guardará los mensajes encriptados (no en texto plano) en el pod del usuario correspondiente.
-
Para recibir los mensajes los usuarios deberán de estar conectados y autentificados en SOLID.
-
Facilidad de aprendizaje para interaccionar con la aplicación por parte de los usuarios novatos en un corto espacio de tiempo.
-
El usuario pueda utilizar la aplicación con un tiempo de envío de mensajes óptimo (especificar en versiones posteriores).
-
No poseer de una base central de datos, que comprometa la información de los usuarios que la usen.
-
Buscar la seguridad, sin tener puntos vulnerables:
-
SQL Injection.
-
Command Injection.
-
Fuga de información.
-
Puertas traseras.
-
Man in the middle.
-
Cross-site request forgery.
-
Mensajes encriptados utilizando el algoritmo de encriptación MD5/SHA1Sum.
-
-
Nivel de accesibilidad y usabilidad siguiendo las recomendaciones de w3c.
1.2. Atributos de calidad
-
Accesibilidad: diseño de una aplicación accesible para personas con discapacidades
-
Disponibilidad: diseño de una aplicación que asegure un cierto grado absoluto de continuidad operacional durante un periodo de duración dado.
-
Modificabilidad: diseño de una aplicación con un software mantenible en el tiempo.
-
Rendimiento: capacidad del sistema a realizar operaciones sin un uso excesivo de recursos (memoria, datos, etc).
-
Seguridad: diseño de una aplicación que no sea vulnerable a:
-
SQL Injection.
-
Comand Injection.
-
Fuga de información.
-
Puertas traseras.
-
Man in the middle.
-
Cross-site request forgery.
-
-
Testeabilidad: diseño de una aplicación que sea capaz de pasar un software mínimo de pruebas para comprobar el correcto funcionamiento de esta.
-
Usabilidad: diseño de una aplicación que sea fácil de usar por parte de los usuarios que interactúen con ella.
-
Escalabilidad: capacidad de la apliación para albergar un mayor volumen de datos.
-
Interoperabilidad: capacidad de la aplicación para interactuar y coexistir con otros sistemas.
-
Portabilidad: característica que posee un software para ejecutarse en diferentes plataformas.
-
Integridad: diseño de una aplicación que mantenga la información exacta a como fue generada sin ser editada por usuarios o procesos no autizados a ello.
-
Consistencia: diseño de una aplicación que mantenga sus datos correctos en todo momento.
-
Robustez: capacidad de la aplicación para actuar y sobreponerse a errores no esperados en tiempo de ejecución.
-
Modular: diseño de una aplicación mediante subdivisiones de esta, independientes unas de otras.
-
Trazable: capacidad de la aplicación a seguir el rastro a las actividades realizadas en ella en todas las etapas de su ciclo de vida.
| Prioridad | Atributo |
|---|---|
1 |
Disponibilidad |
2 |
Seguridad |
3 |
Consistencia |
4 |
Robustez |
5 |
Integridad |
6 |
Modificabilidad |
7 |
Accesibilidad |
8 |
Usabilidad |
9 |
Trazable |
10 |
Rendimiento |
11 |
Testeabilidad |
12 |
Modular |
13 |
Escalabilidad |
14 |
Interoperabilidad |
15 |
Portabilidad |
1.3. Stakeholders
| Role/Name | Expectations |
|---|---|
Profesorado de la asignatura |
Seguir un proceso de desarrollo de la aplicación de acuerdo a lo visto en la asignatura, así como un correcto diseño y arquitectura del producto final. |
SOLID |
Realizar un chat descentralizado de acuerdo a la tecnología SOLID. |
Equipo de desarrollo |
Realizar el trabajo asignado siguiendo los requisitos establecidos en la documentación siguiendo una metodología ágil de acuerdo a lo aprendido en la asignatura. |
2. Restricciones de la Arquitectura
| Restricción | Descripción |
|---|---|
SOLID |
Toda la información intercambiada en la aplicación se almacenará en PODs personales mediante un proceso descentralizado. |
Angular JS/ Typescript |
Se acopla muy bien a un proyecto SOLID. Además, se trata de un framework consolidado que nos ofrece múltiples funcionalidades respaldadas por una gran comunidad. |
Arc42 |
Se nos ha impuesto utilizar esta plantilla para documentar el proyecto. Es un estándar muy utilizado, principalmente en Europa. Este documento ha de mantenerse claro y simple en todo momento. |
| Restricción | Descripción |
|---|---|
Periodo de desarrollo |
El proyecto se llevará a cabo entre los meses de enero y mayo. |
Github |
Debemos usar este conocido controlador de versiones. Nos facilita en gran medida el trabajo en equipo y la organización del proyecto. |
3. Alcance y Contexto del Sistema
3.1. Contexto de Negocio
En la aplicación de chat descentralizado el usuario accedera a ella mediante su webID que sirve como elemento identificador en la comunidad de SOLID o similar supone un cambio respecto a otros autentificadores ya que se realiza mediante URL en este caso. El usuario podra intercambiar mensajes de texto e imágenes con otros usuarios que tengan registrados como amigos presentes en la comunidad. Esos mensajes quedaran almacenados en el POD de cada usuario de modo que ellos sean los únicos propietarios de estos.
3.2. Contexto Técnico
En este diagrama aparecen además del usuario, los profesores que corregiran el proyecto y los miembros de SOLID que valorarán la aplicación, de modo que aumentan el número de stakeholders implicados en el proceso. El login mediante SOLID hara que se cree en el POD de cada usuario una carpeta donde por cada conversación con un amigo se cree otra subcarpeta donde se va a guardar toda la información de la conversación e imágenes que el usuario reciba o desee compartir. Este es el principal objetivo que se busca para competir contra grandes bases de datos centralizadas, las cuales en nuestro proyecto vamos a evitar con este alternativa.
4. Solution Strategy
4.1. Tecnologia
4.1.1. Backend
-
NodeJS
Dado que la aplicación a desarrollar empleará Solid para funcionar, es necesario realizar la instalación de un servidor que de soporte a dicha tecnología. El servidor de referencia para esta tecnología esta implementado sobre Nodo, con lo que necesitaremos emplear esta tecnología.
-
NPM
Npm es un gestor de paquetes para node, que permite instalar software y librerías que deban funcionar sobre esta tecnología. El uso de esta herramienta nos simplificará la instalación del servidor Solid.
-
SPARQL
Sparql se trata de un lenguaje estandarizado de grafos RDF normalizado por el World Wide Web Consortium, con ello una tecnologia clave para el desarrolo de web semantica, por lo que sera la semántica que usemos con el fin de manejar la recuperacion de sentencias y el mantenimiento de datos.
-
CUCUMBER
Cucumber es una herramienta de software utilizada por los programadores de computadoras para probar otro software. Ejecuta pruebas de aceptación automatizadas escritas en un estilo de desarrollo impulsado por el comportamiento
4.1.2. Frontend
-
Angular
Dado que la aplicación a desarrollar deberá ser distribuida, y deberá ser ejecutada en un entorno web, necesitamos un framework de desarrollo que permita crear aplicaciones para ser ejecutadas sobre navegadores web. De las distintas opciones disponibles para esta tarea, angular es una de las más utilizadas. Cuenta con una buena documentación, una base importante de desarrolladores y nos permite programar en TypeScript, que al ser un lenguaje con tipado estatico consideramos que facilitará la escritura del código al eliminar errores de ejecución.
4.1.3. Herramientas de desarrollo
-
WebStorm
Se trata de un Entorno de Desarrollo Integrado completo, que da soporte para todas las tecnologías con las que se trabajará en el desarrollo del proyecto y para el que ya contamos con licencia.
4.2. Obtencion de objetivos de calidad
4.2.1. Seguridad
-
Inyeccion SQL
Al trabajar desde SPARQL no hay una forma 100% efectiva de evitarla, sin embargo seguiremos pautas de limitar el uso de metacaracteres permitiendo a los usuarios solo el uso de estos valores en variables de las propias querys.
-
Fuga de Informacion
Aunque no se haya decidido una tecnologia o protocolo concreto a este punto, las prácticas más adecuadas para prevenir este fallo que se usaran son el uso de logs para observar el trafico de la aplicacion y lozalizar estos abusos, el control de la información a la que lo usuarios tienen acceso y el cifrado de informacion importante.
-
Man in the Middle
Con el fin de evitar esta brecha de seguridad los criterios mas aceptados son el uso de claves publicas, secretas o las anteriormente mencionadas contraseñas con el fin de evitar el filtraje de datos entre usuarios, no obstante no descartamos el uso de otros criterios de validacion para evitar el error.
5. Building Block View
6. Runtime View
Estos diagramas muestran como se realizará el logueo con inicio de sesión y el envío de mensajes.
7. Deployment View
Se muestra un diagrama donde se explica el camino que recorre un mensaje por la infraestructura desde que lo envia un usuario hasta que llega a su amigo.
8. Conceptos transversales
Se incluye una imagen para hacer referencia a todo lo que se va a explicar.
-
Modelo de dominio : Es un modelo conceptual de todos los temas relacionados con un problema específico. En nuestro caso, nuestro modelo de dominio abarca tres cosas :
-
Mensajes
-
Emisor del mensaje
-
Receptor del mensaje
-
-
Patrones : Es un esquema de organización estructural esencial para un sistema de software, que consta de subsistemas, sus responsabilidades e interrelaciones. Nosotros usamos:
-
MVVM(modelo-vista-vista-modelo)
-
-
Logging : Es necesario tener una cuenta de Solid para poder loguearte.
-
Persistencia : Al utilizar ACL y WebRTC la persistencia de los datos es automatizada por Solid.
-
Experiencia del usuario : Conocimientos que tenga el usuario de haber interaccionado previamente con el sistema o similiar, que tuviera unas características parecidas.
-
Interfaz de usuario
-
Ergonómicos
-
Internacionalización
-
-
Seguridad : La aplicación debe ser segura para no tener robos de información ni daños al sistema.
-
Conceptos de desarrollo : Conjunto de actividades que se van a desarrollar a lo largo del proyecto:
-
Contruir, testear, desarrollar
-
Implementar
-
Portabilidad
-
Configurabilidad
-
9. Decisiones de Diseño
9.1. Tecnología
-
NodeJS y Angular
El usar estas tecnologías fue una decisión muy difícil para el equipo ya que nunca las habiamos usado previamente en la carrera y nos va a suponer una dificultad añadida el tener que familiarizarnos con estos frameworks.
Los escogimos porque dentro de las opciones disponibles (Angular o React) para hacer aplicaciones con Solid, Angular nos parecio la más adecuada para este proyecto en concreto. Además Angular tiene buena documentación y varios proyectos de ejemplo con todos los pasos para aprender como funciona rapidamente.
-
TypeScript
Este lenguaje es el más usado con Angular para el desarrollo de aplicaciones. Tenemos ligeros conocimientos de este lenguaje (basicamente, es un JavaScript con comprobación estática de tipos).
Tenemos conocimientos de JavaScript ya que lo habiamos dado en una asignatura previamente pero aun así nos supondra más trabajo el aprender todo lo que puede ofrecer este lenguaje.
-
SPARQL
Para obtener informacion de los PODS y enviar información a los mismos es necesario usar este lenguaje estandarizado para consulta de grafos. La sintaxis es muy similar a otros lenguajes de bases de datos pero el no tener muchos conocimientos de como funciona internamente los PODS de Solid va a hacer que usar este lenguaje suponga otro reto más para el equipo.
-
CUCUMBER
Se usa para la realización de las pruebas de la aplicación.
9.2. Arquitectonicas
-
Patrones
Aun estamos aprendiendo a utilizar las tecnologías mencionadas en el anterior apartado aun no sabemos con certeza los patrones que vamos a emplear en el diseño del código para poder mejorar el rendimiento de nuestra aplicación y hacer que sea mantenible y ampliable. Probablemente separaremos nuestro código en tres capas diferentes para desacoplar las funcionalidades entre las diferentes clases de nuestro proyecto y que una sola clase no mezcle puntos de funcionamiento de más( será capa de presentación, de negocio y de datos). Para esta labor de separar en capas emplearemos el MVC(modelo-vista-controlador) además de buscar mejorar nuestra interfaz de usuario gracias a este patrón, además de poder reutilizar el código lo cual nos hará ganar tiempo el cual escasea para este proyecto. En función que avancen las semanas añadiremos más patrones a esta sección.
9.3. Prioridades
-
Funcionalidad
Hemos decidido basar nuestros esfuerzos en la fase de código en hacer que la aplicación sea funcional aunque la misma sea muy básisca. Nuestro razonamiento para ello es que cuanto antes consigamos mandar información entre PODS (mensaje de texto entre dos usuarios) antes podemos ampliar la aplicación con funcionalidad más compleja (mandar imágenes, chats grupales, etc..).
-
Interfaz de usuarios
Cuando completemos la anterior prioridad nos centraremos en hacer una interfaz de usuario amigable, fácil de usar y sencilla.
-
Disponibilidad
Procuraremos ante fallos en el sistema notificar de la manera más adecuada a los usuarios para evitar que se alarmen ante estas situaciones, además de mostrar ayudas que faciliten la comprensión de la interfaz de usuario cuando se la encuentran por primera vez.
-
Rendimiento
Una vez se consiga una aplicación bonita a ojos del usuario y sin errores graves en funcionamiento buscaremos la mayor velocidad posible en la ejecución de las distintas opciones que nuestra aplicación ofrezca. No estamos seguros si en el tiempo que disponemos para el proyecto conseguiremos maximizar la optimización del mismo.
-
Seguridad
La principal arma para la seguridad se basa en lo más principal de este proyecto que consiste en que cada usuario sea dueño de sus datos al estar contenidos en el POD personal de cada uno. Aún así existen riesgos de ataques como por ejemplo Man in the middle, que si nos sobra tiempo intentaremos encontrar la manera de solventar.
Quality Requirements
10. A) Árbol de calidad
A continuación se incluye el arbol con los criterios de calidad que deberán ser tenidos en cuenta en la realización del sistema. Las hojas de este árbol son los escenarios de calidad que deberán verificarse para asegurar el correcto cumplimiento de los criterios de calidad establecidos. Los nombres de estas hojas se corresponden por tanto con los de los escenarios de calidad del punto siguiente.
11. B) Escenarios de calidad
En este punto describimos los distintos escenarios de calidad que se deberán comprobar durante el desarrollo del sistema parar asegurar la calidad del mismo.
11.1. Escenario 1: Pruebas de accesibilidad con usuarios
11.1.1. 1) Estímulo
Uso normal de la aplicación para verificar su accesibilidad.
11.1.2. 2) Fuente del estímulo
10 usuarios distintos con discapacidad.
11.1.3. 3) Entorno
Sistema funcionando en condiciones normales.
11.1.4. 4) Artefactos del sistema
Cliente Chat descentralizado
11.1.5. 5) Respuesta del sistema
El sistema debe permitir a los usuarios utilizar de manera satisfactoria todas sus funcionalidades.
11.1.6. 6) Medida de la respuesta
Los usuarios evaluarán su experiencia asignando una nota de 0 a 10. Para validar correctamente el sistema deberá obtenerse una nota superior a 5.
11.2. Escenario 2: Guía de accesibilidad (WAI)
11.2.1. 1) Estímulo
Analisis de cumplimiento de las normas de accesibilidad definidas por la Web Accesibility Initiative del W3C.
11.2.2. 2) Fuente del estímulo
Experto en accesibilidad.
11.2.3. 3) Entorno
Sistema funcionando en condiciones normales.
11.2.4. 4) Artefactos del sistema
Cliente Chat descentralizado
11.2.5. 5) Respuesta del sistema
Documento de conformidad de la accesibilidad definido en WCAG 2.1.
11.2.6. 6) Medida de la respuesta
El documento debe indicar el cumplimiento de todos puntos de accesibilidad requeridos.
11.3. Escenario 3: Acceso con teclado
11.3.1. 1) Estímulo
Utilización normal del sistema utilizando solamente un teclado para la entrada de datos.
11.3.2. 2) Fuente del estímulo
Usuario normal del sistema.
11.3.3. 3) Entorno
Sistema funcionando en condiciones normales.
11.3.4. 4) Artefactos del sistema
Cliente Chat descentralizado
11.3.5. 5) Respuesta del sistema
El sistema debe permitir la realización de todas las tareas implementadas en el mismo.
11.3.6. 6) Medida de la respuesta
Todas las tareas deben poder realizar satisfactoriamente.
11.4. Escenario 4: Pruebas unitarias
11.4.1. 1) Estímulo
Comprobación del funcionamiento de los componentes individuales que forman la aplicación.
11.4.2. 2) Fuente del estímulo
Desarrollador.
11.4.3. 3) Entorno
Sistema en desarrollo.
11.4.4. 4) Artefactos del sistema
Cliente Chat descentralizado y Servidor
11.4.5. 5) Respuesta del sistema
El sistema generará un informe indicando si los test desarrollados se ejecutan correctamente.
11.4.6. 6) Medida de la respuesta
Todos los test desarrollados deben ser correctos.
11.5. Escenario 5: Pruebas de integración
11.5.1. 1) Estímulo
Comprobación del funcionamiento del sistema completo.
11.5.2. 2) Fuente del estímulo
Desarrollador.
11.5.3. 3) Entorno
Sistema en funcionamiento normal.
11.5.4. 4) Artefactos del sistema
Cliente Chat descentralizado y Servidor
11.5.5. 5) Respuesta del sistema
El sistema generará un informe indicando si los test desarrollados se ejecutan correctamente.
11.5.6. 6) Medida de la respuesta
Todos los test desarrollados deben ser correctos.
11.6. Escenario 6: Prueba en navegadores
11.6.1. 1) Estímulo
Ejecución de la aplicación en los 3 navegadores más utilizados (Firefox, Chrome y Edge).
11.6.2. 2) Fuente del estímulo
Encargado de pruebas.
11.6.3. 3) Entorno
Sistema en funcionamiento normal.
11.6.4. 4) Artefactos del sistema
Cliente Chat descentralizado
11.6.5. 5) Respuesta del sistema
El sistema se ejecutará normalmente en todos los navegadores.
11.6.6. 6) Medida de la respuesta
Toda la funcionalidad implementada puede ejecutarse en todos los navegadores.
11.7. Escenario 7: Prueba en sistemas operativos
11.7.1. 1) Estímulo
Ejecución de la aplicación en Windows, MacOS, Linux, Android y IPhone.
11.7.2. 2) Fuente del estímulo
Encargado de pruebas.
11.7.3. 3) Entorno
Sistema en funcionamiento normal.
11.7.4. 4) Artefactos del sistema
Cliente Chat descentralizado
11.7.5. 5) Respuesta del sistema
El sistema se ejecutará normalmente en todos los sistemas operativos.
11.7.6. 6) Medida de la respuesta
Toda la funcionalidad implementada puede ejecutarse en todos los sistemas operativos.
11.8. Escenario 8: Prueba en entornos de red
11.8.1. 1) Estímulo
Ejecución de la aplicación con distintas configuraciones de red: Conexión en red local, conexión a traves de internet y red móvil.
11.8.2. 2) Fuente del estímulo
Encargado de pruebas.
11.8.3. 3) Entorno
Sistema en funcionamiento normal.
11.8.4. 4) Artefactos del sistema
Cliente Chat descentralizado
11.8.5. 5) Respuesta del sistema
El sistema permitirá la comunicación en todos los sistemas de red analizados.
11.8.6. 6) Medida de la respuesta
Hay comunicación en todos los sistemas de red analizados.
11.9. Escenario 9: Añadir funcionalidad
11.9.1. 1) Estímulo
Se requiere la implementación de una nueva funcionalidad en la aplicación.
11.9.2. 2) Fuente del estímulo
Desarrollador
11.9.3. 3) Entorno
Sistema en desarrollo.
11.9.4. 4) Artefactos del sistema
Cliente Chat descentralizado y Servidor
11.9.5. 5) Respuesta del sistema
Se añadirá en el sistema una nueva funcionalidad en un tiempo determinado.
11.9.6. 6) Medida de la respuesta
Tiempo empleado, que deberá ser inferior a 8 horas para una modificación de baja complejidad.
11.10. Escenario 10: Pruebas de usabilidad con usuarios
11.10.1. 1) Estímulo
Uso normal de la aplicación para verificar su usabilidad.
11.10.2. 2) Fuente del estímulo
10 usuarios con distintos perfiles.
11.10.3. 3) Entorno
Sistema funcionando en condiciones normales.
11.10.4. 4) Artefactos del sistema
Cliente Chat descentralizado
11.10.5. 5) Respuesta del sistema
El sistema debe permitir a los usuarios utilizar de manera satisfactoria todas sus funcionalidades sin que estos duden y en un tiempo bajo.
11.10.6. 6) Medida de la respuesta
El tiempo empleado para la realización de cada tarea de la prueba será inferior a 1 minuto.
11.11. Escenario 11: Encuesta de usabilidad
11.11.1. 1) Estímulo
Los usuarios que realizan las pruebas de usabilidad se encuestan sobre la facilidad de uso de la misma.
11.11.2. 2) Fuente del estímulo
10 usuarios con distintos perfiles.
11.11.3. 3) Entorno
Sistema funcionando en condiciones normales.
11.11.4. 4) Artefactos del sistema
Cliente Chat descentralizado
11.11.5. 5) Respuesta del sistema
Puntuación numérica (entre 0 y 10) que indique el grado de aceptación de la interfaz de la aplicación por los usuarios que la prueban.
11.11.6. 6) Medida de la respuesta
La puntuación obtenida deberá ser superior a 5.
11.12. Escenario 12: Cifrado de información
11.12.1. 1) Estímulo
Durante un uso normal del sistema, el cliente y el servidor intercambian información.
11.12.2. 2) Fuente del estímulo
Encargado de pruebas.
11.12.3. 3) Entorno
Sistema funcionando en condiciones normales.
11.12.4. 4) Artefactos del sistema
Servidor
11.12.5. 5) Respuesta del sistema
Los paquetes intercambiados deberán aparecer cifrados.
11.12.6. 6) Medida de la respuesta
No debe aparecer ningún no cifrado.
11.13. Escenario 13: Autenticación de clientes
11.13.1. 1) Estímulo
Conexión de un nuevo cliente al servidor.
11.13.2. 2) Fuente del estímulo
Encargado de pruebas.
11.13.3. 3) Entorno
Sistema funcionando en condiciones normales.
11.13.4. 4) Artefactos del sistema
Servidor
11.13.5. 5) Respuesta del sistema
Se permite la conexión la aplicación cliente desarrollada solamente.
11.13.6. 6) Medida de la respuesta
No se permite la conexión al servidor a otras aplicaciones.
11.14. Escenario 14: Autenticación de usuarios
11.14.1. 1) Estímulo
Un usuario accede al sistema.
11.14.2. 2) Fuente del estímulo
Encargado de pruebas.
11.14.3. 3) Entorno
Sistema funcionando en condiciones normales.
11.14.4. 4) Artefactos del sistema
Servidor
11.14.5. 5) Respuesta del sistema
Se comprueban las credenciales del usuario que accede al sistema.
11.14.6. 6) Medida de la respuesta
Se deniegan las conexiones de usuarios que no empleen credenciales válidas.
11.15. Escenario 15: Prueba con múltiples usuarios simultaneos
11.15.1. 1) Estímulo
Acceso concurrente al sistema de multiples usuarios.
11.15.2. 2) Fuente del estímulo
10 usuarios acceden concurrentemente.
11.15.3. 3) Entorno
Sistema funcionando en condiciones normales.
11.15.4. 4) Artefactos del sistema
Servidor
11.15.5. 5) Respuesta del sistema
El sistema atiende a las peticiones realizadas en un tiempo determinado.
11.15.6. 6) Medida de la respuesta
El tiempo de respuesta para las peticiones será inferior a 10 segundos en todos los accesos.
11.16. Escenario 16: Uptime del servidor
11.16.1. 1) Estímulo
Comprobación del uptime del servidor cuando este se encuentre en producción.
11.16.2. 2) Fuente del estímulo
Encargado de mantenimiento.
11.16.3. 3) Entorno
Sistema funcionando en condiciones normales y en un entorno de producción.
11.16.4. 4) Artefactos del sistema
Servidor
11.16.5. 5) Respuesta del sistema
Tiempo que el sistema no estará caido, y responderá a todas las peticiones enviadas por las aplicaciones cliente.
11.16.6. 6) Medida de la respuesta
El tiempo que el servidor permanezca caido será inferior al 0.01% del total.
11.17. Escenario 17: Pruebas Beta
11.17.1. 1) Estímulo
Multiples usuarios utilizando la aplicacion con el fin de forzarla allá donde podrian darse errores.
11.17.2. 2) Fuente del estímulo
Usuarios seleccionados para realizar las pruebas.
11.17.3. 3) Entorno
Sistema funcionando en condiciones normales.
11.17.4. 4) Artefactos del sistema
Servidor.
11.17.5. 5) Respuesta del sistema
Los usuarios en esas condiciones de uso no deberian encontrar ningun error o o retraso con el desarrollo de la prueba.
11.17.6. 6) Medida de la respuesta
11.18. Escenario 18: Pruebas de Integración
11.18.1. 1) Estímulo
Probar una nueva pieza de código previamente a su integracion al grueso y posterior a este.
11.18.2. 2) Fuente del estímulo
Encargado de pruebas.
11.18.3. 3) Entorno
Fragmento de Codigo del que se espera su integración.
11.18.4. 4) Artefactos del sistema
Servidor.
11.18.5. 5) Respuesta del sistema
El fragmento debe de responder correctamente a estas pruebas y posteriormente la aplicación pasar las pruebas unitarias.
11.18.6. 6) Medida de la respuesta
No debe ocurrir ningún error a la hora de implementarlo todo.
11.19. Escenario 19: Prueba Multiples Usuarios atacando la base de datos
11.19.1. 1) Estímulo
Multiples Usuarios modificando la informacion interna de la aplicacion.
11.19.2. 2) Fuente del estímulo
Multiples usuarios modificando la informacion guardada por la base de datos.
11.19.3. 3) Entorno
Sistema funcionando en condiciones normales.
11.19.4. 4) Artefactos del sistema
Servidor.
11.19.5. 5) Respuesta del sistema
Los cambios han de persistir en el sistema correctamente con los cambios hechos en el orden adecuado y el resultado final sea el correcto.
11.19.6. 6) Medida de la respuesta
Datos esperados al acabar las transacciones.
12. Riesgos y deuda técnica
Esta es la primera vez que trabajamos con el lenguaje Angular, con RDF’s y con una arquitectura como la de SOLID, la cual no está integrada de manera sencilla con los lenguajes de programación que hemos ido usando a lo largo del grado de manera más asidua, sin tener así mismo abundante documentación por la red.
Por otro lado, el equipo no dispone de conocimiento en lo relacionado a la seguridad por la red ni acerca de la legislación relativa al almacenamiento de información sensible y de las precauciones que se deben de tomar en ese caso.
Déficit de conocimiento |
Angular |
RDF |
SPARQL |
Solid |
Seguridad en la red |
Legislación para los datos sensibles |
Cucumber |
13. Glossary
| Term | Definition |
|---|---|
Cross-site request forgery |
Tipo de exploit malicioso de un sitio web en el que comandos no autorizados son transmitidos por un usuario en el cual el sitio web confía. |
POD |
Personal Online Data, es el espacio en el que se almacenan tus datos, imágenes, etc. |
SOLID |
Deriva de Social Linked Data, es un conjunto de convenciones y herramientas para construir aplicaciones sociales descentralizadas. |
WebID |
Método estándar de identificación para comunicaciones HTTP. |
About arc42
arc42, the Template for documentation of software and system architecture.
By Dr. Gernot Starke, Dr. Peter Hruschka and contributors.
Template Revision: 7.0 EN (based on asciidoc), January 2017
© We acknowledge that this document uses material from the arc 42 architecture template, http://www.arc42.de. Created by Dr. Peter Hruschka & Dr. Gernot Starke.