Sistema de Informacion

y Control Post Pandemia

Diseño Arquitectura de Software SAD

Introducción
⬡ En esta sección daremos una visión general de todo Documento de
Arquitectura de Software, llamado de aquí en adelante SAD. En esta
sección explicamos el propósito, alcance, referencias y visión general
del documento basado en nuestro proyecto infoCovid_19.

2
 Proposito
⬡ El propósito de este documento es especificar
claramente la arquitectura de software a ser
usada para el desarrollo del sistema
infoCovid_19 que es el producto del Trabajo
de los estudiantes autores de este documento.
Con este documento se pretenden plasmar en
términos arquitectónicos y de diseño todos los
requerimientos definidos en el Documento de
Especificación de Requerimientos de Software
(SRS).

3
“ Con este documento se pretende definir
la arquitectura de software que será
utilizada para el desarrollo del sistema
infoCovid-19. .

4
1. Representación Arquitectónica

En esta sección se describe el patrón

arquitectónico principal escogido para el
diseño de la arquitectura para el sistema
infocovid_19.
Selección de Arquitecturas de los
atributos de calidad
ACTIVIDAD
Análisis
Definición de Métricas
Selección de Arquitecturas Candidatas
Tabla Comparativa
Establecer Prioridades
Selección de la Arquitectura
DESCRIPCION
Se realiza un análisis de los
requerimientos funcionales y no
funcionales, para poder establecer
metas de calidad.
Utilizando el modelo de calidad ISO/IEC
9126 se definen las métricas de calidad
utilizando los atributos de calidad.
Utilizando las métricas de calidad
definidas se realiza una selección de
arquitecturas candidatas.
Se construye una tabla comparativa con
las arquitecturas seleccionadas en la
actividad anterior.
Se establecen prioridades para las sub
características de calidad tomando en
cuenta los requerimientos de calidad
del sistema.
Se analizan los resultados que se
obtuvieron en la tabla comparativa y se
selecciona la mejor arquitectura.
6
 Atributos de Calidad
⬡ Los criterios utilizados para realizar la
comparación entre las arquitecturas de
software, fueron los atributos de calidad,
basándonos en la norma ISO 9126, en
donde se definen 6 categorías principales,
y cada una de estas tiene sus principales
sub categorías, estas categorías son
descritas a continuación:

7
 ID Descripción Prioridad

Requerimientos RF-01
El usuario puede acceder a las funcionalidades que
están asociadas al tipo de usuario
5

El usuario se debe registrar con sus datos personales y

RF-02 7
crear su propia cuenta
Cada función ejecutiva cuenta con actividades cuyos
RF-03 10
estímulos son visuales y auditivos.
Cada subtipo de atención cuenta con actividades cuyos
RF-04 10
estímulos son visuales y auditivos

RF-05 Cada actividad contará con unas breves instrucciones 8

RF-06 Cada actividad cuenta con un ejemplo 4

El sistema muestra al usuario información general de la
RF-07 8
post pandemia
Las instrucciones son mostradas al inicio de cada
RF-08 8
actividad
El usuario puede ingresar información sobre algún
RF-09 8
reporte que presenta en un lugar
RF-10 El sistema permite al usuario registrar incidencias 7
El sistema muestra incidencias registradas por otros
RF-11 7
usuarios
8
Requerimientos RF-12
Es sistema muestra una lista de lugares mas
afectados o relacionados
8

El sistema permite activar su ubicación para tener en

RF-13 7
cuenta donde estuvo ubicado
El sistema contará con guías para evitar algún
RF-14 6
contagio
El sistema permitirá hacer consultas parte del usuario
RF-15 9
y registrarlos
RF-17 El sistema permite la creación de muchos usuarios 6

RF-18 El sistema permite la eliminación de usuarios inactivos 5

RF-19 El sistema contara con ayudas tipo Tooltiptext 5

El sistema muestra información altamente relevante de
RF-20 4
reportes diarios
El sistema contará con tutoriales previos para facilitar
RF-21 5
el uso del sistema

Se puede efectuar pruebas para verificar el

RF-22 cumplimiento de reportes o ingresos de noticias para 4
que sea válido y preciso
9
Metas según Requerimientos
⬡ Ya que para poder informarse sobre las incidencias que pasa en la región de Tacna, el sistema
permitirá al usuario ingresar las incidencias que presenta o tiene en cuenta.
⬡ El sistema debe tener en cuenta las notificaciones para poder informar reportes o datos de calidad
alta.
⬡ Como el sistema será usado para la población de Tacna es necesario que el lenguaje sea español.
⬡ En términos de seguridad, es necesario que cuenten con gestores de autenticación y autorización
para asegurar que están accediendo al sistema personas autorizadas o con su cuenta real. Esto
permite asegurar que los datos ingresados por cada persona sea confidenciales y solo puedan ser
recuperados por las personas autorizadas.
⬡ El sistema permitirá registrar su ubicación actual, para así informar si se encuentra en usa zona en
peligro o zona con normalidad.
⬡ El sistema debe avisar a diario de los números infectados en la ciudad de Tacna.

10
Vista de Caso de Uso

