Documento de Arquitectura

de Software SAD
Versión 1.0

“Sistema de información
y control post Pandemia”

“InfoCovid_19”

Página 1 de 32
Versión Fecha Sección Descripción Autores
Modificada
Creación de la
Plantilla con sus
José
0.1 15/05/20 Línea base SAD respectivas
Contreras
secciones y
descripciones
Creación y
Presentación,
redacción de las Daniela
0.2 18/05/20 Propósito y
secciones descritas Rodríguez
alcance
anteriormente
Creación y
Representación redacción de las Paulo
0.3 19/05/20
Arquitectónica partes de lo Torres
mencionado
Redacción de
Objetivos y
requerimientos, José
0.4 23/05/20 Restricciones
restricciones y Contreras
Arquitectónicos
objetivos
Redacción y
Vista de Caso José
0.5 25/05/20 diagramación de
de Uso Contreras
caso de usos
Creación del Daniela
0.6 30/05/20 Vista lógica
diagramado lógico Rodríguez
Creación y
Vista de
redacción de los Paulo
0.7 04/06/2020 Procesos y vista
diagramas Torres
de despliegue
mencionados
Creación y
Vista de
redacción de José
0.8 06/06/2020 Implementació
diagramas, capas, Contreras
n
datos, etc.
Creación de
0.9 07/06/2020 Vista de Datos
diagramas
Historial de Cambios

Página 2 de 32
CONTENIDO

1. Introducción________________________________________________________5
1.1. Propósito____________________________________________________________5
1.2. Alcance______________________________________________________________5
1.2.1. Descripción de la Metodología usada___________________________________________5

1.3. Visión general del documento___________________________________________6

2. Representación Arquitectónica_________________________________________6
2.1. Selección de Arquitecturas de los atributos de calidad________________________6
2.2. Representación Arquitectónica__________________________________________8
2.2.1. Clientes Pesados___________________________________________________________9
2.2.2. Servidor_________________________________________________________________11
2.2.3. Capas___________________________________________________________________11

2.3. Representación Arquitectónica_________________________________________12

2.4. Atributos de Calidad y sus Escenarios____________________________________13

3. Objetivos y Restricciones Arquitectónicas_______________________________15

3.1. Priorización de Requerimiento__________________________________________15
3.1.1. Resumen de ponderación por Stakehalders____________________________________15
3.1.2. Resumen de Requerimientos________________________________________________16
3.1.3. Requerimientos de prioridad mayor o igual a 7__________________________________17

3.2. Metas y restricciones arquitectónicas según requerimientos_________________17

4. Vista de Casos de Uso_______________________________________________18

4.1. Actores_____________________________________________________________19
4.2. Interfaz de Usuario___________________________________________________19
4.2.1. Vista de Usuario__________________________________________________________20
4.2.2. Vista Administrador_______________________________________________________22

5. Vista Lógica_______________________________________________________25
5.1. Visión General_______________________________________________________25
5.2. Diseño Arquitectónico de Paquetes Importantes___________________________25
5.2.1. Paquete Presentación______________________________________________________25
5.2.2. Conexión________________________________________________________________25
5.2.3. Datos___________________________________________________________________25

6. Vista de Procesos___________________________________________________26
7. Vista de Despliegue_________________________________________________27
8. Vista de Implementación____________________________________________28

Página 3 de 32
 8.1. Descripcion General de la Vista de Implementación_________________________28
8.1.1. Presentación_____________________________________________________________29

9. Vista de Datos_____________________________________________________31
10. Tamaño y desempeño_____________________________________________32
10.1. Concurrencia de usuarios______________________________________________32

11. Calidad_________________________________________________________32
11.1. Seguridad___________________________________________________________32
11.1.1. Despliegue de la Información_____________________________________________32
11.1.2. Validación de información del usuario______________________________________32

11.2. Usabilidad__________________________________________________________32
11.2.1. Presentación de estímulos visuales y auditivos._______________________________32
11.2.2. Ayudas tipo ToolTipText_________________________________________________32

Página 4 de 32
 1. 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.

1.1. Propósito
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).

Este documento va dirigido a los stakeholders implicados en el proceso de desarrollo

del software.

Este documento es la principal fuente de información para empezar con el desarrollo

de nuestro sistema y la integración de los componentes adquiridos.

