UNIVERSIDAD AUTÓNOMA DEL BENI

“JOSÉ BALLIVIÁN”
ALSIE CONSULTORES PEDAGÓGICOS

TÍTULO:
Propuesta de una arquitectura para
reemplazar el sistema informático la
empresa SeLA – Oruro

Tesis de Grado para optar el Título de:

Diplomado en Diseño y Arquitectura de Software

Postulante:

Ing. Saul Mamani Mamani

Tutor:

Ph. D. Aidel Santos Santos

Agosto, 2020

Cochabamba - Bolivia
 AGRADECIMIENTOS

A Dios, a mis padres, a mi

novia, y a mis docentes por
todo su apoyo
Gracias por compartir su
conocimiento
 DEDICATORIA

Dedico es trabajo a la
empresa SeLA Oruro por
permitirme ser parte de su
equipo de desarrollo y
aportar con mi
conocimiento.
 ÍNDICE

INTRODUCCIÓN ........................................................................................................ 1

Problema Científico ................................................................................................. 2

Objeto de Estudio: Obsolescencia o Caducidad de arquitectura y software ............ 3

Objetivo General ...................................................................................................... 4

Objetivos Específicos .............................................................................................. 4

Campo de Acción: Servicio Local de Acueductos y Alcantarillado SeLA – Oruro.... 4

Hipótesis .................................................................................................................. 5

Métodos y Técnicas ................................................................................................. 5

CAPÍTULO I ................................................................................................................ 6
CARACTERIZACIÓN DE ARQUITECTURA Y TECNOLOGÍA OBSOLETA ............. 6

1.1 Definición rectora caducidad de arquitectura y software ................................ 6

1.2 Matriz de variables ......................................................................................... 6

1.3 Operacionalización de variables .................................................................... 7

1.4 Aplicación de instrumentos ............................................................................ 8

1.5 Resultados y caracterización ......................................................................... 8

CAPÍTULO II ............................................................................................................... 9
ARQUITECTURA DE SOFTWARE ............................................................................ 9

2.1 Arquitectura de software ................................................................................ 9

2.1.1 Definición de arquitectura de software................................................... 10

2.2 Elementos comunes de una arquitectura de software.................................. 10

2.3 Principios de la arquitectura de software...................................................... 11

2.4 El ciclo de desarrollo de la arquitectura........................................................ 13

2.5 Patrones de arquitectura .............................................................................. 14

2.6 Tendencias arquitectónicas .......................................................................... 15

2.6.1 Patrones estructurales ........................................................................... 15

 2.6.2 Patrones de representación ................................................................... 16

2.6.3 Patrones de implementación ................................................................. 17

2.6.4 Patrones de evolución ........................................................................... 18

CAPÍTULO III ............................................................................................................ 19
PROPUESTA ARQUITECTÓNICA ........................................................................... 19

3.1 Descripción de la empresa ........................................................................... 19

3.2 Análisis de la arquitectura del sistema actual............................................... 21

3.2.1 Identificación de problemas ................................................................... 22

3.3 Análisis de requerimientos y definición del contexto del sistema ................. 23

3.4 Diseño de la nueva arquitectura propuesta .................................................. 24

3.5 Estrategia para el despliegue ....................................................................... 30

3.6 Estrategia para la migración de datos .......................................................... 31

3.7 Aplicación de los patrones de arquitectura ................................................... 32

3.8 Aplicación de los principios de diseño .......................................................... 32

3.9 Evaluación de la arquitectura propuesta ...................................................... 34

CONCLUSIONES ..................................................................................................... 35
RECOMENDACIONES ............................................................................................. 36
REFERENCIAS BIBLIOGRÁFICAS ......................................................................... 37
 ÍNDICE DE TABLAS Y FIGURAS

Tablas

Tabla 1. Métodos y técnicas ........................................................................................ 5

Tabla 2. Matriz de variables ........................................................................................ 6

Tabla 3. Operacionalización de variables .................................................................... 7

Figuras

Figura 1. Organigrama de la empresa ....................................................................... 20

Figura 2. Arquitectura actual del sistema .................................................................. 21

Figura 3. Nivel 1 – Contexto del sistema ................................................................... 25

Figura 4. Nivel 2 – Contenedores del sistema ........................................................... 26

Figura 5. Nivel 3 – Componentes del sistema ........................................................... 28

Figura 6. Estrategia para el despliegue ..................................................................... 30

Figura 7. Estrategia para la migración de datos ........................................................ 31

 INTRODUCCIÓN

La industria del software a medida que va evolucionando, requiere cada vez nuevas
formas de plantear soluciones óptimas, robustas y escalables, de tal manera que el
código pueda ser mantenible en el tiempo con el mínimo costo posible.

Hace no mucho tiempo atrás los sistemas de escritorio eran la única forma de
desarrollar soluciones informáticas, aunque aún se sigan utilizando estos presentan
varios problemas, especialmente cuando se habla de costos de mantenimiento. Todo
esto ha ido evolucionando de tal forma que ahora los más común y factible es
desarrollar aplicaciones de web y aplicaciones móviles.

La forma de estructurar u organizar un software también ha evolucionado con el tiempo

y se ha adaptado al contexto de los problemas y a las nuevas tecnologías, dicho de
otra forma, la arquitectura de software también ha evolucionado con el tiempo.

Las arquitecturas monolíticas eran comunes en los inicios del desarrollo de software,
según la necesidad estos han ido evolucionando a arquitecturas cliente – servidor para
que puedan trabajar dentro de una infraestructura de red. Con la aparición de los
sistemas web, las arquitecturas MVC han sido muy populares ya que separaba en
capas bien definidas la interfaz del usuario, la lógica del negocio el acceso a los datos.
Las arquitecturas orientadas a servicios SOA, fueron esenciales para escalar los
sistemas a niveles macro, esto fue evolucionando y ahora se utilizan varios derivados
como las arquitecturas de microservicios para compartir información entre diferentes
plataformas y dispositivos.

Una arquitectura de software define la forma de trabajar en un sistema, como construir

nuevos módulos, pero también debe dejar intuir el tipo de aplicación que describe. Tal
como comenta Uncle Bob, si mostráramos un dibujo arquitectónico de una iglesia o de
un piso, simplemente con ver la forma que tiene ese dibujo podemos intuir que tipo de
edificio está proyectando. Así pues, si observamos nuestro dibujo arquitectónico de
software deberíamos de poder intuir qué tipo de aplicación va a ser construida. No es

1
lo mismo una aplicación que controla un hospital que una aplicación de un cajero
automático, cada una tendría un dibujo arquitectónico distinto.

Problema Científico

