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

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

1
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

2
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

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

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

5
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
Arquitectura de software
Informático Ingeniería inversa, del sistema actual.
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

6
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
caducidad de
arquitectura y
software
Bases De Datos
Factores asociados al acceso a los sistemas de
persistencia, modelos y estructura interna
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

7
1.3 Operacionalización de variables
Tabla 3. Operacionalización de variables
Variables Dimensiones Indicadores
V1.
Bases de
Datos
V1. D1.
Accesibilidad a bases
de datos
- Tipos de acceso
- Usuarios y permisos
- Cifrado de datos
V1. D2.
Modelos de
persistencia
- Modelos de migración
- Tipo de base de datos
- Normalización
- Estructura general
- Nomenclatura legible
- Modela relacional
- Esquemas
V2.
Mantenibilidad
V2. D1.
Aplicación de prácticas
estándar
- Cohesión entre componentes
- Acoplamiento
- 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.
Documentación del
sistema
- Legibilidad de documentación
- Documentación actualizada
- Diseño explícito
- Manuales técnicos y de usuario
- Diagramas del sistema
V2. D3.
Costos
- Costos de licencias de software
privativo
V3.
Arquitectura
V3. D1.
Principios de
arquitectura
- Análisis y diseño de la arquitectura de
software
- Aplicación de principio de arquitectura
de software
V3. D2. Patrones de
arquitectura
- Patrones estructurales
- Patrones de representación
- Patrones de implementación
- Patrones de evolución

8
V4.
Infraestructura
V4. D1.
Plataforma de
despliegue
- Mapa de despliegue
- Proceso de despliegue
- Tecnologías de despliegue
V4. D2. Relación de
componentes y
dependencia
- Cohesión y acoplamiento de alto nivel
- Consistencia de diseño y modelo
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.

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

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

11
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

12
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

13
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”.

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

15
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)

16
− 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.

17
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

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

19
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

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

21
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.
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
cmp ArquitecturaActual
Recurso compartido
«database»
DBF
«executable»
SeLASIS
Microsoft Visual
FoxPro 7
«device»
Terminal Movil
Portatil
PDA
Funcionario
SeLA
Lectores
rutas
lecturas
(Excel)

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

23
− 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

24
− 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.

25
a) Nivel 1: Contexto del sistema
Sistema
Web
Sistema
Usuario, Roles y
Permisos
Dispositivo
Móvil
Base
De Datos
Admistrador
Clientes
Bancos
Funcionarios
SeLA
Lectores
Figura 3. Nivel 1 – Contexto del sistema
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.

26
b) Nivel 2: Contenedores
Sistema Web
Sistema
Usuario, Roles y
Permisos
Web app MVC
Client PWA
mobile app
Relational
DataBase
Admistrador
Clientes
Funcionarios
SeLA
Lectores
ORM
(FrontEnd)
Client SPA
Web app API
Gateway
(BackEnd)
Web API
Lógica del
negocio.
Acceso a
datos.
Bancos
Web Page
(FrontEnd)
Client SPA
Web app
API
Gateway
Repositorio
De documentos
Intranet
Internet
Figura 4. Nivel 2 – Contenedores del sistema
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

27
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

28
arquitectura Modelo Vista controlado (MVC). Este módulo que se va a
comunicar directamente con la base de datos.
c) Nivel 3: Componentes
Web API
(BackEnd)
TCP
TCP
Http
(JWT)
API
Gateway
REST API
Módulos - Servicios
Http
(JWT)
API
Gateway
REST API
Https
(JWT)
https
(JWT)
Repositorio
De documentos
Client PWA
mobile app
Inicio de trámites
Gestión de trámites
Catastro y clientes
Mantenimiento
Lecturas
Cajas y Facturación
Almacenes
Créditos
ODECO - Atencion al cliente
Hidrómetros
Contabilidad
Recursos humanos
Control de asistencia
Trámites y mensajería
Sistema
Usuarios, Roles y Permisos
Web app MVC
(FrontEnd)
Client SPA
Web app
[SeLA]
JavaScript/Vuejs
(FrontEnd)
Client SPA
Web app
[Bancos]
INTRANET INTERNET
Web Page
OAuth 2.0
Laravel- Permission
Figura 5. Nivel 3 – Componentes del sistema

29
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

30
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.
Figura 6. Estrategia para el despliegue
deployment Deployment Model
INTRANET
Application: Server
DataBase: Server
VPS: Server
Bancos: PC
Clientes: PC
Funcionario
SeLA: PC
Administrador: PC
«device»
Router
Lectores: Mobile
PostgreSQL
WebPage
Web app
Bancos
«FrontEnd»
Web app
«BackEnd»
Web API
*
https
1
1
1
TCP
TCP
1
*
VPN
*
1 *
https
1

31
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
Schema SeLAsis
Importar
datos
Consultar SQL
- Select
- Insert
Tabla A
Tabla B
...
Tabla Z
DBF
Clon Tabla A
Clon Tabla B
Clon Tabla Z
Importar
datos
Importar
datos
PostgresSQL
Schema Tramites
Schema Catastro
Otro Schema
Tabla A
Tabla B
Tabla A
Tabla B
Tabla X
Figura 7. Estrategia para la migración de datos
9 HTTPS: Hypertext Transfer Protocol Secure

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

33
− (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.

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

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

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

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

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

Recomendados

Recomendados

Más contenido relacionado

Similar a Propuesta de una arquitectura para reemplazar el sistema informático la empresa SeLA – Oruro

Similar a Propuesta de una arquitectura para reemplazar el sistema informático la empresa SeLA – Oruro (20)

Más de Saul Mamani

Más de Saul Mamani (15)

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