1.2. Alcance
Con este documento se pretende definir la arquitectura de software que será utilizada
para el desarrollo del sistema infoCovid_19. Como se verá posteriormente en este
documento (ver sección 2 Representación Arquitectónica) esta representación
arquitectónica es especificada por las diferentes vistas del sistema (Casos de Uso,
Lógica, Procesos, Despliegue, Implementación y Datos).

También son detallados y direccionados otros aspectos importantes con respecto a los
requerimientos no funcionales como lo son el tamaño, desempeño y la calidad de la
arquitectura del sistema.
En este documento se definen los módulos a desarrollar y la manera en que éstos se
relacionan con los componentes adquiridos. El sistema infoCovid_19 contará con las
funcionalidades definidas en el SRS y mapeadas al software en este documento.

1.2.1. Descripción de la Metodología usada

El uso de referencias se realiza de manera transversal a todo el Proyecto Especial y al
Trabajo de Grado, utilizando los formatos encontrados en el documento “Plantilla
Referencias.dot” que se basa en el formato IEEE.

Página 5 de 32
 1.3. Visión general del documento
Este documento está organizado de forma en la cual el lector conforme lo va leyendo,
puede encontrar la descripción de la arquitectura del sistema con ayuda de diferentes
aspectos importantes, estos están distribuidos de la siguiente manera. La sección 2.
Representación Arquitectónica, describe que arquitectura de software será utilizada
para el desarrollo del sistema y como será representada. La sección 3. Objetivos y
Restricciones Arquitectónicas, muestra como los requerimientos no funcionales
impactan en la arquitectura de software seleccionada. La sección 4. Vista de Casos de
Uso, contiene los casos de uso del sistema. La sección 5. Vista Lógica, tiene una
descripción de las partes más importantes de la arquitectura. La sección 6. Vista de
Procesos, muestra la descripción del sistema en los procesos que ejecuta. La sección 7.
Vista de Despliegue, describe la manera como se va a ejecutar el sistema. La sección 8.
Vista de Implementación, describe el modelo de implementación del sistema. La
sección 9. Vista de Datos, muestra la manera cómo van a ser almacenados los datos del
sistema.

2. 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.
El sistema InfoCovid_2020 es una aplicación en la cual se pretende
aplicar los conceptos fundamentales de diseño e implementación de una
arquitectura de software. Se desea mediante ella mostrar a los Stakeholders
una forma más eficiente, completa y confiable para realizar sus
operaciones y llevar un control de sus movimientos de la enfermedad en
cualquier momento en el sitio que se desee y requiriendo solamente una
conexión a internet y un programa de acceso web.
2.1. Selección de Arquitecturas de los atributos de
calidad
El método de comparación de arquitecturas que se utilizo fue el “método de
comparación de arquitecturas basada en el modelo ISO/IEC 9126 adaptado
para arquitecturas de software”, el cual proporciona seis actividades para poder
seleccionar la mejor arquitectura según los atributos de calidad. Estas seis
actividades se muestran en la siguiente tabla.
ACTIVIDAD DESCRIPCION
Se realiza un análisis de los
requerimientos funcionales y no
Análisis
funcionales, para poder establecer
metas de calidad.
Definición de Métricas Utilizando el modelo de calidad
ISO/IEC 9126 se definen las
métricas de calidad utilizando los
Página 6 de 32
 atributos de calidad.
Utilizando las métricas de calidad
Selección de Arquitecturas
definidas se realiza una selección de
Candidatas
arquitecturas candidatas.
Se construye una tabla comparativa
Tabla Comparativa con las arquitecturas seleccionadas
en la actividad anterior.
Se establecen prioridades para las
sub características de calidad
Establecer Prioridades tomando en cuenta los
requerimientos de calidad del
sistema.
Se analizan los resultados que se
Selección de la Arquitectura obtuvieron en la tabla comparativa y
se selecciona la mejor arquitectura.

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:

Los criterios de calidad seleccionados para escoger la arquitectura de software

fueron usabilidad, mantenibilidad y funcionalidad, según el orden de
importancia para el sistema.