Para administrar los procesos del Servido Local de Acueductos y Alcantarillados SeLA
– Oruro, actualmente la empresa cuenta con un sistema informático de escritorio que
está en funcionamiento e instalado en las máquinas de todos los funcionarios que
utilizan el sistema. A la fecha el sistema presenta muchos problemas debido a su
arquitectura y a la tecnología con la que fue desarrollada, tecnología que ha quedado
obsoleto.

El sistema fue desarrollado en Visual FoxPro bajo una arquitectura monolítica y su

propio sistema de archivos de base de datos DBF1. Hasta la fecha recibe parches de
actualización para que siga en funcionamiento.

Visual FoxPro es un lenguaje de programación de paga, lo que representa un gasto

económico para la empresa, a esto se suma la dificultad y el costo de mantenimiento
del sistema debido a su arquitectura monolítica.

Para que el sistema trabaje en red, lo que se ha hecho es compartir una carpeta con
las tablas DBF de la base de datos, ocasionando problemas de seguridad. Se observó
que estas fallas son provocadas por los errores de configuración y el diseño en la base
de datos.

La naturaleza de la base de datos también presenta problemas, ya que la empresa ha

crecido bastante en los últimos años y se manejan miles de datos y transacciones
concurrentes, esto provoca que los índices de las tablas se rompan poniendo en riesgo
la integridad de los datos y ocasionando que le sistema deje de funcionar de manera
recurrente.

1 La extensión de archivo .dbf representa el archivo de base de datos dBase

2
Los nuevos requerimientos también son un problema ya que el sistema no puede ser
escalado para que funcione a través de internet o comparte información con los nuevos
dispositivos móviles, a esto se suma la falta de programadores de Visual FoxPro.

El sistema está quedando obsoleto debido a estos problemas, por lo que la empresa
está buscando la forma de reemplazar por completo es sistema actual por un nuevo
sistema con tecnología actual, base de datos robusta, y bajos costos de
mantenimiento.

Por lo tanto, se busca la mejor estrategia para reemplazar el sistema actual de SeLA
– Oruro por un nuevo sistema informático, que permita migrar toda la funcionalidad
implementada del sistema actual, que se mantenga la integridad de los datos, se
agreguen nuevas características, y sobre todo se reduzcan los costos de
mantenimiento.

Objeto de Estudio: Obsolescencia o Caducidad de arquitectura y software

Una arquitectura inadecuada le impide a un sistema crecer al ritmo de crecimiento de

la propia empresa. Por esta razón se debe plantear nuevas arquitecturas flexibles al
cambio.

Las tecnologías obsoletas provocan gastos de mantenimiento elevados, inconsistencia

en la información almacenada, fallas en los sistemas, etc. La empresa necesita que su
información sea confiable, integro y seguro, lo que le lleva a migrar hacia tecnologías
modernas, robustas, libres y de código abierto.

El investigador asume como objeto de estudio a la arquitectura y la tecnología del

sistema de información actual que está quedando caduco u obsoleto. Los cuales
provocan fallos recurrentes, altos costos de mantenimiento, y le impiden escalar hacia
nuevas funcionalidades. Además, que, a partir de esto, se derivará la identificación de
los procesos implementados, las características faltantes y la migración de los datos
al nuevo sistema.

3
Objetivo General

Proponer una arquitectura flexible y robusta que permita reemplazar por completo el
sistema actual de la empresa de Servicio local de Acueductos y Alcantarillado SeLA –
Oruro por un nuevo sistema desarrollado con tecnología moderna y robusta. De tal
forma que se migre toda la funcionalidad al nuevo sistema, se mantenga la integridad
de los datos, se agreguen nuevas características, y se reduzcan los costos de
mantenimiento.

Objetivos Específicos

Se definen los objetivos específicos que ayudan a cumplir el objetivo general:

1. Caracterizar la arquitectura y la utilidad del sistema informático en la

automatización de los procesos de la empresa de Servicio local de Acueductos
y Alcantarillado SeLA – Oruro

2. Sistematizar los principales fundamentos teóricos y metodológicos referidos a

la arquitectura de software, a los patrones de arquitectura, y a las tendencias
arquitectónicas.

3. Analizar y diseñar la propuesta de una nueva arquitectura para implementar

nuevo sistema que reemplace por completo al sistema actual.

Campo de Acción: Servicio Local de Acueductos y Alcantarillado SeLA – Oruro

El Servicio Local de Acueductos y Alcantarillado SeLA – Oruro, es la empresa

encargada de distribuir agua potable a toda la ciudad de Oruro. Para realizar sus
transacciones y operaciones se apoya en el sistema informático SeLASIS. Este
sistema presenta fallas recurrentes debido a su arquitectura y a la tecnología con la
que fue desarrollada.

4
Hipótesis

La elaboración de una nueva arquitectura de software flexible y robusta, permitirá

reemplazar por completo el sistema actual de SeLA por un nuevo sistema informático,
eliminando los problemas asociados al antiguo sistema y reduciendo los costos de
mantenimiento.

Métodos y Técnicas

Los métodos y técnicas aplicadas se describen en la siguiente tabla.

Tabla 1. Métodos y técnicas

Métodos Tipo Técnica

Análisis Documental Teóricos Guía de Revisión

Entrevista Empírico Cuestionarios

Mapeo de Base de Datos Informático Ingeniería Inversa: Reflexión Base de

Datos

Análisis y Diseño de Informático Ingeniería inversa, del sistema actual.

Arquitectura de software
Análisis, de las nuevas características
Implementación, de patrones de
arquitectura
Aplicación de los principios de diseño
de arquitectura de software

Observación Empírico Guía de Observación

5
 CAPÍTULO I

CARACTERIZACIÓN DE ARQUITECTURA Y TECNOLOGÍA OBSOLETA

1.1 Definición rectora caducidad de arquitectura y software

Una arquitectura obsoleta impide que el software evolucione y se adapte a las nuevas
necesidades de una empresa en constante crecimiento. Debido a su tecnología e
infraestructura, los costos de mantenimiento son elevados.

Todo software tiende a tener un tiempo límite de vida por el avance tecnológico que
hará que el software caduque y comience a presentar fallas hasta llegar al punto de
quedar obsoleto, lo que nos lleva a actualizar o a adquirir un software más actual
acorde con la época y las necesidades de la empresa.

1.2 Matriz de variables

Tabla 2. Matriz de variables

Objeto de Estudio Variables

Obsolescencia o Bases De Datos

caducidad de Factores asociados al acceso a los sistemas de
arquitectura y persistencia, modelos y estructura interna
software
Mantenibilidad
Factores asociados a la corrección de errores,
implementación de nueva funcionalidad y procesos de
soporte