Un caso de uso es una secuencia general de eventos, que

describe todas las posibles acciones entre los posibles actores y
el sistema, para una determinada funcionalidad. En esta
sección se describe los Casos de Uso del sistema
“InfoCovid_19”, en donde se abarcaran todas las
funcionalidades del sistema, se muestran actores que
interactúan en el sistema y las funcionalidades asociadas.

11
12
Vista Lógica
La vista lógica se encarga de representar los requerimientos funcionales del
sistema. En esta sección describimos las partes del diseño del modelo
significativas para la arquitectura, tales como subsistemas y paquetes.

13
Vision general
⬡ En esta vista se observan los dos módulos: Cliente y Servidor. El
cliente hace parte de un cliente pesado como es descrito en la sección
de Representación Arquitectónica.
⬡ El servidor es descrito en la sección 2. Servidor de este documento,
encargándose fundamentalmente del manejo de los datos del sistema y
de la comunicación entre los distintos clientes cuando es necesario el
paso de información desde y hacia la Base de Datos del sistema.

14
Diseño Arquitectonico de paquetes importantes
∙ Paquete Presentación
⬡ Este paquete está modelado bajo el patrón MVC, el cual se explica en la sección 2.
Modelo – Vista – Controlador.
⬡ El paquete de presentación es el encargado de desplegar la información que es mostrada a
los usuarios operador, usuario, administrador.
∙ Conexión
⬡ El paquete conexión es el encargado de manejar las conexiones entre el
Operador/Usuario/Administrador y el Servidor. Este paquete permite la concurrencia
entre varios usuarios y el servidor, permitiendo el uso del sistema por varios usuarios al
mismo tiempo.
∙ Datos
⬡ Este paquete es el encargado de controlar la información que ingresa y sale de la Base de
Datos de infoCovid_19, sustentando el funcionamiento del sistema.
15
Vista de Procesos
⬡ En esta vista se realiza una descomposición, que pueden ser
desarrollados por un desarrollador o un grupo de ellos. Toma en cuenta
principalmente requerimientos internos relacionados con la facilidad de
desarrollo, la gestión del software, reutilización, y las restricciones
impuestas por la herramienta o el lenguaje de programación.
⬡ En esta sección se ilustra el mapeo de los requerimientos no
funcionales de desempeño y disponibilidad al diagrama de procesos.

16
Vista de Procesos

17
Vista de Procesos

⬡ En este servidor de INFOCOVID_19 estarán ejecutándose

constantemente 2 procesos correspondientes a la máquina virtual y a la
base de datos.
⬡ Cada cliente del sistema INFOCOVID_19 correrá un proceso adicional.
⬡ La cantidad final de procesos en ejecución será “2+n”, donde n es igual a
la cantidad de clientes en ejecución.

18
⬡ Los diagramas de despliegue muestran las relaciones físicas de los
distintos nodos que componen el sistema INFOCOVID_19 y el reparto de
los componentes sobre dichos nodos. La vista de despliegue representa la
disposición de las instancias de componentes de ejecución en instancias
de nodos conectados por enlaces de comunicación.

Vista de Despliegue 19
Vista de Implementación

⬡ Con base en el patrón arquitectónico MVC, el sistema se compone

de 3 capas principales sin embargo debido a que es pensado con base
en un modelo N-Tier, existen ciertos detalles que se verán a continuación.

20
Vista de Implementación

21
Vista de Implementación

22
Vista de Implementación

23
Vista de Implementación

24
Vista de Datos

25
Tamaño y Desempeño
⬡ En esta sección se describen de manera general las características del
software que impactan la arquitectura y las restricciones de desempeño.
⬡ CONCURRENCIA DE USUARIOS
⬡ El Sistema Infocovid_2020 esta diseñado para permitir el acceso
concurrente de máximo 10 (tomando el caso extremo de todos los
usuarios estén consultando la capa de datos al mismo tiempo). El sistema
cuenta con un manejador de concurrencia de datos que permite que este
no baje el desempeño cuando varios usuarios estén accediendo a la capa
de datos
26
Calidad
⬡ En esta sección se describe como las arquitecturas contribuye a las
características no funcionales del sistema.
⬡ SEGURIDAD
∙ Despliegue de la Información
⬡ El sistema controla el despliegue de la información de
acuerdo al tipo de usuario, mostrando la información
apropiada para cada usuario que ingrese.
La capa de seguridad es la encargada de validad los privilegios
que tiene cada tipo de usuario en el sistema.
27
Calidad
∙ Validación de información del usuario
⬡ El sistema asegura la privacidad de información personal que
brinda, por cada usuario que se encuentre dentro del sistema,
ua que pueden existir personas malintencionadas que tratan
de modificar o borrar la información que se almacena en el
sistema.
⬡ Esto se realiza mediante la capa de seguridad, la cual se
encarga de validad el nickname y password que son
ingresados por el usuario sean correctos.
28
Calidad
∙ Usabilidad
∙ Presentación de estímulos visuales y auditivos.
⬡ El sistema permite la creación de actividades con estudios
visuales y auditivos, esto con el fin de aumentar el interés del
niño hacia el sistema.
∙ Ayudas tipo ToolTipText
⬡ El sistema contiene ayudas tipo ToolTipText en cada uno
de los botones, mejorando la usabilidad del sistema.