Página 7 de 32
En la tabla de comparación de arquitecturas, este proceso se realizó tomando
los criterios de calidad vistos anteriormente frente a la arquitectura adecuada,
se establecieron prioridades en los atributos de calidad para luego seleccionar
la arquitectura del sistema Infocovid_19.
Conociendo la priorización de los atributos de calidad, esto se realizó mirando
que arquitecturas cumplían cada atributo de calidad, se contabiliza este número
y luego se realiza el promedio según la cantidad de arquitecturas por
seleccionar.
Una vez terminado, se tienen priorizados los atributos de calidad, se utiliza el
peso de cada uno para determinar la mejor arquitectura.
Por último, luego de realizar la comparación de arquitecturas, La arquitectura
seleccionada es la de Cliente-Servidor en Capas, se aprovechan las ventajas
que ofrece la arquitectura cliente- servidor para un buen manejo de datos, para
varios usuarios y las ventajas que ofrece la arquitectura en capas para ser
optimizada, refinada y reutilizada.

2.2. Representación Arquitectónica

La arquitectura escogida para el sistema Infocovid_19 es la de Cliente Servidor,
la cual describimos en lo siguiente:
La arquitectura Cliente-Servidor es comúnmente una arquitectura que se basa
en el concepto de procesamiento en dos o más maquinas. Una aplicación es
Cliente-Servidor si los almacenamientos de los datos se encuentran apartados
de la presentación.
Este caso hace que el servidor sea un motor de base de datos que almacena
datos y el cliente es el proceso que recupera o crea dichos datos. La idea
detrás de esta arquitectura es que el servidor pueda permitir el acceso de
múltiples usuarios a la misma fuente de datos.
Esta arquitectura está compuesta por cuatro capas. En donde cada cliente
tiene 3 de estas 4 capas y el servidor una capa. Por tal motivo los clientes son
clientes pesados.

2.2.1. Clientes Pesados

La filosofía detrás de esta arquitectura Cliente-Servidor supone que cada
máquina realiza el procesamiento relevante para sus tareas. Los clientes son

Página 8 de 32
diseñados para proveer a los usuarios una interfaz gráfica que supone una
presentación de los datos. Los servidores son diseñados para manejar la
complejidad de los datos y las comunicaciones por lo cual sirven como
almacenes de datos. Conforme los sistemas van creciendo, se van
encontrando servidor. Por esto, los clientes ahora son más potentes, siendo
capaces de soportar interfaces graficas más robustas y procesamiento de
información y los servidores cuentan con más capacidad de almacenamiento y
procesamiento a la vez.
Para este caso específico del Sistema Infocovid_19, los clientes serán clientes
pesados que realizaran parte de las tareas de procesamiento y, naturalmente,
se encargaran de la presentación de datos.
Los clientes estarán definidos por tres capas:
 Presentación.
 Seguridad.
 Lógica del Negocio (Core)
2.2.1.1. Presentación
La capa de presentación está representada por medio de diseño modelo Vista
Controlador, el uso de este patrón de diseño suma dos ventajas principales al
sistema. La posibilidad de varias vistas usando el mismo modelo, esto facilita el
diseño de diferentes interfaces de usuario dependiendo del usuario que utilice
el sistema. Extensibilidad por medio de look and feel, esta ventaja permite
aplicar diferentes tipos de look and feel a cada vista sin necesidad de afectar o
modificar la funcionalidad del modelo.
El modelo es encargado de comunicarse con las otras partes del sistema.
2.2.1.1.1. Modelo-Vista-Controlador

Este patrón de diseño conocido como MVC por sus siglas en inglés, el
cual divide el sistema en 3 áreas: procesamiento, salida y entrada. Estas
áreas se representan en tres clases respectivamente:
o Modelo: El modelo se encargar de administrar el comportamiento
y los datos del sistema, respondiendo a requerimientos de
información sobre su estado y respondiendo a instrucciones de
cambio de estado.
o Vista: Se encarga de manejar la visualización de la información.
o Controlador: Interpreta las acciones de los dispositivos de
entrada, informando al modelo y/o a la vista que se actualicen.

Página 9 de 32
Tanto la vista como el controlador dependen del modelo, el cual no
depende de las otras clases. Esta separación permite construir y probar
el modelo independiente de la representación visual, permitiendo
cambios en el controlador y la vista sin afectar la funcionalidad del
sistema.
Entre las ventajas del estilo señaladas en la comunicación de Patterns &
Practices de Microsoft están las siguientes:
o Soporte de vistas múltiples, dado que la vista se halla separado
del modelo y no hay dependencia directa del modelo con respecto
a la vista, la interfaz de usuario puede mostrar múltiples vistas de
los mismos datos simultáneamente. Por ejemplo, múltiples
páginas de una aplicación de web pueden utilizar el mismo
modelo de objetos, mostrado de maneras diferentes.
o Adaptación al cambio, los requerimientos de interfaz de usuario
tienden a cambiar con mayor rapidez de las reglas de negocios.
Los usuarios pueden preferir distintos opciones de
representación, o requerir soporte para nuevos dispositivos como
teléfonos celulares o PDAs. Dado que el modelo no depende de
las vistas, agregar nuevas opciones de presentación
generalmente no afecta al modelo.

