Arquitectura de

Software DAS – Documento de Arquitectura de Software

Arquitectura de Software para Sistema de Gestión

Arquitectura de Educación Superior
Software Versión 1.0

Pagina 1
asdasd
 Arquitectura de
Software DAS – Documento de Arquitectura de Software

CÓDIGO FECHA DE VIGENCIA VERSIÓN PÁGINAS

UTPL-DAS-001 02/07/2023 1.0 12

Sistema de Gestión para una Institución de Educación

Superior

RUBRO CARGO FIRMA FECHA

ELABORADO Arquitecto de Software 02/07/2023
POR: Edison
Cadena
REVISADO [dd-mm-yyyy]
POR:
APROBADO [dd-mm-yyyy]
POR:

Pagina 2
asdasd
 Arquitectura de
Software DAS – Documento de Arquitectura de Software

Control de cambios y versiones

Fecha Versión Comentarios Autor Estado

02/07/2023 V 1.0 Sistema de Gestión para una Inicial
Edison Cadena
Institución de Educación Superior

Pagina 3
asdasd
 Arquitectura de
Software DAS – Documento de Arquitectura de Software

Tabla de contenidos

CONTROL DE CAMBIOS Y VERSIONES............................................................................................3

1. INTRODUCCIÓN..............................................................................................................................5
2. DESCRIPCIÓN DE LA ARQUITECTURA....................................................................................6
3. DIAGRAMA DE CONTEXTO.........................................................................................................7
4. DIAGRAMA DE CONTENEDORES...............................................................................................8
5. DIAGRAMA DE COMPONENTES.................................................................................................9
2.5 PUNTOS...............................................................................................................................................10
6. DIAGRAMA COMPLEMENTARIO AL MODELO C4.............................................................10
ANTERIORMENTE YA SE REALIZÓ UN DIAGRAMA DE DESPLIEGUE:................................12
7. VOLUMEN DE DATOS Y RENDIMIENTO................................................................................12

Pagina 4
asdasd
 Arquitectura de
Software DAS – Documento de Arquitectura de Software

1. Introducción
El presente documento presenta una descripción de alto nivel, en el cual se diseña y
documenta la arquitectura del sistema denominado “Sistema de Gestión de una Institución de
Educación Superior (SGIES)”. En este documento, denominado Documento de Arquitectura de
Software (DAS), se definen los objetivos de la arquitectura del sistema SGIES, el alcance de la
arquitectura del sistema SGIES y la descripción de la arquitectura de software del SGIES; la
arquitectura de software provee conceptos y técnicas que permiten la definición, diseño, desarrollo
y validación de sistemas medianos, grandes y complejos. Adicional a ello a través de la arquitectura
se describe la estructura (componentes y conectores) de un sistema de software ocultando los
detalles de bajo nivel y abstrayendo las características importantes de alto nivel, utilizando para
ellos modelos para descripción arquitectónica, como el modelo C4 que se basa en la
descomposición estructural de un sistema en contenedores y componentes y hace uso de técnicas
de modelado como UML.

1.1 Objetivo

El objetivo a alcanzar mediante el presente documento consiste en desarrollar la

descripción de la arquitectura diseñada para el sistema SGIES mediante el empleo del
modelo para descripción arquitectónica C4 .

1.2 Alcance

El modelo de descripción arquitectónica está compuesto por 4 diagramas, estos son:

 Contexto: diagrama de alto nivel que establece la escena; incluidas las

dependencias clave del sistema/servicio y las personas (actores / roles / personas /
etc.).
 Contenedor: diagrama que muestra las opciones de tecnología de alto nivel, cómo
se distribuyen las responsabilidades entre ellas y cómo se comunican los
contenedores.
 Componente: para cada contenedor, un diagrama de componentes le permite
visualizar los componentes lógicos clave y sus relaciones.
 Clases (o Código): Este es un nivel de detalle opcional que recoge los diagramas de
clases UML de alto nivel, el cual sirve para explicar cómo se implementará (o se ha
implementado) un componente en particular. Los diagramas UML que se realicen
tienden a ser bocetos o diagramas borrador en lugar de modelos completos.

Cada uno de estos diagramas serán desarrollados en función del contexto del problema y de la
arquitectura diseñada anteriormente para el sistema SGIES.