Arquitectura
Factores asociados respecto a la representación y
organización de los componentes del software

Infraestructura
Factores relacionados con los ambientes de despliegue,
sistemas operativos, redes, servidores y contenedores de
hardware

6
1.3 Operacionalización de variables

Tabla 3. Operacionalización de variables

Variables Dimensiones Indicadores

V1. V1. D1. - Tipos de acceso

Bases de Accesibilidad a bases - Usuarios y permisos
Datos de datos - Cifrado de datos

V1. D2. - Modelos de migración

Modelos de - Tipo de base de datos
persistencia - Normalización
- Estructura general
- Nomenclatura legible
- Modela relacional
- Esquemas

V2. V2. D1. - Cohesión entre componentes

Mantenibilidad Aplicación de prácticas - Acoplamiento
estándar - Legibilidad del código
- Automatización de pruebas
- Versionamiento de código
- Tecnologías de implementación
- Aplicación de patrones de diseño
- Aplicación de principios SOLID

V2. D2. - Legibilidad de documentación

Documentación del - Documentación actualizada
sistema - Diseño explícito
- Manuales técnicos y de usuario
- Diagramas del sistema

V2. D3. - Costos de licencias de software

Costos privativo

V3. V3. D1. - Análisis y diseño de la arquitectura de

Arquitectura Principios de software
arquitectura - Aplicación de principio de arquitectura
de software

V3. D2. Patrones de - Patrones estructurales

arquitectura - Patrones de representación
- Patrones de implementación
- Patrones de evolución

7
 V4. V4. D1. - Mapa de despliegue
Infraestructura Plataforma de - Proceso de despliegue
despliegue - Tecnologías de despliegue

V4. D2. Relación de - Cohesión y acoplamiento de alto nivel

componentes y - Consistencia de diseño y modelo
dependencia

V4. D3. Hardware - Vigencia del hardware

- Soporte de largo alcance
- Accesibilidad

1.4 Aplicación de instrumentos

A continuación, se lista los instrumentos que se utilizan para la caracterización.

− Entrevistas

− Ingeniería inversa y reingeniería

− Notaciones para el modelado de sistemas software

− Análisis de arquitecturas de software

1.5 Resultados y caracterización

Se resume la información recolectada del encargado de sistemas, del equipo de

desarrollo, y de los usuarios del sistema informático de SeLa – Oruro.

− El sistema actual está desarrollado bajo una arquitectura monolítica

− El sistema está programado en Microsoft Visual FoxPro 7

− Se incurren en gastos por el pago de licencias

− Los datos persisten en un sistema de archivos DBF

− Se rompen los índices de las tablas debido a la cantidad de registros, el cual

provoca que el sistema quede inutilizable

− Problemas de seguridad con la base de datos que se encuentra en una carpeta

compartida dentro la red local.

8
 CAPÍTULO II

ARQUITECTURA DE SOFTWARE

2.1 Arquitectura de software

La arquitectura del software es una disciplina muy relevante en la actualidad, y a la

que no siempre se le otorga la debida importancia. En el mundo del desarrollo nos
enfrentamos a sistemas complejos. Si bien es cierto que no todo el software tiene por
qué ser realmente complejo, es necesario establecer unas bases sólidas para facilitar
su mantenimiento y su crecimiento en el futuro.

El mantenimiento es esencial, porque, aunque un software se pueda desarrollar en

unas pocas semanas o meses, lo más probable es que se mantenga durante años,
añadiendo nuevas funcionalidades requeridas, o corrigiendo problemas existentes. El
crecimiento también es fundamental, porque todo software cuya funcionalidad no se
amplíe o se modifique, tiende a ser inservible en un relativamente corto espacio de
tiempo.

A medida que el software comienza a crecer y a hacerse más complejo, es importante

que tenga una forma bien definida, de modo que seamos capaces de entenderlo como
un todo. De no ser así, al examinar cada una de sus partes por separado, lo más
normal es que seamos incapaces de interpretar correctamente el funcionamiento y el
motivo de su existencia.

La arquitectura del software por tanto define la estructura que debe tener un software,
las piezas que debemos construir y el modo en el que se deben de juntar y trabajar
entre ellas.

El diseño arquitectónico representa la estructura de los datos y de los componentes

del programa que se requieren para construir un sistema basado en computadora.

La arquitectura de software permite:

− Analizar la efectividad del diseño para cumplir los requerimientos establecidos.

9
 − Considerar alternativas arquitectónicas en una etapa en la que hacer cambios
al diseño todavía es relativamente fácil.

− Reducir los riesgos asociados con la construcción del software.

2.1.1 Definición de arquitectura de software

Una Arquitectura del software es el conjunto de decisiones significativas sobre la

organización de un sistema que define los principios que guían el desarrollo, los
componentes principales del sistema, sus responsabilidades y la forma en que se
interrelacionan.

Citamos la definición más adecuada de arquitectura de software.

"Toda la arquitectura es diseño, pero no todo el diseño es arquitectura. La arquitectura

representa las decisiones de diseño significativas que le dan forma a un sistema,
donde lo significativo puede ser medido por el costo del cambio". (Grady Booch)

2.2 Elementos comunes de una arquitectura de software

La arquitectura de software es una disciplina cambiante y en evolución, por lo tanto,

no existe hasta la fecha un estándar establecido por la industria. Su forma y estructura,
y su documentación cambia de acuerdo al contexto, al nivel de abstracción, y al
sistema que se esté estudiando. Sin embargo, la arquitectura de software en si tiene
elementos y conceptos comunes.

a) Alto nivel.

Generalmente se modela la arquitectura a un alto nivel de abstracción, dejando

de lado los detalles de implementación. Esto con el fin de dar un buen panorama
del sistema y asegurarse que sea el correcto.

b) Estructura.

Se refiere a la forma de organización del proyecto, del software, de la base de

datos, del programa, etc.

10
 c) Capas.

Se puede modelar la arquitectura desde diferentes capas de niveles de

abstracción separados en componentes, módulos o sub sistemas.

d) Relaciones entre las capas.

Se refiere a la forma en como estas capas se relacionan entre sí para trabajar

como un todo.

2.3 Principios de la arquitectura de software

Existen varios principios que guían al diseño de una buena arquitectura de software,
entre las que podemos mencionar:

a) ETC (Easy To Change).

Este principio se refiere a que se debe diseñar la arquitectura del software

pensando para que sea flexible al cambio de requerimientos funcionales y de
tecnología, logrando aislar el software en componentes reemplazables con bajo
acoplamiento y alta cohesión.

b) DRY (Don’t Repeat Yourseft)

Este principio se basa en no repetir componentes, sistemas, servidores,