Página 10 de 32
 2.2.1.2. Seguridad
La capa de seguridad se encarga de validar y autenticar a cada usuario que
desee utilizar el sistema, garantizado que solamente los usuarios registrados
puedan ingresar al sistema y hacer uso del mismo.

2.2.1.3. Lógica del Negocio (CORE)

La capa de Lógica de Negocio, es la encargada de realizar el procesamiento,
administrando el comportamiento y los datos del sistema, básicamente es el
funcionamiento del sistema.

2.2.2. Servidor
El servidor del sistema estará definido por la arquitectura por capas que se
especifica en la sección consecuente.
El servidor tendrá la lógica del negocio y se encargará del almacenamiento de
los datos.
2.2.3. Capas
El patrón arquitectónico por capas ayuda a estructurar las aplicaciones que
pueden ser descompuestas en grupos de tareas en la cual cada grupo de
tareas es un nivel particular de abstracción.
El estilo en capas como una organización jerárquica tal que esta capa
proporciona servicios a la capa inmediatamente superior y se sirve de las
prestaciones que le brinda la inmediatamente inferior.
Los sistemas de información usados en los sistemas de dominio de negocio,
usualmente utilizan arquitecturas de dos capas. La capa inferior es la base de
datos que contiene los datos de la compañía. En esta arquitectura muchas
aplicaciones trabajan de manera concurrente encima de esta capa de datos,
para cumplir diferentes tareas. Por el acoplamiento tan alto que esto genera
entre la interface de usuario y los datos, se introduce una tercera capa en
medio de estas, llamada la capa de dominio, que modela la estructura
conceptual del domino del problema. De igual manera es necesario sub dividir
esta capa, para finalmente tener una arquitectura de cuatro capas:
•Presentación.
•Lógica de la aplicación.
•Dominio.
•Datos.

Página 11 de 32
Entre los beneficios de esta arquitectura se encuentran los siguientes:
•Reutilización de capas: Se puede dar en la medida en que cada capa tenga un
nivel de abstracción bien definido y unas interfaces documentadas y bien
definidas igualmente. Si esta caja negra está desarrollada correctamente,
puede reducir dramáticamente el esfuerzo en desarrollo y la cantidad de
defectos.
•Soporte de estandarización: Unos niveles de abstracción claramente definidos
y comúnmente aceptados, permiten el desarrollo de tareas e interfaces
estandarizadas
•Posibilidad de intercambio: Se pueden intercambiar diferentes
implementaciones de la misma capa que sean semánticamente equivalentes,
sin realizar gran esfuerzo.

2.3. Representación Arquitectónica

Este documento presenta l arquitectura de tres niveles como una serie de vistas: vista
de casos de uso, vista lógica, vista de procesos, vista de despliegue, vista de
implementación y vista de datos. Estas vistas se basan en el lenguaje unificado de
modelado (UML).
Se utiliza el modelado de vistas “4+1” de Krunchtenj. En este enfoque se definen 5
vistas diferentes de un mismo sistema cada una de las cuales se enfoca en un aspecto
específico del mismo.

Página 12 de 32
 2.4. Atributos de Calidad y sus Escenarios

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.

REFINAR ESCENARIOS

Página 13 de 32
PRIORIZACION ESCENARIOS

UTILIDAD ESCENARIOS

Página 14 de 32
 3. Objetivos y Restricciones
Arquitectónicas
3.1. Priorización de Requerimiento
El proceso de priorización de requerimientos se realizó tomando los Stakeholders (ver
sección 3.2 resumen de Stakehalders) y mirando la importancia de cada de estos
Stakeholders tiene sobre cada requerimiento.
La primera parte de la priorización es saber el peso que tiene cada Stakehalders del
proyecto, porque no podemos tomar a los Stakehalders por igual, porque cada uno
tiene una importancia diferente dentro del proyecto. Esto lo hacemos tomando los
requerimientos contra los Stakehalders y miramos por cada requerimiento que
Stakehalders está interesado en el requerimiento. Luego se contabiliza el número de
requerimientos que le interesan a cada Stakehalders, para obtener el porcentaje de los
requerimientos que le interesan.