1.3 Definiciones, acrónimos y abreviaturas

C4: Modelo de Descripción Arquitectónica

HTTPS: Hyper Text Transfer Protocol Secure

SGIES: Sistema de Gestión de una Institución de Educación Superior

DAS: Documento de Arquitectura de Software.

Pagina 5
asdasd
 Arquitectura de
Software DAS – Documento de Arquitectura de Software

UML: Lenguaje Unificado de Modelado.

IDE: Entorno de Desarrollo Integrado (Integrated Development Environment).

BD: Base de Datos.

SOAPUI: SOAP User Interface.

MySQL: Sistema de Gestión de Base de Datos Relacional.

APIs: Interfaz de Programación de Aplicaciones (Application Programming Interface).

RESTful: Transferencia de Estado Representacional (Representational State Transfer).

HTML: HyperText Markup Language.

CSS: Cascading Style Sheets.

JavaScript: Lenguaje de Programación JavaScript.

HTTPS:

1.4 Referencias

Microsoft Docs: Microsoft Docs ofrece documentación técnica detallada sobre arquitectura de
software, patrones de diseño y desarrollo de aplicaciones. Visita la sección de arquitectura de
software en https://docs.microsoft.com/es-es/azure/architecture/.

OMG (Object Management Group): El sitio web oficial de OMG proporciona información sobre
el Lenguaje Unificado de Modelado (UML) y otros estándares relacionados. Puedes acceder a
su documentación y especificaciones técnicas en su página web (www.omg.org).

Software Architecture in Practice" de Len Bass, Paul Clements y Rick Kazman.

"Design Patterns: Elements of Reusable Object-Oriented Software" de Erich Gamma, Richard

Helm, Ralph Johnson y John Vlissides.

"UML Distilled: A Brief Guide to the Standard Object Modeling Language" de Martin Fowler.

García-Holgado, A., Vázquez-Ingelmo, A., & García-Peñalvo, F. J. (2022). Modelo C4.

Vázquez-Ingelmo, A., García-Holgado, A. y García-Peñalvo, F. J. (2020, abril). Modelo C4 en una

asignatura de Ingeniería del Software para facilitar la comprensión de UML y el software.
En 2020 IEEE Global Engineering Education Conference (EDUCON) (pp. 919-924). IEEE.

2. Descripción de la Arquitectura
Tipo de aplicación Web 1.0 La elección de una solución web permite el
acceso al sistema desde diferentes
dispositivos, brindando flexibilidad y
conveniencia a los usuarios, quienes podrán
utilizarlo tanto en computadoras de
escritorio como en dispositivos móviles.
Lenguaje de programación PHP 7.0 PHP es un lenguaje de programación
ampliamente utilizado y compatible con

Pagina 6
asdasd
 Arquitectura de
Software DAS – Documento de Arquitectura de Software

aplicaciones web. Su gran comunidad de

desarrolladores, la disponibilidad de
frameworks y bibliotecas, y su soporte
multiplataforma hacen de PHP una
elección sólida

Capa de persistencia MySQL 8.0 MySQL es un sistema de gestión de

bases de datos relacional de código
abierto, conocido por su rendimiento,
estabilidad y seguridad. Además, es
ampliamente utilizado y cuenta con una
gran cantidad
de recursos y
documentación disponibles.
Componentes UI Bootstrap 5.0 Bootstrap es un framework front-end
popular que ofrece una amplia gama de
componentes y estilos predefinidos para
crear interfaces de usuario modernas y
JavaScript ECMAScript 2021

Librería Cache Memcached 1.6 Memcached es una solución de

almacenamiento en caché distribuido
que mejora el rendimiento y la
escalabilidad de las aplicaciones web al
reducir las consultas a la base de datos y
almacenar datos en memoria.

Herramientas de desarrollo y software base

Elemento Descripción Versión

IDE Visual Studio 2019
Gestor de BD Toad , SQL Developer 15
Tester de Web Services SOAPUI 5.1
Control de versiones Git 2.33
Gestor de dependencias npm 8.1
Documentación Swagger 3.0
Pruebas unitarias NUnit 3.13
Integración continua Jenkins 2.3
Gestión de proyectos Jira 8.18
Colaboración Microsoft Teams 1.14
Virtualización Docker 10.20