tecnología, etc. En fin, minimizar la duplicidad.

El software debe evitar especificar el comportamiento relacionado con un

determinado concepto en varios lugares, ya que esta práctica es una fuente de
errores frecuente. En algún momento, un cambio en los requisitos requerirá
cambiar este comportamiento. Es probable que al menos una instancia del
comportamiento no se pueda actualizar, y que el sistema se comporte de
manera incoherente.

En lugar de duplicar la lógica, se puede encapsular en una construcción de

programación. Convierta esta construcción en la única autoridad sobre este

11
 comportamiento y haga que cualquier otro elemento de la aplicación que
requiera este comportamiento use la nueva construcción

c) Orthogonality

El principio de ortogonalidad se refiere a lograr abstraer el sistema en

componentes altamente cohesivos e independientes, de tal forma, que los
cambios en un componente no afecten a otros, logrando reducir la
interdependencia entre componentes.

En un software ortogonal las operaciones no tienen efectos laterales, cada

operación cambia una cosa sin afectar a otras, de esta forma el código es más
fácil de testear y ampliar. La mejora en la calidad de código es inmediata, así
como una mayor productividad y una disminución del riesgo de errores.

Cuando un software no es ortogonal es muy difícil de cambiar y controlar. Al

estar las piezas de software altamente dependientes unas de otras, cualquier
cambio en una de ellas va a suponer un considerable esfuerzo y puede hacer
que algo deje de funcionar. Sin embargo, si fuera ortogonal, al ampliar una
unidad de software no tendríamos que preocuparnos de ninguna más.

d) Reversibility

El principio de reversibilidad en ingeniería de software indica que la arquitectura

no debería depende de la tecnología final de implantación (como un lenguaje
de programación en específico, un gestor de base de datos, etc.) logrando
sistemas flexibles al cambio.

Como la arquitectura debe ser flexible al cambio y se debe adaptar al contexto

de objeto de estudio, no deberían existir decisiones finales sobre el uso de
tecnología o procedimientos de comunicación o implementación.

e) Tracer Bullet

Muchas veces se necesita saber si se está caminando por el camino correcto,

diseñando o construyendo el producto adecuado, por esta razón se desarrollan

12
 prototipos de pequeñas funcionalidades; también se puede diseñar mockups o
interfases de usuario, para mostrarle a los clientes una idea de lo que se está
construyendo. A esto se refiere Tracer Bullet o Balas trazadoras.

2.4 El ciclo de desarrollo de la arquitectura

Dentro de un proyecto de desarrollo, e independientemente de la metodología que se

utilice, se puede hablar de “desarrollo de la arquitectura de software”. Este desarrollo,
que precede a la construcción del sistema, está dividido en las siguientes etapas:
requerimientos, diseño, documentación y evaluación. Cabe señalar que las actividades
relacionadas con el desarrollo de la arquitectura de software generalmente forman
parte de las actividades definidas dentro de las metodologías de desarrollo.

A continuación, se describen dichas etapas.

a) Requerimientos.

La etapa de requerimientos se enfoca en la captura, documentación y

priorización de requerimientos que influencian la arquitectura. Como se
mencionó anteriormente, los atributos de calidad juegan un papel
preponderante dentro de estos requerimientos, así que esta etapa hace énfasis
en ellos. Otros requerimientos, sin embargo, son también relevantes para la
arquitectura, estos son los requerimientos funcionales primarios y las
restricciones.

b) Diseño.

La etapa de diseño es la etapa central en relación con la arquitectura y

probablemente la más compleja. Durante esta etapa se definen las estructuras
que componen la arquitectura. La creación de estas estructuras se hace en base
a patrones de diseño, tácticas de diseño y elecciones tecnológicas. El diseño
que se realiza debe buscar ante todo satisfacer los requerimientos que
influencian a la arquitectura, y no simplemente incorporar diversas tecnologías
porque están “de moda”.

13
 c) Documentación.

Una vez creado el diseño de la arquitectura, es necesario poder comunicarlo a

otros involucrados dentro del desarrollo. La comunicación exitosa del diseño
muchas veces depende de que dicho diseño sea documentado de forma
apropiada. La documentación de una arquitectura involucra la representación
de varias de sus estructuras que son representadas a través de distintas vistas.
Una vista generalmente contiene un diagrama, además de información
adicional, que apoya en la comprensión de dicho diagrama.

d) Evaluación.

Dado que la arquitectura de software juega un papel crítico en el desarrollo, es

conveniente evaluar el diseño una vez que este ha sido documentado con el fin
de identificar posibles problemas y riesgos. La ventaja de evaluar el diseño es
que es una actividad que se puede realizar de manera temprana (aún antes de
codificar), y que el costo de corrección de los defectos identificados a través de
la evaluación es mucho menor al costo que tendría el corregir estos defectos
una vez que el sistema ha sido construido.

2.5 Patrones de arquitectura

Se puede definir a un patrón como una solución aplicable repetidamente a un problema

que surge en un contexto específico. Son modelos que se pueden reutilizar en
diferentes escenarios.

Los patrones arquitectónicos son formas de capturar estructuras de diseño de probada

eficacia, para que puedan ser reutilizadas. Los arquitectos de software han estado
buscando formas de capturar y reutilizar el conocimiento arquitectónico que han
probado ser exitosos en el pasado.

Un patrón propone una solución arquitectónica que sirve como base para el diseño de
la arquitectura de un software.

14
De acuerdo al problema que se está tratando de resolver, se pueden aplicar uno o
varios patrones de arquitectura que ayuden a resolver el problema.

2.6 Tendencias arquitectónicas

Existen muchos patrones relacionados con la arquitectura de software, las cuales se

las puede dividir en los siguiente grupos o tendencias arquitectónicas.

2.6.1 Patrones estructurales

Son patrones que se enfocan en la forma, estructura u organización del software a

nivel macro, entre las cuales se puede mencionar las siguientes:

a) Arquitectura monolítica

Consiste en una simple instancia que maneja procesos y servicios a través de

un flujo de datos.

Se puede decir que la arquitectura monolítica es aquella en la que el software

se estructura de forma que todos los aspectos funcionales del mismo quedan
acoplados y sujetos en un mismo programa.

b) Patrón Cliente – Servidor

Este patrón consiste en dos partes; un servidor y múltiples clientes. El

componente del servidor proporcionará servicios a múltiples componentes del
cliente. Los clientes solicitan servicios del servidor y el servidor proporciona
servicios relevantes a esos clientes. Además, el servidor sigue escuchando las
solicitudes de los clientes.

c) Patrón MVC (Modelo Vista Controlador)

Este patrón, divide una aplicación interactiva en 3 partes, como