Cuando se tiene el peso de cada Stakehalders, se utiliza este peso para obtener la
prioridad de cada uno de los requerimientos, sumando los pesos de los Stakehalders
interesados en cada requerimiento.

En las siguientes sub secciones se muestra el resumen de los pesos de los

Stakehalders, un resumen de todos los requerimientos y aquellos con prioridad
superior a 7, con el fin de justificar las decisiones arquitectónicas tomadas.

3.1.1. Resumen de ponderación por Stakehalders

Resumen de ponderación por Stakehalders muestra un resumen de la ponderación

asignada de cada Stakehalders del proyecto.
Stakehalders Peso del Stakehalders
Analista de Requerimientos 7.7
Cliente 9.6
Niño 2.5
Arquitecto de Software 6.4
Director de Desarrollo 5.6
Director de Proyecto 4.4
Administrador de Sistema 2.4
Desarrollador 5.7
Tester 6.6

Página 15 de 32
 3.1.2. Resumen de Requerimientos
Muestra un resumen de los requerimientos del sistema.
ID Descripción Prioridad
El usuario puede acceder a las funcionalidades que están
RF-01 5
asociadas al tipo de usuario
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
Es sistema muestra una lista de lugares mas afectados o
RF-12 8
relacionados
El sistema permite activar su ubicación para tener en
RF-13 7
cuenta donde estuvo ubicado
RF-14 El sistema contará con guías para evitar algún contagio 6
El sistema permitirá hacer consultas parte del usuario y
RF-15 9
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 el
RF-21 5
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

3.1.3. Requerimientos de prioridad mayor o igual a 7

ID Descripción Prioridad
RF-02 El usuario se debe registrar con sus datos personales y crear su 7

Página 16 de 32
 propia cuenta
Cada función ejecutiva cuenta con actividades cuyos estímulos
RF-03 10
son visuales y auditivos.
Cada subtipo de atención cuenta con actividades cuyos estímulos
RF-04 10
son visuales y auditivos
RF-05 Cada actividad contará con unas breves instrucciones 8
El sistema muestra al usuario información general de la post
RF-07 8
pandemia
RF-08 Las instrucciones son mostradas al inicio de cada actividad 8
El usuario puede ingresar información sobre algún reporte que
RF-09 8
presenta en un lugar
RF-10 El sistema permite al usuario registrar incidencias 7
RF-11 El sistema muestra incidencias registradas por otros usuarios 7
Es sistema muestra una lista de lugares mas afectados o
RF-12 8
relacionados
El sistema permite activar su ubicación para tener en cuenta
RF-13 7
donde estuvo ubicado
El sistema permitirá hacer consultas parte del usuario y
RF-15 9
registrarlos

3.2. Metas y restricciones arquitectónicas según

requerimientos
Basado en la priorización expuesta en la sección anterior, se plantean las siguientes
metas a cumplir con la arquitectura propuesta:
 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.

Página 17 de 32
 4. Vista de Casos 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.

Página 18 de 32
 4.1. Actores
Los siguientes actores son los que interactuarán con el Subsistema de Reservas de una
vez realizado de deploy.

4.2. Interfaz de Usuario

En esta sección presenta la captura de pantalla de la interfaz del sistema
Infocovid_2020

Página 19 de 32
4.2.1. Vista de Usuario
Login “Infocovid_2020” Registro de Usuarios

Menú Principal del Sistema Alertas de aviso del Sistema

Página 20 de 32
GPS de Registro lugar Infectado Triaje de Control Personal

Cifras de Contagiados Noticias Referente al Covid

Página 21 de 32
4.2.2. Vista Administrador

Login de Administrador Menu Principal Login

Control de Usuarios Registro de Noticias

Página 22 de 32
 Noticias de Usuarios Reporte General

Caso de Uso del sistema InfoCovid_19 muestra