Pagina 7
asdasd
 Arquitectura de
Software DAS – Documento de Arquitectura de Software

Listado de atributos de calidad

Atributo de calidad Clasificación Atributos externos/internos

Seguridad Funcionamiento general En tiempo de ejecución
Usabilidad Funcionamiento general De diseño
Disponibilidad Funcionamiento general De diseño, en tiempo de
ejecución
Mantenibilidad Desarrollo De diseño, de sistema
Escalabilidad Desarrollo De diseño, de sistema
Flexibilidad Desarrollo De diseño, de sistema
Portabilidad Despliegue De diseño, de sistema
Eficiencia Despliegue En tiempo de ejecución, de
sistema.

Selección de atributos de calidad

⮚ Seguridad:

● Por qué: Utilizaré la seguridad como atributo de calidad para proteger la

información confidencial de los usuarios y garantizar la integridad y
confidencialidad de los datos.

● Para qué: El objetivo es prevenir accesos no autorizados, proteger contra

ataques maliciosos y mantener la confianza de los usuarios en la
aplicación.

● Cómo: Implementaré medidas de seguridad, como autenticación de

usuarios, cifrado de datos, protección contra ataques conocidos y
pruebas de seguridad para identificar y solucionar posibles
vulnerabilidades.

⮚ Usabilidad:

● Por qué: Utilizaré la usabilidad como atributo de calidad para garantizar

que los usuarios puedan interactuar fácilmente con la aplicación, sin
dificultades ni confusiones.

● Para qué: El objetivo es facilitar la navegación, realización de tareas y

comprensión del sistema, mejorando la experiencia del usuario.

● Cómo: Aplicaré principios de diseño centrados en el usuario, como una

interfaz intuitiva, estructura de navegación clara y retroalimentación

Pagina 8
asdasd
 Arquitectura de
Software DAS – Documento de Arquitectura de Software

visual. Realizaré pruebas de usabilidad con usuarios reales para identificar

posibles mejoras en la experiencia de uso.

⮚ Disponibilidad:

● Por qué: Utilizaré la disponibilidad como atributo de calidad para

asegurar que la aplicación esté disponible y funcional cuando los usuarios
la necesiten.

● Para qué: El objetivo es evitar tiempos de inactividad y garantizar el

acceso continuo a la aplicación, maximizando su disponibilidad.

● Cómo: Implementaré medidas como la redundancia de servidores, copias

de seguridad regulares, monitoreo constante y planes de contingencia
para mitigar interrupciones y minimizar el impacto en la disponibilidad
del sistema.

⮚ Mantenibilidad:

● Por qué: Utilizaré la mantenibilidad como atributo de calidad para

facilitar la modificación, reparación y mejora de la aplicación en el
tiempo.

● Para qué: El objetivo es asegurar que el sistema sea fácil de mantener y

evolucionar, permitiendo la incorporación de nuevas funcionalidades o la
corrección de errores.

● Cómo: Aplicaré buenas prácticas de desarrollo de software, como el uso

de código limpio, modularidad, documentación adecuada y pruebas
automatizadas. Además, utilizaré patrones de diseño que promuevan la
mantenibilidad y la escalabilidad del sistema.

3. Diagrama de Contexto

El diagrama de contexto es el punto de partida para tener una visión general del sistema y
su relación con otros sistemas de software y las personas que lo usarán. En este diagrama los
detalles no son importantes, a continuación, se presenta unos lineamientos para su creación:

- Elementos soportados en el diagrama: Personas y Sistemas de Software.

- El enfoque debe estar en las personas y los sistemas de software relacionados

- No se debe especificar tecnologías, protocolos, ni otros detalles de bajo nivel.

- La audiencia son personas técnicas y no técnicas dentro y fuera del equipo del
proyecto.

Pagina 9
asdasd
 Arquitectura de
Software DAS – Documento de Arquitectura de Software

Explicación del Diagrama de Contexto.

En este diagrama se tiene una visión general del SGIES y como se relaciona con los
restantes sistemas de software que interactúa, además de los usuarios que emplearán el
sistema, en este caso serán Profesores, estudiantes y personal administrativo de la institución
de educación superior, los cuáles mediante el login respectivo ingresan al sistema con su rol
respectivo y emplean las opciones asignadas a su rol.