− Modelo: contiene la funcionalidad y los datos básicos

− Vista: muestra la información al usuario (se puede definir más de una

vista)

15
 − Controlador: maneja la entrada del usuario

Esto se hace para separar las representaciones internas de información de las

formas en que se presenta y acepta la información del usuario. Desacopla los
componentes y permite la reutilización eficiente del código.

d) Patrón de arquitectura en capas

El patrón arquitectónico más común es el patrón arquitectónico en capas. Los

patrones de arquitectura en capas son patrones de n niveles donde los
componentes están organizados en capas horizontales. Este es el método
tradicional para diseñar la mayoría de los programas informáticos y está
destinado a ser auto independiente. Esto significa que todos los componentes
están interconectados, pero no dependen unos de otros. Cada capa del patrón
de arquitectura en capas tiene un papel y una responsabilidad específicos
dentro de la aplicación. Por ejemplo, una capa de presentación se encargaría
de manejar toda la interfaz de usuario y la lógica de comunicación del
navegador, mientras que una capa empresarial se encargaría de ejecutar las
reglas empresariales específicas asociadas a la solicitud.

e) Patrón de microservicios

Cuando escribes tu solicitud como un conjunto de microservicios, en realidad

estás escribiendo múltiples solicitudes que funcionarán juntas. Cada
microservicio tiene su propia responsabilidad y los equipos pueden
desarrollarlos independientemente de otros microservicios. La única
dependencia entre ellos es la comunicación. A medida que los microservicios
se comunican entre sí, tendrás que asegurarte de que los mensajes enviados
entre ellos sean compatibles con los anteriores.

2.6.2 Patrones de representación

Son patrones que se emplean para la representación y la documentación de la

arquitectura.

16
Se refiere a la notación del modelado y al conjunto de herramientas para documentar
una arquitectura y establecer un marco conceptual con un vocabulario que se use
durante el diseño de la arquitectura de software.

Existen muchas notaciones para modelar y documentar sistemas software, entre las
más importantes se mencionan las siguientes:

a) C4 Model.

El modelo C4 que significa contexto, contenedores, componentes y código y es

un conjunto de diagramas jerárquicos que puede utilizar para describir la
arquitectura de su software en diferentes niveles de zoom, cada uno útil para
diferentes audiencias.

b) UML.

El Lenguaje Unificado de Modelado (UML) fue creado para forjar un lenguaje de

modelado visual común y semántica y sintácticamente rico para la arquitectura,
el diseño y la implementación de sistemas de software complejos, tanto en
estructura como en comportamiento. UML tiene aplicaciones más allá del
desarrollo de software, p. ej., en el flujo de procesos en la fabricación.

2.6.3 Patrones de implementación

Se refiere al comportamiento del sistema basado en las prácticas específicas y en los

paradigmas que se van a emplear para el desarrollo del software.

Afectan a la forma interna del sistema, son decisiones micro que podrían afectar a la
arquitectura global del software, por ejemplo:

− Uso de Golang para la portabilidad entre plataformas

− Docker para puesta en producción

− Test drive development como buena práctica de programación

− Paradigmas funcionales en las API para logran concurrencia, etc

17
2.6.4 Patrones de evolución

Son patrones que se enfocan en la evolución de la arquitectura en el transcurso del

tiempo.

− Big Ball Mud, es un sistema de software que carece de una arquitectura

perceptible. Aunque no son deseables desde el punto de vista de la ingeniería
de software, estos sistemas son comunes en la práctica debido a las presiones
comerciales, la rotación de los desarrolladores y la entropía del código. Son un
tipo de diseño anti-patrón.

18
 CAPÍTULO III

PROPUESTA ARQUITECTÓNICA

3.1 Descripción de la empresa

El Servicio Local de Acueductos y Alcantarillado SeLA – Oruro; es una entidad

autárquica2 y descentralizada con autonomía de Gestión; es decir que a pesar de no
ser una institución de lucro tiene la capacidad de generar ingresos por la facturación
de sus servicios que permiten financiar los gastos de operación, mantenimiento y
administración del servicio.

La regulación del servicio que presta, está a cargo de la Autoridad de Fiscalización y

Control Social de Agua Potable y Saneamiento Básico (AAPS); entidad a la cual SeLA
– Oruro remiten periódicamente distintos informes que cercioren que el agua se
distribuye en la cantidad y calidad necesarias, además de ello la AAPS cuenta con un
auditor técnico y un auditor contable permanentes en la ciudad de Oruro, que se
encargan de fiscalizar la labor de la institución acuífera.

De igual manera, y al ser una institución pública; la Contraloría General del Estado se
constituye en otra instancia fiscalizadora del manejo de recursos que realiza SeLA –
Oruro durante todas las etapas que permiten la prestación del servicio de agua potable
a la población de la ciudad de Oruro.

Actualmente la empresa enfrenta nuevos retos, tales como la consolidación del área
de servicio, la expansión y prestación de servicios en condiciones óptimas a zonas
periurbanas, una gestión operativa moderna y la incorporación del servicio de
alcantarillado sanitario dentro de sus atribuciones. Retos que exigen una reflexión
colectiva sobre las restricciones a las que se enfrentan para lograr mejores resultados
y la construcción conjunta de una visión de futuro que inspire el desempeño colectivo

2 Autarquía es sinónimo de autosuficiencia

19
e individual para alcanzar la máxima aspiración institucional de contribuir a mejores
condiciones de vida a la población orureña.

Figura 1. Organigrama de la empresa

Fuente: http://selaoruro.gob.bo/institucion.php

Para administrar de forma automatizada sus procesos, SeLA – Oruro actualmente

cuenta con un sistema informático de escritorio que está en funcionamiento, el cual a
la fecha presenta muchos problemas debido a su arquitectura y a la tecnología con la
que fue desarrollada.

Se pretende desarrollar un nuevo sistema que reemplace totalmente al sistema actual,

de tal forma que se migre toda la funcionalidad al nuevo sistema, se mantenga la
consistencia y la integridad de los datos, se agreguen nuevas funcionalidades, y se
reduzcan los costos de mantenimiento. Para ello, se va estudiar la arquitectura del
sistema actual para encontrar y comprender mejor los problemas, también se van a
recolectar y analizar nuevos requerimientos.

20
 3.2 Análisis de la arquitectura del sistema actual

Se utiliza UML 2 como notación de modelado para diseñar la arquitectura actual del
sistema.
cmp ArquitecturaActual

«device»
«executable» lecturas
SeLASIS (Excel)

Terminal Movil
Portatil
PDA

Funcionario
SeLA
Microsoft Visual
rutas
FoxPro 7

Recurso compartido

«database» Lectores
DBF