un resumen.
ID NOMBRE DESCRIPCIÓN
Administra la información
general de usuarios y de
CU-1 Administrar datos
las noticias existentes en
el sistema
Gestiona la información
CU-2 Gestiona Usuarios de los usuarios existentes
en el sistema
Crea usuarios con sus
CU -2.2 Crea Usuario
datos necesarios
Consulta información de Consulta información de
CU-2.3
usuario usuario
Elimina usuario que no
CU-2.4 Elimina Usuario entre en un determinado
tiempo
Cambia datos de
información de los
CU-2.5 Actualiza información
usuarios que están
creados
Permite que el usuario y
operador salga del sistema
CU-3 Salir del sistema
guardando cambios que
realizo
CU-4 Ingreso del sistema Permite ingresar al
sistema con los datos

Página 23 de 32
 recientes guardados
Permite al usuario y
CU-5 Crea noticias operador crear noticias
recientes
Crea una presentación
CU-5.1 Enlace presentación para las noticias de
acuerdo al tema
Designa las noticias de
CU-5.2 Designa noticias acuerdo al tema o de lo
que se habla
Usuario u operador
CU-5.3 Crea Reportes
pueden crear reportes
Registra activando la
CU-6 Designa ubicación
ubicación de GPS
Permite desactivar la
CU-6.1 Desactivación de GPS ubicación mientras no se
usa
Permite activar GPS
CU 6.2 Activación de GPS cuando lo requiera o
desee
Permite hacer una
revisión general de los
CU-7 Consulta Reportes
reportes que fueron
subidos
Permite al usuario guardar
CU-7.1 Guarda Reportes los reportes más
relevantes
Permite al usuario
CU-7.1 Eliminar Reportes eliminar el reporte que no
sea de su interés
Permite al sistema
registrar al usuario para
CU-8 Registro de triaje
poder saber más de su
salud
Permite al usuario que
registre los datos que le
CU-8.1 Ingresa datos al triaje
pide el triaje para una
evaluación.

5. Vista Lógica

Página 24 de 32
 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.

5.1. Visión General

La arquitectura general escogida para el sistema infoCovid_19 es Cliente‐ Servidor en
Capas.

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.

5.2. Diseño Arquitectónico de Paquetes Importantes

5.2.1. 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.
5.2.2. 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.
5.2.3. 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.

Página 25 de 32
 6. Vista de Procesos
Para proporcionar un servicio de INFOCOVID_19, comprender la organización de
procesos del sistema, utilizamos una vista de procesos en la disciplina de análisis y
diseño. Solo hay una vista del proceso del sistema. La vista de procesos se perfecciona
durante las iteraciones. Como los aspectos estáticos y dinámicos que ofrecemos a
través de UML.
La figura muestra una vista de procesos parcial para el sistema INFOCOVID_19. Todas
las terminales son administradas por un único proceso terminal, el cual es manejado a
través de mensajes en sus colas de input. Estos objetos controladores se ejecutan en
alguna de las tareas que compone el proceso controlador.

Enlace: https://app.lucidchart.com/invitations/accept/947fd051-0438-4745-9e25-
9d4c270aaedd

Proponemos utilizar los diagramas UML para describir los diferentes aspectos.
De esta manera, el aspecto estático de esta vista se describe por medios los
diagramas de clases y de objetos. Solo que en esta vista pondremos más
atención a las clases activas y los mensajes que fluyen; el aspecto dinámico
por su parte, se describe utilizando los diagramas de interacción, de estados y
de actividades.
De acuerdo con Diana Pallioto y Gabriel Romano, esta vista describe los
aspectos computación y de coordinación de procesos a través de los
elementos: servicio y componente.
Al mantener esta vista de proceso, una relación de correspondencia con el
modelo de casos de uso, los casos de uso que se transforman en servicios y
los actores en componentes. De acuerdo a la semántica de los casos de uso,
los servicios describirán la secuencia de interacciones, o hilo de control del
sistema y sus componentes detallarán las operaciones necesarias.

Página 26 de 32
 7. Vista de Despliegue
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.
El nodo de recurso de ejecución, tal como un computador, un dispositivo o memoria.
Los estereotipos permiten precisar la naturaleza del equipo.
Los nodos se interconectarán mediante soportes bidireccionales que pueden a su vez
estereotiparse. Dada la vista, permitirá determinar las consecuencias de distribución y
la asignación de recursos. Las instancias de los nodos pueden contener instancias de
ejecución, como instancias de componentes y objetos. El modelo dado mostrara
dependencias entre las instancias y sus interfaces, y también modelar la migración de
entidades entre nodos u otros contenedores.
Esta vista tiene una forma de descriptor y otra de instancia. La forma de instancia
muestra la localización de las instancias de los componentes específicos en instancias
especificas del nodo como parte de una configuración del sistema. La forma de
descriptor muestra que tipo componentes pueden subsistir en que tipos de nodos y
que tipo de nodos menos común que la primera.
Nuestro diagrama de despliegue es un grafo de nodos unidos por conexiones de
comunicación. Un nodo puede contener instancias de componentes software, objetos,
procesos. En general el nodo será una unidad de computación de algún tipo, desde un
sensor a un mainframe. La instancia de componente software estará unida por
relaciones de dependencia, posiblemente a interfaces.

