Entrega - Vistas y más

1. Presentación primaria

Diagrama de clases - Servidor

 Diagrama de clases - Cliente

2. Catálogo de elementos

a. Elementos y responsabilidades

Elemento Responsabilidades

Modelo - Acceso a la capa de almacenamiento

de datos.
- Lleva un registro de las vistas y
controladores del sistema.
- Implementación privilegios de acceso
dentro de la lógica de negocio
(funcionalidad del sistema).
- Notificación a las vistas sobre los
cambios en los registros.

Vista - Recepción de datos del modelo y

muestra dichos datos al usuario.
- Generación de interfaz gráfica para
 mostrar los datos a usuario.

Controlador - Recepción de eventos de entrada.

- Recibir órdenes del usuario, solicitar
los datos al modelo y comunicar a la
vista.

b. Relaciones y Propiedades

Relación Propiedades

Modelo, Vista Relación síncrona entre modelo y vista,

interacción de datos directa.

Vista, Controlador Relación síncrona entre modelo y vista

por el cruce de datos directo y
modificación de interfaces por parte del
controlador, así como el envío de
eventos al controlador por parte de la
vista.

Controlador, Modelo Relación asíncrona entre controlador y

modelo, la interacción de datos no es
directa.
c. Interfaces de los elementos

d. Comportamiento de los elementos

3. Diagrama de contexto
4. Guía de variabilidad

El modelo vista/controlador puede ser integrado con otros Frameworks en

caso de que llegado un momento específico se deba cambiar a otra
herramienta, es importante tener en cuenta que estas herramientas deben
ser integrables con la API implementada.

En caso de que sea necesaria la generación de códigos más complejos para

aumentar la seguridad de la aplicación, se puede tener seguridad de que la
estructura definida contará con buena adaptabilidad para ello, es importante
mencionar que el lenguaje de programación, modelo de arquitectura y
herramienta usada, en este caso los frameworks, permitirán la integración de
este principio.

En caso de que se deban realizar cambios en parámetros de rutas por temas

de competitividad de mercado, la aplicación en su módulo de itinerarios
permitiría un fácil manejo a estas variables, dando así flexibilidad a cambios
en tiempo real.

5. Antecedentes

Patrones de diseño

· Patrón de diseño MVC, nos ayuda a crear una separación lógica

entre el modelo (información y lógica de negocio), la vista (la lógica de
presentación) y el controlador (intermediario entre la vista y el modelo).

· Capas con encapsulamiento. Ambos módulos implementados

(empleados e itinerarios) contará con ésta estructura.

· Arquitectura cliente-servidor. Uno de los modelos más

comunes actualmente, permiten una fácil implementación en la
red y entendimiento para futuros mantenimientos o adiciones en
el hardware del sistema.

Restricciones técnicas de diseño que se pactaron junto a

arquitectos y grupo de desarrollo

· Desarrollo backend con Spring Boot.

· Desarrollo frontend con Angular 8.
· Gestor de bases de datos PostgreSQL

Resultados de análisis
 Se utilizará la arquitectura cliente servidor con el patrón de
diseño MVC obteniendo:

· Clientes que interactúan con los usuarios finales.

· Servidores de aplicación que procesan los datos para los
clientes.
· Servidores de la base de datos que almacenan los datos para
los servidores de aplicación.

Suposiciones

· Teniendo en cuenta que los usuarios pueden acceder al

sistema en cualquier momento, se debe contar con una
disponibilidad mínima del 99.7%

· El sistema está adaptado para que el usuario logre completar

una tarea de itinerario y agenda en un tiempo máximo de 30
minutos, gracias a su diseño intuitivo y de fácil manejo.

· El tiempo de respuesta al momento de realizar las siguientes

transacciones no debe ser superior a 8 segundos.

· El sistema deberá soportar hasta 50 transacciones por

segundo.

· El sistema debe ser capaz de soportar el procesamiento de

hasta 100 usuarios simultáneamente.

6. Información adicional

7.