Figura 2. Arquitectura actual del sistema

Fuente: Elaboración propia

Como se puede observar en la Figura 2. Arquitectura actual dela arquitectura actual

del sistema SeLASIS es monolítica.

Este sistema está desarrollado en Visual Fox Pro 7, y como base de datos utiliza su
propio sistema de archivos DBF3 (database file) en una carpeta compartida para que

3 dBASE: fue el primer sistema de gestión de base de datos usado ampliamente para
microcomputadoras

21
el sistema ejecutable pueda leerlo desde cualquier computadora en la red. Para las
lecturas de consumo de agua, se descargan las rutas y los clientes en unos terminales
móviles portátiles PDA para que los lectores se los lleven y registren el consumo de
agua en estos dispositivos; una vez registrado vuelven a la empresa y el personal de
sistemas descarga los datos al sistema de SeLA.

El sistema actual cubre varias unidades de la empresa, aunque no todas. Entre las
unidades que cubre el sistema se tiene: Gestión de trámites, instalaciones nuevas,
regularizaciones, mantenimiento, catastro, gestión de clientes, lecturas, cajas,
facturación, créditos, hidrómetros, ODECO y atención al cliente.

3.2.1 Identificación de problemas

En base al análisis que se hizo de la arquitectura del sistema actual, se han encontrado
varios problemas que impiden que el sistema siga en funcionamiento de manera
adecuada y escale para implementar nuevas funcionalidades.

Entre los problemas identificados podemos mencionar:

− Al ser una aplicación de escritorio, se debe instalar y configurar en cada

computadora de los funcionarios que van a utilizar el sistema.

− Se realiza el mantenimiento en cada máquina donde el sistema este instalado

− A menudo se lanzan nuevas versiones del sistema y se los instala en las

maquinas, esto ocasiona que los funcionarios muchas veces trabajen con una
versión obsoleta del sistema.

− Al ser Microsoft Visual Fox Pro un lenguaje de programación propietario, la

empresa debe pagar licencias.

− Al ser Visual Fox Pro un lenguaje de programación antiguo, resulta difícil

reclutar programadores que realicen el mantenimiento del sistema.

− La base de datos se encuentra en una carpeta compartida, lo que le vuelve

insegura y vulnerable a ataques externos e internos.

22
 − La alta demanda de transacciones a la base de datos ocasiona que los índices
se rompan, dejando a la base de datos y al sistema inaccesible por un periodo
de tiempo.

− Como los índices de la base de datos se rompen, resulta imposible escalarlo a

las nuevas funcionalidades

− Se ha identificado un diseño no adecuado en el modelado de la base de datos,

no implementa las formas normales básicas.

− Al ser un sistema monolítico y de escritorio, resulta difícil exponer alguna

información a través de internet

− Los clientes no pueden consultar sus deudas a través de internet.

− No se pueden realizar cobros de servicios por entidades externas como bancos

o cooperativas, ya que la arquitectura actual y la tecnología no lo permiten.

− Debido a su arquitectura monolítica, no se puede realizar cobros de servicio a

través de internet.

Además, el sistema actual no cubre los procesos de: recursos humanos, control de
asistencia, contabilidad, administración de almacenes, inicio de trámites, contratos,
solicitudes de trámites y mensajería, consulta de deuda de los clientes, etc.

Por esta razón, la empresa ha decidido migrar toda la información a un nuevo sistema
informático que reemplace totalmente al sistema actual y que reduzca los costos de
mantenimiento.

3.3 Análisis de requerimientos y definición del contexto del sistema

En base al análisis de la arquitectura actual y a las entrevistas con los funcionarios de

las diferentes unidades de la empresa, se ha recolectado los siguientes
requerimientos:

− Requerimiento 1: Desarrollar un nuevo sistema informático que permita

reemplazar de manera total al sistema actual

23
 − Requerimiento 2: Aplicar tecnología libre y de código abierto para reducir los
costos de mantenimiento del nuevo sistema.

− Requerimiento 3: Migrar toda la información a un nuevo gestor de base de datos

robusto y seguro.

− Requerimiento 4: Implementar las funcionalidades faltantes en el nuevo sistema

informático, como ser: recursos humanos, control de asistencia, contabilidad,
administración de almacenes, inicio de trámites, solicitudes de trámites, y
mensajería.

− Requerimiento 5: Escalar el sistema para que se pueda realizar cobros de

servicio de agua por medio de entidades bancarias externas a la empresa.

− Requerimiento 6: Escalar el sistema para que los clientes puedan revisar sus
deudas a través de la página web de la empresa.

− Requerimiento 7: Reemplazar los dispositivos PDA por nuevos dispositivos

móviles con sistema operativo Android.

− Requerimiento 8: Diseñar y configurar la nueva infraestructura de red para la

puesta en producción de nuevo sistema informático.

La lista de requerimientos limita el contexto del nuevo sistema que se va a desarrollar.

3.4 Diseño de la nueva arquitectura propuesta

Para analizar y diseñar la estructura organizativa del nuevo sistema informático, se ha

dividido la arquitectura en diferentes niveles de abstracción según el modelo C4 de
Simon Brown.

24
a) Nivel 1: Contexto del sistema

Clientes Lectores
Bancos

Sistema Dispositivo
Web Móvil

Funcionarios
SeLA

Sistema
Usuario, Roles y
Permisos
Admistrador

Base
De Datos

Figura 3. Nivel 1 – Contexto del sistema

Fuente: Elaboración propia

La propuesta consiste en desarrollar un nuevo sistema informático basado en

tecnología web. Las personas o instituciones que van a utilizar este sistema son
los funcionarios de SeLA, los clientes y las entidades bancarias. El
administrador de sistemas, va a tener acceso a un módulo especializado para
la gestión de usuarios, roles y permisos.

Al igual que el sistema actual, los lectores de SeLA van a tener acceso a un
dispositivo móvil, esta vez con sistema Android, para descargar sus rutas y
registrar el consumo de agua de todos los clientes. El sistema descargará la
información de los dispositivos móviles para actualizar la información.

25
 b) Nivel 2: Contenedores

Clientes
Internet

Intranet Sistema Web Web Page

(FrontEnd)
(BackEnd) (FrontEnd)
Client SPA
Web API Web app
Client SPA
Web app API Bancos
Gateway Lógica del
negocio.

Funcionarios Acceso a API Client PWA

SeLA datos.
Gateway mobile app

Repositorio
De documentos

ORM

Lectores

Sistema
Usuario, Roles y
Relational Permisos
DataBase
Web app MVC
Admistrador

Figura 4. Nivel 2 – Contenedores del sistema

Fuente: Elaboración propia