Enlace: https://app.lucidchart.com/invitations/accept/d44a98cd-01c5-41e0-
a14e-4f216c74184a

Página 27 de 32
 8. Vista de Implementación

8.1. Descripcion General de la 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.
 Presentación: Es la encargada de tomar los dados que el usuario ingresa al sistema
y enviarlos a la lógica. También se encarga de mostrar al usuario los datos
solicitados. Debido a que se busca disponibilidad en el sistema, está pensada
como un MVC en conjunto con el componente Administrador de Servicios
incluido en la capa de presentación.
 Lógica de Negocio: Se encarga de recibir y atender las solicitudes de los
usuarios. Como fue mencionado antes, el componente Administrador de
Servicios dentro de ésta capa, pertenece al modelo MVC y es quien se
encarga de controlar el flujo de ejecución de las solicitudes de los usuarios
hacia las diferentes funcionalidades del sistema. Es la capa intermedia debido
a que tiene interacción tanto con la capa de presentación como con la
persistencia.
 Capa de persistencia: Se encarga de manejar los datos en memoria para
realizar las operaciones solicitadas por el usuario. Se encarga de acceder a la base
de datos y controla el flujo hacia ella mediante un Administrador de consultas.
8.1.1. Presentación

Página 28 de 32
 Presentación:
Este componente se encarga de la comunicación directa con el
Cliente. Además se encarga de validar y direccionar a los usuarios
dependiendo de su
Perfil y permisos.

 Clientes:
Se encarga de mostrar todos los servicios a los que tiene acceso el
Usuario.

 Personal:
Como clientes, se encarga de mostrar todas las funcionalidades a las que
Tiene acceso.


Administrador de Servicios:
Componente encargado de recibir y direccionar las
Solicitudes a los componentes capaces de atender la petición.

 Servicios Externos:
Componente
Encargado de atender las solicitudes de servicios
Externos (transacciones c
on entidades fuera del sistema)

Página 29 de 32
 Servicios:
Componente encargado de atender y realizar las operaciones solicitadas por
El usuario. Cabe anotar que en el diagrama solo se observa uno
Para una mejor
Representación y entendimiento, sin embargo en el sistema
existen diferentes
Componentes de tipo servicios como generación, eliminación, creación y
consulta.
9.1.3
Persistencia

 Administrador de Consultas:
Este componente se encarga de administrar todas
Las consultas enviadas desde los componentes de servicios de la capa de
Lógica. Es quien
Dirige las peticiones al repositorio.

 Repositorio:
Este componente es la representación dentro del sistema de la base de
datos.

9. Vista de Datos
En esta vista se explica la manera como fueron almacenados los datos en la base de
datos de infoCovid_19. Esta vista es vital porque el sistema se encarga de gestionar
usuarios, actividades y reportes.
Se presenta el modelo de datos utilizado, la distribución y una descripción de los
servicios de persistencia.

Página 30 de 32
Modelo de base de datos infoCovid_19

 El usuario cuenta con todas sus especificaciones de cuenta y

datos personales.
 El usuario puede realizar diversas actividades y acciones.
 El usuario puede guardar sus sesiones y se lleva un registro
completo de cada sesión hecha.
 El usuario puede realizar reportes con toda la información
solicitada.
 El sistema de infoCovid_19 en la base de datos tiene permitido
modificar la configuración de usuario.

10. 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.

Página 31 de 32
 10.1. 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.

11. Calidad
En esta sección se describe como las arquitecturas contribuye a las características no
funcionales del sistema.
11.1. Seguridad
11.1.1. 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.
11.1.2. 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.
11.2. Usabilidad
11.2.1. 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.
11.2.2. Ayudas tipo ToolTipText
El sistema contiene ayudas tipo ToolTipText en cada uno de los botones,
mejorando la usabilidad del sistema.

Página 32 de 32