Context

4. Diagrama de Contenedores
En el modelo C4 un contenedor no debe confundirse con “docker”, y más bien el término
contenedor hace referencia a una unidad ejecutable, por ejemplo: aplicación web de servidor,
aplicación web de cliente (SPA), aplicación de escritorio, un JOB, un scrtip, una app móvil, una base
de datos o esquema de base de datos, un sistema de archivos, etc.

Este diagrama describe la arquitectura del software a alto nivel, identificando los principales
contenedores, sus relaciones y responsabilidades. Aquí se especifica también las tecnologías y
protocolos de comunicación a usar. A continuación, se presenta unos lineamientos para su
creación:

- Elementos soportados en el diagrama: Contenedores, Personas y Sistemas de Software.

Pagina 10
asdasd
 Arquitectura de
Software DAS – Documento de Arquitectura de Software

- La audiencia son personas técnicas dentro y fuera del equipo del proyecto.

- No se debe especificar modelos de despliegue, esquemas de failover, clustering, etc.

Explicación del Diagrama de Contenedores.

La aplicación web es una aplicación PHP 7.0/Visual Studio 2019 del lado del servidor,
que gestiona el contenido hacia una página web (Html, Css y JavaScript) que se ejecuta en el
navegador del cliente proporcionando las opciones de gestión según el usuario y el rol. La
información para toda la gestión académica y económica se almacena en una base de datos
relacional (MySql). Se representa cada una de las unidades ejecutables del sistema propuesto.

Container

Pagina 11
asdasd
 Arquitectura de
Software DAS – Documento de Arquitectura de Software

5. Diagrama de Componentes
Explicación del Diagrama de Componentes.
El diagrama de componentes permite identificar los principales bloques de construcción
(building blocks) que forman un contenedor, así como sus relaciones. Estos bloques de
construcción se conocen en el modelo C4 como componentes, entiéndase por componente una
agrupación de funcionalidades relacionadas. A continuación, se presenta unos lineamientos para su
creación:

- Elementos soportados en el diagrama: Componentes, Contenedores, Personas y Sistemas

de Software.

- La audiencia son los arquitectos y desarrolladores de software dentro del equipo del
proyecto.

Pagina 12
asdasd
 Arquitectura de
Software DAS – Documento de Arquitectura de Software

Component

6. Diagrama complementario al modelo C4

Para lograr una visión integral del sistema, es necesario generar el Diagrama de Despliegue o
también denominado de infraestructura física, en donde se especifiquen detalles de la plataforma
base, máquinas virtuales, sistema operativo, modelo de despliegue (on-premise, IaaS, PaaS, SaaS),
Docker, etc.

Deployment

Pagina 13
asdasd
 Arquitectura de
Software DAS – Documento de Arquitectura de Software

En la teoría indica que el diagrama complementario también se define como el modelo del
código.

Deployment

Pagina 14
asdasd
 Arquitectura de
Software DAS – Documento de Arquitectura de Software

7. Volumen de datos y rendimiento

El volumen de datos que va a soportar la capa de persistencia tiene un impacto directo

sobre el rendimiento del sistema. Se debe tener información histórica de las transacciones
generadas por período de tiempo, un estimado, para poder realizar los cálculos respectivos y
mediante el DDL (Lenguaje de Definición de Datos) poder crear la estructura más adecuada
para la capa de persistencia, posteriormente mediante el DML (Lenguaje de manipulación de
datos) poder manipular la información para interactuar con la capa de persistencia mediante la
aplicación web y la aplicación del lado del cliente propuesto.
Una vez implementada físicamente la capa de persistencia es necesario realizar pruebas de
rendimiento, mediante técnicas para probar justamente el rendimiento de nuestro sistema en
diferentes escenarios, solo con estas pruebas se podrán obtener índices de rendimiento y
determinar el verdadero nivel de rendimiento de nuestra aplicación. Con toda la información
histórica transaccional y con la información de épocas en las cuales se tiene mayor
concurrencia de usuarios se puede realizar una evaluación del rendimiento.

Es importante el diseño de la infraestructura tecnológica que se deba implementar

para asegurar un rendimiento óptimo.

Pagina 15
asdasd