En este nivel de diseño se puede observar que el sistema va estar separado por
capas. Una capa para BackEnd y otra capa para FrondEnd, ambas capas están
relacionadas con API4 Geteway para el intercambio de información.

4 API: Interfaz de Programación de Aplicaciones

26
 En la capa del BackEnd se encuentra toda la lógica de la aplicación y el acceso
a los datos, además que el acceso a los datos se realiza a través de ORM5 para
evitar la dependencia del sistema con un gestor de base de datos en específico.

Para la capa del FrontEnd se propone desarrollar una SPA6, diseñando

interfaces amigables que logren una buena experiencia de usuario.

Para almacenar toda la información se visto por conveniente utilizar un gestor

de base de datos relacional y robusta, debido a que se espera conservar la
integridad de los datos de la empresa.

El almacenamiento de la toda documentación digitalizada se lo hará en un

repositorio o carpeta privada, al cual solo tendrá acceso el sistema BackEnd.

Por seguridad funcionarios y el administrador de sistemas de SeLA tendrán

acceso al sistema solo a través la red local de la empresa.

Se va a desarrollar una aplicación web SPA exclusivamente para el cobro de

servicio de agua por medio de entidades bancarias externas. Estas entidades
podrán utilizar el sistema a través de internet.

Los clientes podrán consultar sus deudas a través de la página web de la

empresa, para ello el sistema proveerá una serie de API públicas que serán
consultados por la página web.

La interacción con los dispositivos móviles se realizará a través de una API

provista por el sistema web.

Para el módulo del administrador y gestión de usuarios, roles y permisos; por

seguridad se ha visto por conveniente desarrollarlo bajo el patrón de

5 ORM: Object Relation Model

6 SPA: Single Page Applicatton

27
 arquitectura Modelo Vista controlado (MVC). Este módulo que se va a
comunicar directamente con la base de datos.

c) Nivel 3: Componentes

INTRANET INTERNET

Web API Web Page

(BackEnd)
Https
Módulos - Servicios (JWT)

(FrontEnd)
Client SPA Inicio de trámites
(FrontEnd)
Web app
Gestión de trámites Client SPA
[SeLA]
Web app
Catastro y clientes [Bancos]
Mantenimiento
API https
API Lecturas (JWT)
Gateway
Gateway
Cajas y Facturación
Http REST API
(JWT) REST API Recursos humanos

Control de asistencia Http

(JWT)
Créditos
JavaScript/Vuejs
Almacenes
Client PWA
Trámites y mensajería mobile app

ODECO - Atencion al cliente

Contabilidad

Repositorio Hidrómetros
De documentos

TCP
Sistema
Usuarios, Roles y Permisos
Web app MVC

TCP

OAuth 2.0

Laravel- Permission

Figura 5. Nivel 3 – Componentes del sistema

Fuente: Elaboración propia

28
 Este diagrama muestra la arquitectura a un nivel más detallado, se identifican
los componentes y la tecnología que se va a emplear para la implementación
del sistema propuesto.

Para la capa BackEnd se propone desarrollar proyectos del tipo Web API, se va
a dividir en diferentes proyectos de acuerdo a los módulos o servicios que brinda
la empresa. Cada módulo va a ser independiente entre si logrando alta cohesión
y bajo acoplamiento.

Se propone utilizar Laravel como Framework de desarrollo y PHP como

lenguaje de programación para desarrollar los proyectos en el BackEnd. La
puesta en producción se propone Apache como servidor de aplicaciones, y una
maquina con sistema operativo Linux. Estas herramientas son libres y de código
abierto, así que se reducirán los costos de mantenimiento.

Para la capa del FrontEnd se propone desarrollar una SPA con un Framework
JavaScript como VueJS, para coda módulo se sugiere crear un proyectó
independiente que serán desplegados en contenedores Docker. La
comunicación con los servicios brindados por el backend se lo realizará a través
del protocolo RESTfull, cuya API estarán protegidas por un sistema de
autenticación basado en tokens con la tecnología JWT7.

La página web y el módulo para el cobro de servicios por entidades bancarias,

se lo desplegarán en un VPS8 utilizando contenedores Docker

Para la aplicación móvil se propone una aplicación web progresiva PWA,

compatible con sistemas Android, desarrollado con los Framework NativeScript
y VueJS.

7 JWT: Json Web Token

8 VPS: virtual private server

29
 Para la gestión de usuarios, roles y permisos; se propone el implementar del
estándar OAuth 2.0 y la librería Laravel – Permission. Este módulo estará
desplegado en apache y estará implementado con le Framework Laravel bajo
el patrón de arquitectura Modelo Vista Controlador MVC.

Se ha visto por conveniente implementar la base de datos en PostgreSQL, ya

que es un gestor de base de datos robusto y de código abierto.

3.5 Estrategia para el despliegue

El objetivo de este diagrama es mostrar la infraestructura de la red y la tecnología

propuesta para la puesta en producción del software. Para esto se hace uso del
diagrama de despliegue de UML.
deployment Deployment Model

INTRANET

Application: Server VPS: Server

DataBase: Server
«BackEnd» WebPage
TCP Web API VPN
PostgreSQL

«FrontEnd» Web app

Web app Bancos

TCP 1 1
https
https
«device»
Router
1 *
1 1 *
* 1
Clientes: PC
*
Lectores: Mobile Bancos: PC
Administrador: PC
Funcionario
SeLA: PC

Figura 6. Estrategia para el despliegue

Fuente: Elaboración propia

30
Se tiene un servidor de base de datos donde se encuentra el gestor de base de datos
PostgreSQL, y un servidor de aplicaciones donde se encuentran desplegados los
sistemas BackEnd, FrontEnd, y el módulo para el administrador. La comunicación
entre ambos servidores se realiza bajo el protocolo TCP/IP.

Los funcionarios, el administrador y los lectores de SeLA interactúan con el sistema a

través de la red local interna de la empresa.

La página web y el módulo para las entidades bancarias se encuentran desplegados

en un servidor privado virtual VPS, y se comunica con el servidor de aplicaciones a
través de una red privada virtual VPN. Los clientes y los bancos interactúan con estos
sistemas por medio de internet con un protocolo seguro de transferencia HTTPS9.

3.6 Estrategia para la migración de datos

La migración de la base de datos actual a la nueva base de datos es un proceso

complicado, ya que se debe mantener la consistencia y la integridad de los datos en
dos esquemas, modelos y tecnología totalmente diferentes. Por esta razón se ha
diseñado una estrategia para llevar a cabo este proceso con el menor esfuerzo posible.