29
ESCENARIO DE CALIDAD :PERFORMANCE
⬡ 1.al tener muchas consultas simultaneas demorara en mostrar el resultado.

⬡ El sistema al tener consultas simultaneas de peticiones tardara unos segundos mas en mostrar el
resultado a los usuarios.

⬡ 2.cuando las notificaciones se saturen por tema de peticiones de demora.

⬡ 3.cuando el sistema no controle un error de entrada.

⬡ 4. que el sistema le muestre un resultado no deseado que no tenga nada que ver con lo que consulto
el usuario.

⬡ 5.sistema al buscar en la base de datos se demore en buscar por la cantidad de registros que tiene la
base de datos.

30
REFINAR ESCENARIOS
ESCENARIO PEOR CASO ACTUAL DESEADO MEJOR CASO

Escenario #01: <10% de 13% de cumplimiento 20% de 35% de

mejorar la disponibilidad de cumplimiento cumplimiento cumplimiento
información a los usuarios sobre
los reportes

Escenario #02: 9 segundos 6 segundos 3 segundos 1a2

Cuando el sistema no controle un segundos
error de entrada

Escenario #03: 12 segundos 7 segundos 5 segundos 3 segundos

Fallas en saturación del sistema

Escenario #04: <10% de 6% de cumplimiento 3% de cumplimiento 1% de

Al tener muchos usuarios en cumplimientos cumplimiento
línea, probabilidad de no poder
soportar.
Escenario#05: <10% de 6% de cumplimiento 3% de cumplimiento 1% de
sistema al buscar en la base de datos cumplimientos cumplimiento
se demore en buscar por la cantidad
de registros que tiene la base de
datos.

31
PRIORIZACION ESCENARIOS
ESCENARIO VOTO PEOR CASO ACTUAL DESEADO MEJOR CASO
S
Escenario #01: <10% de 13% de cumplimiento 20% de 35% de
mejorar la disponibilidad de cumplimiento cumplimiento cumplimiento
información a los usuarios sobre 30
los reportes

Escenario #02: 9 segundos 6 segundos 3 segundos 1a2

Cuando el sistema no controle un 20 segundos
error de entrada

Escenario #03: 12 segundos 7 segundos 5 segundos 3 segundos

Fallas en saturación del sistema 20

Escenario #04: <10% de 6% de cumplimiento 3% de cumplimiento 1% de

Al tener muchos usuarios en cumplimientos cumplimiento
línea, probabilidad de no poder 15
soportar.
Escenario#05: <10% de 6% de cumplimiento 3% de cumplimiento 1% de
sistema al buscar en la base de datos cumplimientos cumplimiento
se demore en buscar por la cantidad
de registros que tiene la base de 10
datos.

32
UTILIDAD ESCENARIOS
ESCENARIO VOTOS PEOR CASO ACTUAL DESEADO MEJOR CASO
Escenario #01: 30 <10% de 13% de 20% de 35% de cumplimiento
mejorar la disponibilidad de cumplimiento cumplimiento cumplimiento
información a los usuarios
sobre los reportes 0 15 30 95

Escenario #02: 20 9 segundos 6 segundos 3 segundos 1 a 2 segundos

Cuando el sistema no controle
un error de entrada 80 90 100 100

Escenario #03: 20 12 segundos 7 segundos 5 segundos 3 segundos

Fallas en saturación del sistema
80 90 90 100

Escenario #04: 15 <10% de 6% de 3% de 1% de cumplimiento

Al tener muchos usuarios en cumplimientos cumplimiento cumplimiento
línea, probabilidad de no
poder soportar.
0 10 95 100
Escenario#05: 10 <10% de 6% de 3% de 1% de cumplimiento
sistema al buscar en la base de cumplimientos cumplimiento cumplimiento
datos se demore en buscar por
la cantidad de registros que
tiene la base de datos. 0 10 95 100

33
MAPEO DE ESTRATEGIAS
Escenarios Respuest Respuesta
INDICADOR ESTRATEGIAS DESCRIPCIÓN
Afectados a Actual Esperada
Persistencia de insertar datos Almacenar datos en los 13% 20%
01 de único Reporte reportes ingresados tan pronto 3
como llegue al sistema.
Cuando el sistema no controle un Asegurarse que los usuarios
error de entrada solo reciben una notificación
cuando parte de su indicación
02 3 15s 30s
de dicho reporte fallido y
proporcionar detalle de cada
reporte
Fallas en saturación del sistema Permitir a los operadores a
03 dividir consultas de los reportes 4 12s 5s
y notificaciones
Al tener muchos usuarios en Permite a los operadores a
04 línea, probabilidad de no poder volver a resignar la consulta 1 5% 8%
soportar. de los reportes
sistema al buscar en la base de permitir que el operador
datos se demore en buscar por la invalide la falta de
05 cantidad de registros que tiene la disponibilidad de datos de un 2 6% 8%
base de datos. reporte, debido a reportes
engañosas

34
Gracias

35