PostgresSQL
PostgresSQL
Schema Tramites
DBF Schema SeLAsis
Tabla A
Importar
Tabla A Clon Tabla A Tabla B
datos
Importar
Tabla B Clon Tabla B Schema Catastro
datos
Consultar SQL
... - Select Tabla A
- Insert
Importar Tabla B
Tabla Z Clon Tabla Z
datos
Otro Schema

Tabla X

Figura 7. Estrategia para la migración de datos

Fuente: Elaboración propia

9 HTTPS: Hypertext Transfer Protocol Secure

31
Se va a crear un esquena llamado “SeLAsis” en la nueva base de datos de
PostgreSQL, en este esquema se va a crear las mismas tablas que se tienen en los
DBF del sistema actual y se van a importar los datos a estas nuevas tablas. Se van a
realizar consultas SQL (select, insert y update) en el esquema creado para recorrer los
datos de las tablas importadas e insertarlos en las tablas correspondientes de la nueva
base de datos.

3.7 Aplicación de los patrones de arquitectura

Para el diseño de la arquitectura del nuevo sistema informático, se han aplicado

algunos patrones estructurales de arquitectura de software, como ser:

− Patrón MVC, en el desarrollo del módulo para la gestión de usuarios, roles y

permisos.

− Patrón de microservicios, para el desarrollo de los servicios del BackEnd, la

interacción con la aplicación móvil y la interacción con el módulo para el cobro
de servicio por las entidades bancarias.

3.8 Aplicación de los principios de diseño

Se ha aplicado los siguientes principios de arquitectura de software:

− (ETC): Easy To Change

Como el sistema está separado en diferentes capas, como son el BackEnd, el

FrontEnd y mobile, resulta relativamente fácil de realizar cambios de tecnología
o cambios de frameworks de desarrollo.

El sistema utiliza ORM para trabajar con la base de datos. Por lo tanto, resulta
fácil cambiar de gestor de base de datos si fuese necesario.

Los módulos del sistema son independientes, por lo que están poco acoplados,
los cambios en un módulo no afectan en gran medida a los otros módulos.

32
− (DRY): Dont Repeat Yourselft

Como se utiliza el protocolo RESTful para el intercambio de información vía http

y https se tiene bien definido las acciones que se realizan en cada petición (GET,
POST, PUT, DELETE), de esta forma evitamos repetir código
innecesariamente.

El inicio de sesión se lo realiza una sola ves a través del módulo administrador,
de esta forma evitamos repetir código de inicio de sesión en cada módulo del
sistema

− Orthogonality

Los sistemas BackEnd, FrontEnd, y la aplicación móvil, son ortogonales entre

sí, ya que no dependen del código, sino más bien de las interfaces requeridas
y provistas. De hecho, las API REST BackEnd se reutilizan tanto en la página
web para los clientes, como en la aplicación móvil. El módulo para las entidades
bancarias y la aplicación web para los funcionarios de SeLA, también comparten
funcionalidad con los módulos de cajas y facturación.

La base de datos es ortogonal al sistema BackEnd ya que están en diferentes

servidores.

− Reversibility

El cambio hipotético de la tecnología o gestor de base de datos, no afectara

catastróficamente al desarrollo del sistema, ya que el intercambio de
información se realiza por medio de una ORM. El sistema no trabaja
directamente con tablas de una base de datos en específico, sino con objetos.

Como los sistemas Backend y FrontEnd están desacoplados, se puede cambiar

de tecnología en una capa sin afectar la otra. Por ejemplo, si el FrontEnd se
está desarrollado en VueJS se puede cambiar a Angular o React sin afectar en
lo absoluto al sistema BackEnd.

33
3.9 Evaluación de la arquitectura propuesta

La arquitectura propuesta es flexible, escalable y cumple con los principios de diseño

de arquitecturas de software. Además, cumple con todos los requerimientos
funcionales establecidos, y soluciona, de alguna forma, los problemas del sistema
actual.

34
 CONCLUSIONES

El objetivo planteado al inicio del proyecto se ha complido, ya que la arquitectura

propuesta es flexible, escalable, robusta y permitirá reemplazar por completo al
sistema actual de la empresa SeLA – Oruro. Además, está enfocado para migrar toda
la funcionalidad del sistema antiguo al nuevo sistema, permite agregar nuevas
funcionalidades y reduce los costos del mantenimiento ya que para su implementación
se emplea tecnología libre y de código abierto.

Se ha diseñado una estrategia factible para migrar la información actual de las tablas
en DBF a la nueva base de datos.

También se puede concluir que:

− La arquitectura propuesta cumple con todos los requerimientos funcionales que

la empresa ha establecido.

− Con el estudio y el modelado de la arquitectura del sistema actual, se han

encontrado problemas que impiden que el sistema actual escale para
implementar nuevos requerimientos funcionales.

− Con patrones de representación y las notaciones de modelado como UML y el

modelo C4, se han diseñado y documentados los diferentes diagramas de la
arquitectura propuesta.

− La nueva arquitectura propuesta aplica los principales principios de diseño de

arquitectura de software

− La aplicación de patrones de arquitectura como el patrón MVC y de

microservicios, ayudaron a solucionar problemas comunes que se presentaron
en el análisis y el diseño de la nueva arquitectura.

35
 RECOMENDACIONES

Ya que la arquitectura del software se adecua al contexto del sistema analizado en un

tiempo determinado, se recomienda actualizar y ajustar constantemente esta
propuesta para considerar aspectos y características que en su momento se
consideraron irrelevantes.

36
 REFERENCIAS BIBLIOGRÁFICAS

Arsys. (2020). ¿Qué es la arquitectura del software? Obtenido de ¿Qué es la

arquitectura del software?: https://www.arsys.es/blog/arquitectura-software/

Group, O. M. (13 de 09 de 2019). omg. Obtenido de omg:

https://www.omg.org/spec/UML/About-UML/

Kord, M. (2011). TuxNots. Obtenido de TuxNots:

https://sites.google.com/site/tuxnots/materias-de-la-facu/metodologia-de-
sistemas/introduccionalaarquitecturadelsoftwareescenarioseinteresesatributos
decalidad

Oruro, S. . (2018). SeLA. Obtenido de SeLA: http://selaoruro.gob.bo/

Rumbaugh, J., Jacobson, I., & Booch, G. (2007). El Lenguaje de Modelado Unificado
2.0. Madrid: Perarson Addison Wesley.

Rumbaugh, J., Jacobson, I., & Booch, G. (2007). El lenguaje de Modelado Unificado
Manual de Referencia. Madrid: PEARSON Addison Wesley.

Sommerville, I. (2005). Ingenieria de Software. Madrid: PEARSON Addison Wesley.

Zayas, C. Á. (s.f.). Didáctica del postgrado. La Paz: Grupo Editorial Kipus.

37