DISEÑO DE UNA ARQUITECTURA PARA LA IMPLEMENTACIÓN DE INTEROPERABILIDAD CON SISTEMAS LEGACY

UNIVERSIDAD AUTÓNOMA DEL BENI
“JOSÉ BALLIVIÁN”
ALSIE CONSULTORES PEDAGÓGICOS
DISEÑO DE UNA ARQUITECTURA PARA LA
IMPLEMENTACIÓN DE INTEROPERABILIDAD CON
SISTEMAS LEGACY
Tesis de Grado para optar el Título de:
Maestría en Ingeniería de Software
Postulante:
Ing. Saúl Mamani Mamani
Tutor:
M.Eng. Cristian Gabriel Morales Rivas
Mayo, 2023
Cochabamba – Bolivia

AGRADECIMIENTOS
A Dios, a mis padres, a mis hermanos
y a mi novia por todo su apoyo. A mis
docentes de la maestría, gracias por
compartir su conocimiento.
A todo el personal de ALSIE
Consultores Pedagógicos, por
sostener el presente programa de
Maestría de manera consistente hasta
su culminación

DEDICATORIA
Dedico este trabajo a la empresa
SeLA Oruro por haberme permitido
ser parte de su equipo de desarrollo y
aportar con mi conocimiento.

RESUMEN
La evolución de sistemas heredados o Legacy Software siempre presenta desafíos,
especialmente cuando se requiere escalar y compartir información a través de internet.
En este contexto, la propuesta actual se centra en abordar este problema mediante la
aplicación de conceptos, métodos y técnicas de la ingeniería de software, arquitectura
de sistemas, e integración de sistemas de información.
Mediante la implementación de una capa de interoperabilidad, se logró que la
información del Sistema Legacy de la empresa SeLA – Oruro sea interoperable, lo que
permitió su integración con los nuevos sistemas desarrollados y otros sistemas
externos.
Se realizó un análisis exhaustivo de la arquitectura del sistema actual, identificando los
errores que obstaculizaban su escalabilidad. En base a este análisis, se diseñó una
nueva arquitectura para lograr la interoperabilidad, utilizando patrones de arquitectura
y patrones de integración.
Los nuevos sistemas desarrollados y los sistemas externos trabajan en conjunto con
la información del Sistema Legacy, sin afectar su funcionamiento, ya que este
continuará en producción durante un período considerable.
Con el fin de demostrar la eficacia de la capa de interoperabilidad, se ha desarrollado
un nuevo sistema de cobranza que reemplaza al anterior, corrige numerosos errores,
e implementa los nuevos requerimientos. Este nuevo sistema opera con la información
del Sistema Legacy y genera su propia información de manera independiente, lo que
permite reducir significativamente el acoplamiento que existe en el sistema actual.
Palabras clave: interoperabilidad, integración, arquitectura de software, patrones de
arquitectura, patrones de integración, legacy software, software heredado.

ÍNDICE GENERAL
AGRADECIMIENTOS ................................................................................................... 1
DEDICATORIA.............................................................................................................. 2
RESUMEN..................................................................................................................... 3
INTRODUCCIÓN .......................................................................................................... 1
Situación Problemática.............................................................................................. 2
Problema Científico ................................................................................................... 3
Objeto de Estudio: Desarrollo Arquitectónico de Software ....................................... 3
Objetivo General........................................................................................................ 4
Objetivos Específicos ................................................................................................ 4
Campo de Acción: Sistema de Información Legacy de la empresa SeLA – Oruro . 5
Hipótesis .................................................................................................................... 5
Aporte Teórico ........................................................................................................... 5
Métodos y Técnicas................................................................................................... 6
CAPÍTULO I (Diagnóstico) ............................................................................................ 8
1.1 Descripción de la Empresa.............................................................................. 8
1.2 Marco Contextual. Sistema Administrativo y de Cobranza de SeLA ............ 10
1.3 Definición Rectora. Caducidad de Arquitectura e Interoperabilidad con
Sistemas Legacy ..................................................................................................... 12
1.4 Matriz de Variables ........................................................................................ 13
1.5 Operacionalización de Variables ................................................................... 14
1.6 Aplicación de instrumentos............................................................................ 15
1.7 Resultados y Caracterización ........................................................................ 18
CAPÍTULO II (Fundamento Teórico)........................................................................... 20
2.1 Interoperabilidad de Sistemas ....................................................................... 20
2.2 Adaptación de Interfaz con Software Adapter ............................................... 21
2.3 Legacy Software o Sistema Heredado .......................................................... 21
2.4 Sistemas Evolutivos....................................................................................... 22
2.5 Ingeniería Inversa .......................................................................................... 22
2.6 Reingeniería de Software .............................................................................. 22
2.7 Arquitectura de Software ............................................................................... 23

2.7.1 Definición de Arquitectura de Software................................................... 24
2.8 Elementos Comunes de una Arquitectura de Software................................. 25
2.9 Principios de la Arquitectura de Software...................................................... 26
2.10 El Ciclo de Desarrollo de la Arquitectura.................................................... 28
2.11 Patrones de Arquitectura............................................................................ 30
2.12 Tendencias Arquitectónicas ....................................................................... 31
2.12.1 Patrones Estructurales......................................................................... 31
2.12.2 Patrones de Representación ............................................................... 36
2.12.3 Patrones de Implementación ............................................................... 37
2.12.4 Patrones de Evolución......................................................................... 37
2.13 Integración de Sistemas ............................................................................. 37
2.14 Estrategias Tradicionales de Integración ................................................... 38
CAPÍTULO III (Modelo Teórico).................................................................................. 44
3.1 Situación Actual del Sistema Legacy............................................................. 44
3.2 Modelo Teórico de la Nueva Arquitectura ..................................................... 46
CAPÍTULO IV (Propuesta) .......................................................................................... 49
4.1 Análisis del Sistema Legacy Actual............................................................... 49
4.1.1 Arquitectura del sistema actual ............................................................... 49
4.1.2 Análisis de la base de datos ................................................................... 50
4.1.3 Identificación de problemas .................................................................... 51
4.2 Determinación de Requerimientos y Definición del Contexto ....................... 52
4.3 Diseño de la Nueva Arquitectura Propuesta ................................................. 54
4.3.1 Representación arquitectónica C4 Model ............................................... 54
4.3.2 Diagrama de contexto del sistema.......................................................... 55
4.3.3 Diagrama de contenedores..................................................................... 56
4.3.4 Diagrama de componentes ..................................................................... 58
4.3.5 Diagrama de clases................................................................................. 62
4.4 Análisis y Diseño de la Base de Datos.......................................................... 65
4.4.1 Modelo relacional de los servicios de interoperabilidad ......................... 65
4.4.2 Modelo relacional de la base de datos del sistema de cobranza ........... 66
4.5 Arquitectura General...................................................................................... 70

4.6 Stack Tecnológico.......................................................................................... 71
4.6.1 Producción de código base..................................................................... 71
4.7 Implementación del Sistema.......................................................................... 77
4.7.1 Implementación del servicio interoperable.............................................. 77
4.7.2 Implementación del sistema de cobranza............................................... 80
4.8 Automatización del Despliegue ..................................................................... 90
4.8.1 Diagrama de despliegue ......................................................................... 90
4.8.2 Implementación del script para el despliegue automático...................... 91
4.9 Aplicación de los Patrones de Arquitectura................................................... 93
4.10 Aplicación de los Principios de Diseño....................................................... 93
4.11 Evaluación de la Arquitectura Propuesta ................................................... 95
CONCLUSIONES........................................................................................................ 96
RECOMENDACIONES ............................................................................................... 98
REFERENCIA BIBLIOGRÁFICA ................................................................................ 99
ANEXO 1................................................................................................................... 102
ANEXO 2................................................................................................................... 107

ÍNDICE DE TABLAS Y FIGURAS
Figuras:
Figura 1. Organigrama de la empresa (Oruro, 2018) ................................................... 9
Figura 2. Ciclo de vida de un software (Alfredo Rodríguez, 2001)............................. 21
Figura 3. Ciclo de Desarrollo de la Arquitectura (Maceda, 2016)............................... 30
Figura 4. Arquitectura monolítica (Blancarte, 2021) ................................................... 31
Figura 5. Arquitectura Cliente-Servidor (Blancarte, 2021).......................................... 32
Figura 6. Arquitectura MVC (Blancarte, 2021)............................................................ 33
Figura 7. Arquitectura en capas (Blancarte, 2021) ..................................................... 34
Figura 8. Arquitectura Orientada a Servicios (SOA) (Blancarte, 2021)...................... 34
Figura 9. Arquitectura de Microservicios (Blancarte, 2021)........................................ 35
Figura 10. Transferencia de archivos (Saithala, 2019)............................................... 39
Figura 11. Base de datos compartida (Saithala, 2019) .............................................. 40
Figura 12. Invocación a procedimientos remotos (Saithala, 2019) ............................ 41
Figura 13. Comunicación asíncrona (Saithala, 2019)................................................. 42
Figura 14. Descripción de alto nivel para la evolución del Sistema Legacy............... 44
Figura 15. Modelo teórico de la nueva arquitectura ................................................... 46
Figura 16. Arquitectura actual del Sistema Legacy .................................................... 49
Figura 17. Base de datos del Sistema Legacy ........................................................... 50
Figura 18. Diagrama de contexto del Sistema............................................................ 55
Figura 19. Diagrama de contenedores de la Capa de Interoperabilidad.................... 56
Figura 20. Diagrama de contenedores del nuevo sistema de cobranza .................... 58
Figura 21. Diagrama de componentes Cobranza API ................................................ 59
Figura 22. Diagrama de componentes Cobranza Backend........................................ 60
Figura 23. Diagrama de componentes Cobranza Frontend ....................................... 61
Figura 24. Clases Servicio Cobranza API................................................................... 62
Figura 25. Clases Modelo Cobranza Backend ........................................................... 63
Figura 26. Clases Controlador Cobranza Backend .................................................... 64
Figura 27. Modelo Relacional del servicio interoperable............................................ 65
Figura 28. Modelo Relacional del Sistema de Cobranza............................................ 67

Figura 29. Arquitectura general – Enfoque global ...................................................... 70
Figura 30. Organización del código Servicio de Cobranza API.................................. 78
Figura 31. API consulta de deudas – cliente con deudas........................................... 79
Figura 32. API consulta de deudas – cliente sin deuda.............................................. 79
Figura 33. API consulta historial de pagos ................................................................. 80
Figura 34. API Lista de conceptos de cobro............................................................... 80
Figura 35. Organización del código Sistema de Cobranza ........................................ 82
Figura 36. Organización del código Sistema de Cobranza Frontend......................... 84
Figura 37. Pantalla Inicio de Sesión............................................................................ 86
Figura 38. Pantalla cobro por consumo de agua........................................................ 86
Figura 39. Pantalla generación de factura .................................................................. 87
Figura 40. Pantalla cobro por trámites........................................................................ 87
Figura 41. Pantalla cobro de otros servicios a clientes SeLA..................................... 88
Figura 42. Pantalla lista de usuarios del sistema........................................................ 88
Figura 43. Aplicación banca móvil .............................................................................. 89
Figura 44. Pago de servicios por la aplicación del BNB............................................. 89
Figura 45. Página web de SeLA - Oruro..................................................................... 90
Figura 46. Diagrama de despliegue............................................................................ 91
Figura 47. Archivo Dockerfile ...................................................................................... 92
Figura 48. Archivo deploy.sh....................................................................................... 92
Tablas:
Tabla 1 Métodos y técnicas .......................................................................................... 6
Tabla 2 Organización de clientes en SeLA – Oruro ................................................... 10
Tabla 3 Cantidad de clientes atendidos por caja........................................................ 11
Tabla 4 Matriz de variables ......................................................................................... 13
Tabla 5 Operacionalización de variables .................................................................... 14

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, y la arquitectura misma, pueda ser mantenible en el tiempo.
Hace no mucho tiempo atrás los sistemas de escritorio eran la única forma de
desarrollar soluciones informáticas; hoy en día, estos sistemas presentan algunos
problemas relacionados con la portabilidad, escalabilidad, integración, e
interoperabilidad. No obstante, la industria ha ido evolucionando de tal manera que
ahora lo más común y factible es desarrollar aplicaciones web, sistemas basados en
microservicios, y aplicaciones móviles.
La forma de estructurar y organizar un sistema 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 ido evolucionando.
Las arquitecturas monolíticas eran comunes en los inicios del desarrollo de software,
según la necesidad estos han ido evolucionando hacia 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 y 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 que se va a trabajar en un sistema, 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 lo mismo

2
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.
Situación Problemática
La empresa del Servicio Local de Acueductos y Alcantarillados SeLA – Oruro, para
gestionar sus procesos, dispone de un sistema informático de escritorio que está
operativo y se encuentra instalado en las computadoras de todos los funcionarios que
requieren utilizarlo. Hasta la fecha, este sistema ha enfrentado numerosos problemas
debido a su arquitectura y la tecnología en la que fue desarrollado, la cual se ha vuelto
obsoleta.
El sistema fue desarrollado en Visual FoxPro bajo una arquitectura monolítica y su
propio sistema de archivos de base de datos DBF1
. Además, los programadores del
sistema actualmente trabajan en otras áreas o han abandonado la empresa. Sin
embargo, el software sigue recibiendo parches de actualización, por lo tanto, se ha
convertido en un Sistema Legacy.
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 tecnología y a su arquitectura monolítica.
Para que el sistema trabaje en red, lo que se ha hecho es compartir en una carpeta
las tablas DBF de la base de datos; se ha observado que esta configuración provoca
cuellos de botella, fallas de integridad, y problemas de seguridad. Debido a esta
configuración, algunas veces, los índices de las tablas se rompen provocando que el
sistema caiga por un tiempo indeterminado.
Los nuevos requerimientos también son un problema, ya que el sistema no puede ser
escalado para implementar nuevas funcionalidades de interoperabilidad; Por tal
motivo, no se puede compartir información con los nuevos sistemas, con dispositivos
móviles o con sistemas externos a través de internet.
1
La extensión de archivo .dbf representa el archivo de base de datos dBase

3
Debido a la tecnología obsoleta y a la arquitectura monolítica del sistema actual, la
empresa no brinda el servicio de pagos por internet y tampoco trabaja con otros bancos
para el cobro de sus facturas; Por esta razón, muchos clientes se tienen que desplazar
por largas distancias hasta las oficinas para pagar sus facturas, lo que ocasiona que
existan largas filas en cajas y molestia en los clientes de SeLA – Oruro.
Para publicar las deudas de los clientes en la página web, la empresa realiza copias
semanales de los archivos DBF y los exporta a un archivo centralizado en Excel. O
sea, utilizan el método de integración de intercambio de archivos. Por esta razón, la
información publicada en la página web no es siempre exacta, provocando
desconfianza en los clientes de la empresa.
Resulta complicado la generación de las nuevas facturas que deben estar alineadas a
los requerimientos del nuevo sistema de facturación electrónica exigidas por impuestos
nacionales. Para la creación de estas nuevas facturas se consumen los servicios web
proporcionados por impuestos, y estos trabajan con conexión directa a internet.
Reemplazar el Sistema Legacy por un nuevo sistema desarrollado con tecnología web
actual requiere una inversión significativa en términos de tiempo, recursos y esfuerzo.
Por estos motivos y en el contexto actual, no se considera una solución viable.
Problema Científico
Por lo tanto, se ha identificado el siguiente problema científico:
La arquitectura y la tecnología obsoleta del Sistema Legacy, limita el desarrollo de los
nuevos requerimientos y la integración con otros sistemas.
Objeto de Estudio: Desarrollo Arquitectónico de Software
La interoperabilidad es la capacidad que tienen dos o más sistemas o componentes
para intercambiar datos e información. De esta forma, se puede integrar varios
sistemas desarrollados con diferentes tecnologías.

4
Un sistema heredado o Sistema Legacy es un sistema informático que ha quedado
anticuado pero que sigue siendo utilizado por el usuario y no se quiere o no se puede
reemplazar o actualizar de forma sencilla.
Una arquitectura inadecuada impide que un sistema pueda escalar al ritmo de las
nuevas necesidades de la empresa y del mercado, llegando con el tiempo a quedar
obsoleto.
El investigador asume como objeto de estudio el Desarrollo Arquitectónico de
Software para lograr interoperabilidad entre Legacy Software con otros sistemas
desarrollados con tecnología actual, puesto que este conocimiento derivará en la
identificación de una estrategia para la implementación de los nuevos requerimientos
funcionales y el intercambio de información.
Objetivo General
Desarrollar e implementar una capa de interoperabilidad basada en una nueva
arquitectura, con el fin de lograr la integración efectiva y la interoperabilidad entre el
Sistema Legacy de la empresa SeLA – Oruro con los nuevos sistemas desarrollados
y con otros sistemas externos.
Objetivos Específicos
Se definen los objetivos específicos que ayudan a cumplir el objetivo general:
1. Caracterizar la arquitectura y la dependencia del Sistema Legacy “SeLAsis” en
la automatización de los procesos de cobranza, para comprender y documentar
los problemas asociados a este sistema.
2. Sistematizar los principales fundamentos teóricos y metodológicos relacionados
con las tendencias arquitectónicas de software, la interoperabilidad, y los
patrones de integración de sistemas.
3. Realizar el análisis y diseño de una nueva arquitectura utilizando las notaciones
de modelado C4 y UML, para luego implementar esta arquitectura, con el

5
propósito de garantizar la interoperabilidad de la información generada entre el
Sistema Legacy y los nuevos sistemas desarrollados.
4. Desarrollar un nuevo sistema de cobranza web que se ajuste a la nueva
arquitectura, con el propósito de resolver las limitaciones y deficiencias
identificadas en el Sistema Legacy.
Campo de Acción: Sistema de Información Legacy de la empresa 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 gestionar sus
transacciones y operaciones se apoya en el sistema de información “SeLAsis”.
Se asume como campo de acción el sistema mencionado, específicamente el módulo
de cajas y cobranzas; puesto que cuenta con las características requeridas para
desarrollar el Objeto de Estudio y además hace posible la concreción del diagnóstico.
Hipótesis
La implementación de una capa de interoperabilidad basada en el diseño de una nueva
arquitectura, permite que la información generada por el Sistema Legacy de la
empresa SeLA – Oruro sea interoperable con los nuevos sistemas desarrollados y con
sistemas externos a través de la publicación de servicios.
Aporte Teórico
El aporte teórico radica principalmente en la operacionalización del objeto de estudio.
La operacionalización implica describir y medir de manera precisa las características
y propiedades del sistema en su estado actual. Esto implica analizar la arquitectura, la
tecnología utilizada, los componentes y módulos existentes, así como las interacciones
y dependencias entre ellos.
Con base en este aporte teórico, se pueden desarrollar estrategias efectivas de
reingeniería y modernización del sistema, permitiendo su evolución y adaptación a las
demandas del entorno actual.

6
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
Documentación del sistema
Documentación de la base de datos
Entrevista Empírico
Cuestionarios
Reuniones
Ingeniería inversa y
reingeniería
Informático
Ingeniería inversa al Sistema Legacy
Reingeniería del sistema de cobranza
Notaciones para el
modelado de sistemas
software
Informático
C4 Model
Lenguaje de Modelado Unificado - UML
Análisis y Diseño de
Arquitectura de software
Informático
Implementación de patrones de
arquitectura.
Aplicación de los principios de diseño
de arquitectura de software
Mapeo de Base de Datos Informático
Ingeniería Inversa:
Reflexión Base de Datos
Diccionario de la Base de Datos
Estrategias de Integración Informático
Interoperabilidad de sistemas
Patrones de integración de sistemas
Observación Empírico Guía de Observación
Nota: Métodos y técnicas aplicadas al proyecto

7
Población y Muestra
El campo de acción de la presente investigación es el Sistema de Información Legacy
de la empresa SeLA – Oruro, o sea un software, el cual requiere de un tratamiento
meramente informático, motivo por el cual no se lo considera como Población ni
Muestra.

8
CAPÍTULO I
DIAGNÓSTICO
CARACTERIZACIÓN DEL SISTEMA LEGACY, SOFTWARE EN EL PROCESO
ADMINISTRATIVO Y DE COBRANZA DE LA EMPRESA SeLA – ORURO
1.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.
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

9
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 (SeLA-Oruro, 2018)
Con el objetivo de automatizar sus procesos, actualmente SeLA – Oruro cuenta con
un sistema informático de escritorio en funcionamiento. Sin embargo, este sistema
presenta numerosos problemas debido a su arquitectura y tecnología con la que fue
desarrollada, lo que dificulta su capacidad de escalar y adaptarse a las nuevas
necesidades de la empresa. Como resultado, se hace imperativo abordar estos
problemas para garantizar la evolución y el crecimiento del sistema en línea con las
demandas actuales de la organización.
Por lo tanto, se propone diseñar e implementar una capa de interoperabilidad a partir
del diseño de una nueva arquitectura, para lograr la interoperabilidad del Sistema
Legacy de la empresa SeLA - Oruro con los nuevos sistemas desarrollados y otros
sistemas externos, facilitando la interacción a través del intercambio de servicios. Para

10
ello, se va estudiar la arquitectura y la base de datos del sistema actual con el propósito
de comprender mejor los problemas.
1.2 Marco Contextual. Sistema Administrativo y de Cobranza de SeLA
Para administrar de forma automatizada sus procesos, la empresa SeLA – Oruro
actualmente cuenta con un sistema informático de escritorio que está en
funcionamiento. El sistema informático cubre los procesos de trámites administrativos,
mantenimiento de redes, catastro, lectura de consumo, facturación, ODECO, atención
al cliente, hidrómetros, cortes, y créditos. Además, cuenta con un módulo de cobranza.
Este sistema está desarrollado en Visual FoxPro 7 y como base de datos utiliza su
propio sistema de archivos DBF3
(Database File) en una carpeta compartida para que
el sistema pueda ser ejecutado desde cualquier computadora en la red LAN.
La empresa tuvo un crecimiento proporcional en relación al crecimiento poblacional de
la ciudad de Oruro. En consecuencia, la empresa ha crecido considerablemente estos
últimos años. Los clientes están divididos en ciclos, detallados en la siguiente tabla.
Tabla 2
Organización de clientes en SeLA – Oruro
CICLO CLIENTES FECHA DE FACTURACION
B 13027 8 de cada mes
C 11431 18 de cada mes
D 13988 10 de cada mes
F 13731 21 de cada mes
A 12096 15 de cada mes
G 19841 15 de cada mes
E 11715 23 de cada mes
TOTAL 95829
Nota: Los clientes pueden realizan los pagos desde las Fechas de Facturación
3
dBASE: Primer sistema de gestión de base de datos usado ampliamente para microcomputadoras.

11
La empresa cuenta con 95829 clientes distribuidos en 7 ciclos, cada uno con distintas
fechas de facturación. Esta organización permite asignar grupos de clientes a los
lectores de medidores y, sobre todo, reducir las filas en las cajas durante el proceso
de cobro de servicios. Al disponer de diferentes fechas de facturación, también se
establecen diferentes plazos para que los clientes realicen sus pagos. De esta manera,
se evita que todos los clientes acudan a realizar el pago de sus servicios al mismo
tiempo, lo que resultaría en enormes filas y muchos reclamos.
A pesar de esta estrategia de dividir en ciclos, aún se presentan problemas de grandes
filas en las cajas al momento de cobrar los servicios. Esto se debe a que la única forma
de pago aceptada para los clientes es mediante las cajas físicas ubicadas dentro de la
empresa.
Durante las fechas de facturación y cobro de servicios por ciclos, los cajeros llevan a
cabo una media de 237 cobros diarios. Estos períodos concentran una mayor actividad
en las cajas, tal como se detalla en la siguiente tabla.
Tabla 3
Cantidad de clientes atendidos por caja
CAJA FECHA
CANTIDAD DE CLIENTES
ATENDIDOS
Caja 1 08/02/2020 243
Caja 2 08/02/2020 263
Caja 3 08/02/2020 146
Caja 4 08/02/2020 252
Caja 5 08/02/2020 375
Caja 6 08/02/2020 245
Caja 7 08/02/2020 181
Caja 8 08/02/2020 192
TOTAL 1897
Nota: La cantidad de clientes atendidos fueron extraídos del sistema SeLAsis en una fecha determinada

12
El análisis muestra que las cajas atienden aproximadamente a 1897 clientes
diariamente, debido a que es el único lugar autorizado para el cobro de servicios. Por
lo tanto, se tiene la presencia de 1897 clientes haciendo fila en un solo día. Estas cifras
revelan que se debe buscar nuevas alternativas para el pago de servicios.
El sistema presenta numerosos problemas debido a su arquitectura y a la tecnología
con la que fue desarrollado, especialmente en el módulo de cobranzas. Existe la
necesidad de escalar este módulo en el menor tiempo posible para lograr su
interoperabilidad con otros sistemas, permitiendo la realización de cobros en línea y a
través de otros bancos. No obstante, esta meta resulta inalcanzable en el corto plazo
debido a que se ha identificado que se trata de un software heredado o Legacy
Software con un problema sumamente crítico: su arquitectura y tecnología están
obsoletas.
Los elementos que definen el estado del Legacy Software se detallarán en los
siguientes puntos del presente capítulo.
1.3 Definición Rectora. Caducidad de Arquitectura e Interoperabilidad con
Sistemas Legacy
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.
Con la interoperabilidad, un sistema moderno puede comunicarse y trabajar con
sistemas antiguos o heredados (Legacy), para garantizar una transición sin problemas
entre los sistemas y la continuidad en el flujo de trabajo.

13
1.4 Matriz de Variables
Tabla 4
Matriz de variables
Objeto de Estudio Variables
Desarrollo
arquitectónico de
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, a la
implementación de nuevas funcionalidades sin comprometer el
rendimiento del sistema, y procesos de soporte
Interoperabilidad
Factores asociados a la capacidad de diferentes sistemas o
aplicaciones para comunicarse, intercambiar datos y trabajar
juntos sin problemas
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

14
1.5 Operacionalización de Variables
Tabla 5
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

15
V3.
Interoperabilidad
V3. D1.
Estrategias de
integración
- Transferencia de archivos
- Base de datos compartido
- Invocación a procedimiento remoto
- Mensajería
V4.
Arquitectura
V4. D1.
Principios de
arquitectura
- Análisis y diseño de la arquitectura de
software
- Aplicación de principios de arquitectura
de software
V4. D2. Patrones
de arquitectura
- Patrones estructurales
- Patrones de representación
- Patrones de implementación
- Patrones de evolución
V4. D3. Diseño
arquitectónico
- C4 Model
- Lenguaje de Modelado Unificado, UML
V5.
Infraestructura
V5. D1.
Plataforma de
despliegue
- Mapa de despliegue
- Proceso de despliegue
- Tecnologías de despliegue
V5. D2. Relación
de componentes y
dependencia
- Cohesión y acoplamiento de alto nivel
- Consistencia de diseño y modelo
V5. D3. Hardware - Vigencia del hardware
- Soporte de largo alcance
- Accesibilidad
1.6 Aplicación de instrumentos
A continuación, se lista los instrumentos que se utilizan para la caracterización.
a) Análisis documental.
Se realiza a la documentación existente respecto del Sistema Legacy. Para esto se
utiliza una guía de revisión respecto de los documentos base con los siguientes
resultados.

16
● Documentación digital, manual de usuario: NO
● Documentación física: SI
● Manuales técnicos: NO
● Descripción arquitectónica: NO
● Documento de requerimientos implementados: NO
Esto sin duda representa un reto en cuanto al análisis del Sistema Legacy, ya que
para el nuevo desarrollo se deben de aplicar técnicas de ingeniería inversa para
conocer y describir los requerimientos funcionales previamente implementados, sin
dejar de lado la consulta a los usuarios.
b) Entrevistas
Se realiza a los usuarios del Sistema Legacy SeLAsis, poniendo énfasis en los
cajeros y el personal de facturación. Las entrevistas se dieron de forma continua y
aún se aplican para obtener información de mantenimiento y en su momento de
desarrollo. La guía general para el cuestionario de relevamiento de requerimientos
es:
● Cuestionarios, realizado a los usuarios del Sistema Legacy sobre
funcionamiento del sistema y la base de datos
● Reuniones, con los usuarios del sistema y los stakeholders, como los
gerentes de unidades, jefe de sistemas, administrador de base de datos,
etc.
c) Ingeniería inversa y reingeniería
La ingeniería inversa y reingeniería se llevan a cabo en el sistema y la base de
datos del Legacy Software. Mediante entrevistas y análisis documental, se generan
varios modelos para comprender la arquitectura, el diseño y las características del
Sistema Heredado.
Estos modelos proporcionan información detallada sobre el sistema existente, a
diferencia de un enfoque tradicional de relevamiento de requerimientos.

17
d) Notaciones para el modelado de sistemas software
Para modelar sistemas orientados a objetos existen varias notaciones, tales como,
el C4 Model y el Lenguaje de Modelado Unificado (UML) 2.5, Estas notaciones
posibilitan la representación gráfica del sistema en cuestión.
Estas notaciones son empleadas para crear diagramas que capturan tanto la
estructura como el comportamiento del Sistema Legacy mediante la aplicación de
ingeniería inversa, así como de los nuevos sistemas a través de ingeniería directa.
De esta manera, se logra una representación visual clara y concisa de la
arquitectura tanto del sistema existente como del nuevo sistema.
e) Análisis y diseño de arquitecturas de software
Sin duda alguna, analizar la arquitectura del Sistema Legacy nos va a ayudar a
comprender las deficiencias que tiene este sistema las cuales impiden escalar a
nuevas funcionalidades. A través del análisis y diseño de una nueva arquitectura,
junto con la implementación de tecnologías y herramientas modernas, se espera
solucionar dichas deficiencias, permitiendo que el Sistema Legacy sea
interoperable con los nuevos sistemas desarrollados y, además, con otros sistemas
externos, sin afectar el funcionamiento actual del sistema.
Para ello se emplean las notaciones de modelado descritas con anterioridad.
f) Mapeo de Base de Datos
Definitivamente, un paso crucial para lograr la interoperabilidad entre el Sistema
Legacy, los nuevos sistemas desarrollados y otros sistemas externos a la empresa,
es el mapeo y análisis de la base de datos del Sistema Legacy. Para este propósito,
se emplean herramientas de gestión de base de datos como Dbeaver para generar
el diagrama entidad-relación que será útil para diseñar, escribir y probar las
consultas SQL necesarias.
Además, se utilizará Microsoft Visual FoxPro para el análisis de los archivos DBF.

18
g) Estrategias de integración
Con el fin de lograr la interoperabilidad con Sistemas Legacy, se utilizan diversas
estrategias de integración de sistemas, como la invocación de procedimientos
remotos. Este patrón nos permite diseñar una nueva arquitectura eficiente que
permita al sistema actual escalar a nuevas funcionalidades mediante la
implementación de tecnología moderna. De esta manera, se logra una integración
efectiva de los sistemas.
1.7 Resultados y Caracterización
La información recopilada de parte del encargado de sistemas, el equipo de desarrollo
y los usuarios del sistema informático de SeLA - Oruro se ha sintetizado de forma
concisa en:
● El sistema actual está desarrollado bajo una arquitectura monolítica
● El sistema está programado en Microsoft Visual FoxPro 7, y es un sistema de
escritorio para sistemas Windows
● Se incurren en gastos por el pago de licencias
● Los datos persisten en un sistema de archivos DBF, y las tablas no están
relacionadas
● Se rompen los índices de las tablas debido a la cantidad de registros, y a la
cantidad de solicitudes concurrentes, el cual provoca que el sistema quede
inutilizable por un lapso de tiempo
● Problemas de seguridad con la base de datos que se encuentra en una carpeta
compartida dentro la red local
● Una única forma de pago aceptada para los clientes, mediante las cajas físicas
ubicadas dentro de la empresa
● Existen largas filas en las cajas y molestia de los clientes
● No existe ningún medio para que los clientes no pueden consultar sus deudas
en tiempo real
● Dificultad para adaptar las facturas al nuevo sistema de facturación impuesta
por el Servicio de Impuestos Nacionales

19
● El sistema no cuenta con documentación referente a su arquitectura, como
manuales técnicos y tampoco manuales de usuario
● Los programadores del sistema están trabajando en otras áreas o han
abandonado la empresa.
● El sistema presenta dificultades para escalar a los nuevos requerimientos, como
la interacción a través de internet, debido a la tecnología con la que fue
desarrollado. Estas limitaciones impiden la adaptación del sistema a los
cambios y demandas actuales del mercado y los usuarios.

20
CAPÍTULO II
FUNDAMENTO TEÓRICO
Para el desarrollo de este proyecto, es necesario conocer:
2.1 Interoperabilidad de Sistemas
La interoperabilidad es la capacidad de comunicación entre distintos sistemas con
distintos datos en distintos formatos de modo que la información pueda ser compartida,
accesible desde distintos entornos y comprendida por cualquiera de ellos.
Por lo tanto, no sólo se deberá tener en cuenta el nivel técnico (es decir que los
distintos sistemas sean capaces de comunicarse y transmitir la información) sino
también el nivel organizativo (es decir que se establezcan los procedimientos mediante
los cuales será posible esta comunicación para el intercambio de información).
La interoperabilidad es una pieza de gran valor para las empresas privadas, puesto
que trata de dar respuesta a necesidades más que conocidas, como: información
duplicada entre distintas áreas, falta de cohesión entre las diferentes partes, existencia
de diversos sistemas de información que actúan de forma separada. Cuando todo esto
sucede, el control y eficiencia no reinan en la organización. (Mahendran, 2018)
La interoperabilidad es muy importante para las compañías privadas, para las
Administraciones Públicas es un requisito indispensable, para que la cooperación,
desarrollo, implementación, integración y prestación de servicios se realice de la mejor
forma posible.
También facilita en gran medida el cumplimiento de políticas públicas, y sobre todo
para que la colaboración entre las distintas aplicaciones que habiliten el desarrollo de
nuevos servicios. De tal forma que posibilita el desarrollo de la administración
electrónica y de la sociedad de la información.

21
2.2 Adaptación de Interfaz con Software Adapter
Básicamente la función de un adaptador de software o “adapter”, es permitir adaptar
una interfaz a otra a fin de que el objeto que es adaptado, pueda colaborar con otro
que requiere una interfaz diferente. Este elemento Erich Gamma lo presenta como
“patter” estructural. (León, 2006)
2.3 Legacy Software o Sistema Heredado
Un Legacy Software o Sistema Heredado es un sistema, tecnología o aplicación de
software antiguo o desactualizado que sigue en uso dentro de una organización porque
sigue desempeñando las funciones para las que fue diseñado. Por lo general, los
sistemas legacy ya no cuentan con soporte y mantenimiento y están limitados a nivel
de crecimiento. Sin embargo, no pueden reemplazarse fácilmente. (Stackscale, 2023)
Figura 2. Ciclo de vida de un software (Alfredo Rodríguez, 2001)
Una vez que el sistema llega a su fin de vida útil, se convierte en un Sistema Legacy.
Además, los fabricantes y proveedores de la solución ya no dan mantenimiento ni

22
servicio. Por tanto, el sistema queda a total responsabilidad de la empresa. Con un
buen equipo informático, se puede conservar el sistema durante un tiempo, pero una
empresa no puede ni debe quedarse con un Sistema Legacy por siempre.
En una primera aproximación, la solución a este problema se puede presentar a través
de dos caminos: un nuevo desarrollo que incorpore nuevas tecnologías y
funcionalidades o por medio de la aplicación de reingeniería al Legacy Software.
Actualmente, el presupuesto de muchas empresas no permite desarrollos de gran
envergadura en costo y tiempo. Los Legacy Software constituyen una fuente valiosa
de conocimiento del sistema a partir de los cuales, y una vez analizados, se puede
decidir el camino a tomar para actualizar el sistema: reingeniería, abandono o una
solución híbrida.
2.4 Sistemas Evolutivos
Uno de los objetivos de la ingeniería de software actual es avanzar hacia el paradigma
de sistemas evolutivos o con capacidad de evolución (Evolutionary Systems). En este
modelo la distinción entre desarrollo y mantenimiento adaptativo es reemplazada por
la noción de evolución continua del propio sistema.
2.5 Ingeniería Inversa
Ingeniería inversa es el proceso por el cual se recupera información de alto nivel a
partir de bajos niveles de abstracción. Por ejemplo, recuperar información de diseño a
partir del código fuente u obtener un código fuente de alto nivel a partir de un programa
fuente en lenguaje ensamblador. (Ruiz, 2021)
2.6 Reingeniería de Software
La definición dada por el Reengineering Center del Software Engineering Institute de
la Universidad Carnegie Mellon es: Reingeniería es la transformación sistemática de
un sistema existente a una nueva forma para realizar mejoras de la calidad en
operación, capacidad del sistema, funcionalidad, rendimiento o capacidad de evolución
a bajo coste, con un plan de desarrollo corto y con bajo riesgo para el cliente.

23
En esta definición se enfatiza que el hecho de que la reingeniería es la mejora de
sistemas existentes de modo que la inversión resulte muy rentable y que, de todas
formas, dicha mejora podría ser obtenida a través de un nuevo desarrollo. Si la
reingeniería no tiene un coste bajo, no está acabada en poco tiempo, no tiene poco
riesgo o no ofrece un valor añadido para el cliente, hay que considerar la posibilidad
de un nuevo desarrollo.
Los criterios para su aplicación se basan tanto en técnicas heurísticas como la edad
del código o el coste del personal de mantenimiento, como en modelos de coste más
sofisticados. Si hubiese que hacer reingeniería a varios legacy systems, habría que
recopilar sus similitudes dentro de una misma arquitectura y tratarlos como si fueran
una familia de sistemas y no aplicar soluciones aisladas a cada uno de ellos.
2.7 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. (Valdez, 2021)
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.

24
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.
● 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.7.1 Definición de Arquitectura de Software
Una arquitectura de software es un marco conceptual y estructural que establece las
bases para el desarrollo de un sistema informático. Se trata de un conjunto de
decisiones significativas que definen la organización y estructura del sistema, así como
los principios que guían su diseño y evolución.
La arquitectura de software establece los componentes principales del sistema, sus
responsabilidades y las interacciones entre ellos. Proporciona una visión global del
sistema, permitiendo comprender cómo se organizan y relacionan sus partes, y cómo
funcionan en conjunto para cumplir con los objetivos del sistema.
Además, la arquitectura de software define los principios y patrones que deben
seguirse durante el desarrollo, como el modularidad, la reutilización de componentes,
la separación de preocupaciones y la escalabilidad. Estos principios ayudan a
garantizar la calidad del sistema, su mantenibilidad y su capacidad de adaptación a
futuros cambios y requerimientos.
Citamos la definición más adecuada de arquitectura de software.

25
"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". (Rumbaugh,
Jacobson, & Booch, 2007)
2.8 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 sí tiene
elementos y conceptos comunes. (Milian, 2021)
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 el proyecto que se está construyendo 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.
c) Capas.
Se puede modelar la arquitectura desde diferentes capas de niveles de
abstracción separados en componentes, módulos o subsistemas.
d) Relaciones entre las capas.
Se refiere a la forma en cómo estas capas se relacionan entre sí para trabajar
como un todo.

26
2.9 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: (Milian, 2021)
a) ETC (Easy To Change).
Este principio se refiere a que se debe diseñar la arquitectura del software
pensado 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
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.

27
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
cometidos.
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, aunque
realicemos cambios.
d) Reversibility
El principio de reversibilidad en ingeniería de software indica que la arquitectura
no debería depender 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
prototipos de pequeñas funcionalidades; también se puede diseñar mockups o
interfaces de usuario, para mostrar a los clientes una idea o un prototipo de lo
que se está construyendo. Esto es a lo que se refiere Tracer Bullet o Balas
trazadoras.

28
2.10 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 de
software. (Maceda, 2016)
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 y que, por lo
habitual, se conocen en inglés como drivers arquitectónicos. 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, son también relevantes para la arquitectura, estos son los
requerimientos funcionales 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écnicas 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”.

29
c) Documentación.
Una vez que ha sido creado el diseño de la arquitectura, es necesario darlo a
conocer a otros interesados en el sistema, como desarrolladores, responsables
de implantación, líderes de proyecto o el cliente mismo. La comunicación
exitosa depende por lo habitual de que el diseño sea documentado de forma
apropiada. A pesar de que durante el diseño se hace una documentación inicial
que puede incluir bocetos de las estructuras, o bien capturas de las decisiones
de diseño, la documentación formal involucra la representación sus estructuras
por medio de vistas.
Una vista representa una estructura y contiene por lo habitual un diagrama,
además de información adicional que apoya en la comprensión de este.
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 el sistema), 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.
e) Implementación.
Una vez establecida la arquitectura, se construye el sistema. Durante esta etapa
es importante evitar que ocurran desviaciones respecto del diseño definido por
el arquitecto.

30
Figura 3. Ciclo de Desarrollo de la Arquitectura (Maceda, 2016)
2.11 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. (Milian, 2021)
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.

31
Para abordar el problema que se busca resolver, se pueden aplicar uno o varios
patrones de arquitectura que proporcionen soluciones efectivas. Los patrones de
arquitectura son enfoques probados y comprobados que se utilizan para resolver
desafíos recurrentes en el diseño y desarrollo de sistemas.
2.12 Tendencias Arquitectónicas
Existen muchos patrones relacionados con la arquitectura de software, las cuales se
pueden dividir en los siguientes grupos o tendencias arquitectónicas. (Maceda, 2016)
2.12.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: (Blancarte, 2021)
a) Arquitectura monolítica
El estilo arquitectónico monolítico consiste en crear una aplicación
autosuficiente que contenga absolutamente toda la funcionalidad necesaria
para realizar la tarea para la cual fue diseñada, sin contar con dependencias
externas que complementan su funcionalidad. En este sentido, sus
componentes trabajan juntos, compartiendo los mismos recursos y memoria.
Figura 4. Arquitectura monolítica (Blancarte, 2021)

32
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.
Figura 5. Arquitectura Cliente-Servidor (Blancarte, 2021)
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)
● Controlador: maneja la entrada del usuario

33
Figura 6. Arquitectura MVC (Blancarte, 2021)
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
La arquitectura en capas es una de las más utilizadas, no solo por su
simplicidad, sino porque también es utilizada por defecto cuando no estamos
seguros que arquitectura debemos de utilizar para nuestra aplicación.
La arquitectura en capas consta en dividir la aplicación en capas, con la
intención de que cada capa tenga un rol muy definido, como podría ser, una
capa de presentación (UI), una capa de reglas de negocio (servicios) y una capa
de acceso a datos (DAO), sin embargo, este estilo arquitectónico no define
cuantas capas debe de tener la aplicación, sino más bien, se centra en la
separación de la aplicación en capas (Aplica el principio Separación de
preocupaciones (SoC)).
En la práctica, la mayoría de las veces este estilo arquitectónico es
implementado en 4 capas, presentación, negocio, persistencia y base de datos.

34
Figura 7. Arquitectura en capas (Blancarte, 2021)
e) Patrón Arquitectura Orientada a Servicios (SOA)
Lo primero que tenemos que entender al momento de implementar una
arquitectura SOA es que, todas las aplicaciones que construimos están
diseñadas para ser integradas con otras aplicaciones, por lo que deben de
exponer como servicios todas las operaciones necesarias para que otras
aplicaciones puedan interactuar con ella.
Figura 8. Arquitectura Orientada a Servicios (SOA) (Blancarte, 2021)

35
En la imagen anterior podemos ver como las aplicaciones del lado izquierdo (A,
B, C) exponen una serie de servicios que estarán disponibles por la red, los
cuales son consumidos por las aplicaciones del lado derecho (X, Y, Z), aunque
podrían ser consumidos por cualquier otra aplicación que esté dentro de la
misma red, o en su defecto, por internet.
La idea central de construir servicios va más allá de solventar la problemática
de la integración con aplicaciones heterogéneas, sino que brinda una serie de
ventajas que ayudan a la reutilización de los servicios, encapsulamiento de las
aplicaciones, seguridad, una larga lista de características.
f) 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
desarrollarse 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.
Figura 9. Arquitectura de Microservicios (Blancarte, 2021)

36
En la arquitectura de Microservicios es común ver algo llamado API Gateway,
el cual es un componente que se posiciona de cara a los microservicios para
servir como puerta de entrada a los Microservicios, controlando el acceso y la
funcionalidad que deberá ser expuesta a una red pública
2.12.2 Patrones de Representación
Son patrones que se emplean para la representación y la documentación de la
arquitectura.
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 clases 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.
C4 model permite representar un sistema de software con un conjunto de
diagramas que describen cada uno, en profundidad, un nivel diferente de
detalle, orientado a un público objetivo específico.
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.

37
2.12.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 lograr concurrencia, etc.
2.12.4 Patrones de Evolución
Son patrones que se enfocan en la evolución de la arquitectura en el transcurso del
tiempo. (Blancarte, 2021)
● 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.
2.13 Integración de Sistemas
La integración de sistemas es el proceso de anexión de todos los sistemas
informáticos, tecnologías, aplicaciones y software de una compañía para que
funcionen como un solo sistema. Se emplea tanto en sistemas internos como en
sistemas externos y conecta toda la infraestructura empresarial, posibilitando la
interoperabilidad entre las distintas herramientas. (Núria, 2021)
Los negocios emplean una gran cantidad de sistemas dispares que operan de forma
independiente, están programados con codificaciones distintas y cuentan con
lenguajes y códigos de programación divergentes. La integración de sistemas, por

38
tanto, ejerce de intérprete entre los distintos lenguajes, programaciones, software y
hardware para que los datos puedan fluir ininterrumpidamente y sin obstáculos.
A la práctica, no deja de ser un procedimiento de integración de datos que posibilita la
convergencia de información entre todos los sistemas empresariales de forma
automática. Sin la integración, las compañías operarían en una atmósfera
desarticulada y la información debería ser introducida manualmente en cada sistema,
cosa que incrementa el riesgo de fallos técnicos, retrasaría enormemente los
procedimientos y rutinas de trabajo y obstaculizar el flujo orgánico de intercambio de
información. Así, la integración de sistemas es la clave que encaja todas las piezas del
puzle para que las herramientas funcionen como una red centralizada y operan según
una arquitectura consistente.
Por otro lado, el papel de la integración de sistemas es cada vez más relevante a
medida que la transformación de las infraestructuras, protocolos, formatos y
tecnologías avanza a ritmo frenético, ya que permite que los negocios puedan
actualizar sus herramientas sin tener que prescindir o cambiar todas las demás ni
romper la cadena de conexión. Es decir, la integración de sistemas permite a las
empresas seguir operando con su infraestructura heredada a la vez que incorporan
nuevas tecnologías, software y aplicaciones.
2.14 Estrategias Tradicionales de Integración
¿Cómo podemos integrar varias aplicaciones para que trabajen juntas e intercambien
información?
Existen muchos tipos de integración de software que utilizan diferentes infraestructuras
para satisfacer las necesidades de una empresa. Algunas soluciones transfieren datos
entre subsistemas específicos, mientras que otras forman una base de datos sólida a
través de una red interconectada. (Núria, 2021)
Los diversos enfoques se pueden resumir en cuatro estrategias principales de
interacción. Dos o más aplicaciones pueden integrarse utilizando múltiples estrategias.

39
a) Transferencia de archivos
Podemos hacer que unas aplicaciones creen y almacenen información en
ficheros y otras los lean. Las aplicaciones tienen la responsabilidad de
transformar los ficheros de un formato a otro si es necesario. La frecuencia de
escritura/lectura dependerá de la naturaleza del negocio. (Segura, 2020)
Figura 10. Transferencia de archivos (Saithala, 2019)
Ventajas:
● Las aplicaciones que se integran no necesitan conocer cómo funcionan
las otras aplicaciones, sólo el formato de datos y cuándo se debe leer y
escribir.
● No es necesario el uso de herramientas adicionales.
● Mecanismo relativamente simple.
Desventajas:
● Sobrecarga de trabajo a los desarrolladores: acordar un formato de
ficheros y directorios a usar, garantizar que los nombres son únicos,
decidir el tratamiento de ficheros antiguos.

40
● Si la frecuencia de escritura/lectura es baja pueden surgir problemas de
sincronización. Ej. Un cliente cambia sus datos personales en la web y
el sistema de facturación lee el fichero con el cambio 24 horas más tarde.
● Si la frecuencia de escritura/lectura es alta, puede llegar a ser ineficiente.
b) Base de datos compartida
Integrar las aplicaciones almacenando sus datos en una base de datos
compartida. El esquema de la base de datos debe ser capaz de satisfacer las
necesidades de las distintas aplicaciones.
Figura 11. Base de datos compartida (Saithala, 2019)
Ventajas:
● Todas las aplicaciones tienen una vista consistente de los datos, la
posibilidad de inconsistencias es mínima.
● Lenguaje de consulta estándar: SQL.
Desventajas:
● Es difícil diseñar un esquema que satisfaga las necesidades de todas las
aplicaciones involucradas.

41
● La integración de componentes externos es compleja porque no suelen
funcionar con un esquema de datos que no sea el suyo.
● Alto acoplamiento con la base de datos: cualquier cambio en la base de
datos afecta a todas las aplicaciones.
● Puede ser un cuello de botella en términos de rendimiento.
c) Invocación a procedimiento remoto
Hacer que las aplicaciones proporciones una o varias interfaces que permitan a
otras aplicaciones interaccionar con ella en tiempo de ejecución. Las llamadas
suelen ser síncronas.
Figura 12. Invocación a procedimientos remotos (Saithala, 2019)
Ventajas:
● Las aplicaciones que se integran no necesitan conocer cómo funcionan
las otras aplicaciones, sólo su interfaz.
● Opción natural para los programadores.
● Las aplicaciones pueden ofrecer varias interfaces de programación para
los mismos datos.
● Opción preferente para la integración web.
Desventajas:
● Rendimiento y fiabilidad.

42
d) Mensajería
Usar mensajes para transferir paquetes de datos de forma frecuente, fiable y
asíncrona, usando formatos personalizables.
Procedimiento:
● Crear. El emisor crea un mensaje y le añade datos.
● Enviar. El emisor coloca el mensaje en el canal.
● Entregar. El sistema de mensajería transmite el mensaje desde el
ordenador del emisor al del receptor.
● Recibir. El receptor lee el mensaje del canal.
● Procesar. El receptor extrae los datos del mensaje. Comunicación
asíncrona.
Comunicación Asíncrona:
Figura 13. Comunicación asíncrona (Saithala, 2019)
Ventajas:
● Alta cohesión (mucho trabajo local).
● Bajo acoplamiento (pocas dependencias).
● Las aplicaciones pueden funcionar de forma desconectada.

43
Desventajas:
● Es posible que los mensajes lleguen en el orden incorrecto.
● No adecuado para aplicaciones que requieren un tiempo de respuesta
rápido.
● Aplicaciones difíciles de probar y depurar.

44
CAPÍTULO III
MODELO TEÓRICO
En este capítulo se expone el modelo teórico para la interoperabilidad con Legacy
Software y su adaptación para implementar nuevos requerimientos funcionales. Es
crucial destacar que el término Legacy Software se refiere a sistemas que están en
producción y que fueron desarrollados con tecnologías obsoletas, pero que aún están
en funcionamiento debido a su importancia crítica para la empresa y la valiosa
información que manejan. Sin embargo, el Legacy Software presenta problemas de
compatibilidad con las nuevas tecnologías, lo que dificulta su actualización y
mantenimiento; como se menciona en el capítulo 2 del marco teórico.
3.1 Situación Actual del Sistema Legacy
En primer lugar, se representa a un alto nivel las relaciones y las nuevas necesidades
o requerimientos solicitados actualmente al Sistema Legacy en producción. La
siguiente figura describe esta relación:
Figura 14. Descripción de alto nivel para la evolución del Sistema Legacy

45
De acuerdo con los resultados del diagnóstico y lo descrito en el marco teórico; debido
a la alta dependencia del Sistema Legacy, no es viable desarrollar un nuevo
sistema para reemplazar al actual en el corto plazo. Esto se debe a que las nuevas
necesidades son inmediatas y se espera que entren en producción lo antes posible.
Debido a la arquitectura y la tecnología obsoleta con la que fue desarrollado el sistema
actual, no es posible implementar nuevos requerimientos relacionados con el
trabajo en red o a través de internet. Esto impide la adaptación del sistema a las
necesidades actuales de la empresa y limita su capacidad de innovación y
competitividad en el mercado.
La integración de la base de datos del sistema actual con nuevos sistemas o
sistemas externos no puede realizarse de manera directa, ya que el sistema actual
almacena sus datos en archivos DBF y utiliza una carpeta compartida para trabajar en
red. Esto dificulta la interoperabilidad del sistema y la integración con otras
aplicaciones desarrolladas con tecnología actual.
Por último, aunque es viable realizar labores de mantenimiento y añadir nuevas
funcionalidades al sistema actual gracias a que se dispone del código fuente, esta
tarea se vuelve cada vez más complicada debido a varios factores. Uno de ellos es la
dificultad para encontrar programadores que dominen Visual FoxPro, el lenguaje en el
que fue programado el sistema. Además, se ha detectado la presencia de código
desordenado (código espagueti) y de difícil lectura, lo que complica aún más la tarea
de realizar cambios en el sistema.
En este escenario se puede establecer que la dependencia de Legacy Software es en
todo caso un síntoma, resultado de las decisiones de implementación durante el
desarrollo de software, decisiones que eran factibles en ese momento, según los
desarrolladores del sistema legacy actual.
En esa dirección construir un modelo teórico hacia la consolidación de la dependencia
a Legacy Software carece de una razón válida.

46
No obstante, en el marco de la presente investigación se busca escalar el sistema
actual por medio de la interoperabilidad, aprovechando la información valiosa
almacenada en el mismo para su uso en los nuevos sistemas a desarrollar y en la
posible integración con otros sistemas externos.
3.2 Modelo Teórico de la Nueva Arquitectura
El autor pone a consideración el siguiente modelo teórico que representa la nueva
arquitectura para lograr interoperabilidad entre el sistema actual y los nuevos sistemas
que serán desarrollados.
Figura 15. Modelo teórico de la nueva arquitectura

47
A continuación, se detallan los elementos conceptuales y cómo se logra
interoperabilidad del Sistema Legacy actual con los nuevos sistemas y con otros
sistemas externos.
Nuevos requerimientos: Los nuevos requerimientos van a ser desarrollados e
implementados con tecnología moderna, y se van a desplegar en una capa de
interoperabilidad.
Capa de interoperabilidad: Se propone que la capa de interoperabilidad sea el
servidor que aloje los servicios interoperables, con todas las configuraciones y
medidas de seguridad necesarias para su correcto funcionamiento. De esta manera,
se asegura que la comunicación entre los sistemas sea efectiva y segura. Además,
esta capa permitirá que el Sistema Legacy actual se integre con nuevos sistemas
desarrollados en tecnologías modernas, sin afectar el funcionamiento del Sistema
Legacy actual.
Servicios interoperables: Los servicios interoperables permiten una separación clara
de responsabilidades a un nivel superior mediante la creación de APIs de
comunicación entre ellos. Esto permite que los servicios sean independientes y
trabajen de forma aislada con tecnología completamente agnóstica respecto al resto
de los servicios. Además, los nuevos requerimientos y el mantenimiento se reducen al
contexto del servicio en lugar de estar relacionados con todo el sistema. De esta
manera, la dependencia específica en un solo sistema desaparece y se fragmentan
las responsabilidades, con menor dependencia o independencia total según el modelo
de comunicación mediante API's.
Nuevos sistemas o sistemas externos: Estos pueden utilizar los servicios
interoperables y para reducir aún más el acoplamiento, se podría utilizar un patrón de
arquitectura orientado a servicios (SOA) o el de microservicios, donde cada servicio
interoperable se diseñe y desarrolle de manera independiente y se comuniquen
mediante APIs. De esta manera, cada servicio puede ser actualizado y escalado sin
afectar a los demás, lo que aumenta la flexibilidad y adaptabilidad del sistema en
general.

48
Despliegue individual: Desde la perspectiva DevOps los despliegues serán de forma
individual, lo que garantiza un nuevo nivel de independencia respecto de áreas,
características y funcionalidades del software. Con esto claramente se ataca
directamente a la dependencia hacia un sistema específico.

49
CAPÍTULO IV
PROPUESTA
En este capítulo, se analiza la arquitectura y la base de datos del Sistema Legacy
actual, se capturan los nuevos requerimientos, se diseña y se implementa la
arquitectura de la nueva capa de interoperabilidad para lograr interacción con los
nuevos sistemas y los otros sistemas externos.
4.1 Análisis del Sistema Legacy Actual
4.1.1 Arquitectura del sistema actual
Se utiliza UML 2 como notación de modelado para diseñar la arquitectura actual del
sistema, y mediante ingeniería inversa se tiene el siguiente diagrama:
Figura 16. Arquitectura actual del Sistema Legacy

50
Como se puede observar en el diagrama, la arquitectura actual del sistema SeLAsis
es monolítica.
Este sistema está desarrollado en Visual FoxPro 7, y como base de datos utiliza su
propio sistema de archivos DBF (Database file) en una carpeta compartida para que
el sistema ejecutable pueda ser leído o ejecutado 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, por lo tanto, utilizan
intercambio de archivos como estrategia de integración de sistemas.
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.
4.1.2 Análisis de la base de datos
Figura 17. Base de datos del Sistema Legacy

51
Como base de datos el Sistema Legacy utiliza archivos DBF (Database file), y para
que la base de datos trabaje en red, se ha habilitado una carpeta compartida. Todos
los sistemas ejecutables, y las computadoras deben ser configurados para que puedan
utilizar esta base de datos centralizada, lo que conlleva varios problemas.
4.1.3 Identificación de problemas
En base al análisis que se hizo de la arquitectura del sistema y a la base de datos, 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, el sistema debe ser instalado y configurado
en cada computadora de los funcionarios.
● Se debe realizar el mantenimiento en cada máquina donde el sistema esté
instalado.
● A menudo se lanzan nuevas versiones, por lo tanto, se debe actualizar el
sistema en cada una de las máquinas. Esto no siempre sucede en todas las
máquinas lo que ocasiona que los funcionarios algunas veces trabajan con una
versión obsoleta del sistema.
● Al ser Microsoft Visual FoxPro un lenguaje de programación propietario, la
empresa debe pagar costos de licencias.
● Al ser Visual FoxPro un lenguaje de programación antiguo, a menudo, resulta
difícil reclutar programadores para 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.
● 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 escalar a
las nuevas funcionalidades

52
● Las tablas en la base de datos no están relacionadas, lo que dificulta su lectura
y su análisis.
● 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 en tiempo real a través de internet,
esto debido a la arquitectura y la tecnología obsoleta del sistema.
● 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 pueden realizar cobros de servicio a
través de internet.
● Con el Sistema Legacy, no se pueden adecuar las facturas a los nuevos
requerimientos de facturación electrónica solicitados por Impuestos Nacionales.
Como se puede observar, el sistema tiene muchos problemas. El sistema actualmente
está en producción y existe alta dependencia de la información que se genera por
todas las unidades de la empresa que utilizan este sistema. Por este motivo,
desarrollar un nuevo sistema con tecnología moderna que reemplace al sistema actual,
no es factible en el mediano tiempo.
El Sistema Legacy debe seguir funcionando, al menos por un buen tiempo. Entonces,
se debe buscar la mejor estrategia para lograr interoperabilidad entre el Sistema
Legacy y los nuevos sistemas que se van a desarrollar, incluso con sistemas externos
a través de la integración de servicios.
4.2 Determinación de Requerimientos y Definición del Contexto
En base al análisis de la arquitectura actual, la base de datos, y a las entrevistas con
los funcionarios de las diferentes unidades de la empresa, se ha recolectado los
siguientes requerimientos:

53
● Requerimiento 1: Diseñar una nueva arquitectura para permitir interoperabilidad
entre el Sistema Legacy y los nuevos sistemas o servicios que se van a
desarrollar.
● Requerimiento 2: La nueva arquitectura y los nuevos sistemas, no deben afectar
de ninguna manera el funcionamiento del Sistema Legacy actual.
● Requerimiento 3: Implementar la nueva arquitectura utilizando las mejores
prácticas de desarrollo, estándares de la industria y tecnologías modernas y
adecuadas.
● Requerimiento 4: Utilizar tecnología libre y de código abierto para reducir los
costos de mantenimiento de los nuevos sistemas y servicios.
● Requerimiento 5: Integrar de forma efectiva la información almacenada en la
base de datos actual con los nuevos sistemas o servicios desarrollados,
garantizando un flujo de datos coherente y preciso entre ellos.
● Requerimiento 6: Desarrollar un nuevo sistema de cobros de servicios de agua
que utilice la información existente en la base de datos actual, sin afectar el
funcionamiento del sistema actual.
● Requerimiento 7: Generar la nueva factura de pago de servicios, en base a las
disposiciones del nuevo sistema de facturación electrónica propuesta por
impuestos nacionales.
● Requerimiento 8: Escalar el sistema para permitir la realización de cobros de
servicios de agua a través de entidades bancarias externas a la empresa, sin
causar impacto en el funcionamiento del sistema actual.
● Requerimiento 9: Escalar el sistema para permitir que los clientes puedan
consultar sus deudas a través de la página web de la empresa.
● Requerimiento 10: Exponer servicios web API que permitan a los clientes
efectuar pagos mediante aplicaciones bancarias externas a la empresa,

54
facilitando así la interoperabilidad y la comodidad en los procesos de pago de
servicios.
● Requerimiento 11: Analizar y definir los servicios específicos que se van a
exponer, considerando las necesidades de interoperabilidad y los
requerimientos de los sistemas externos involucrados.
● Requerimiento 12: Identificar y aplicar mecanismos de seguridad adecuados
para proteger el intercambio de datos e información entre el Sistema Legacy, y
los servicios expuestos para las entidades bancarias y las aplicaciones móviles
de terceros.
● Requerimiento 13: Realizar pruebas tanto a los servicios expuestos como al
nuevo sistema desarrollado, con el objetivo de garantizar la calidad del software
y su correcto funcionamiento.
● Requerimiento 14: Diseñar y configurar una nueva infraestructura de red
necesaria para la puesta en producción de los nuevos servicios y los nuevos
sistemas que van a ser desarrollados.
4.3 Diseño de la Nueva Arquitectura Propuesta
4.3.1 Representación arquitectónica C4 Model
Para modelar la nueva arquitectura, los servicios y el sistema propuesto, se emplea la
notación de modelado C4 Model. Este enfoque divide la arquitectura en varios niveles
de abstracción, lo que proporciona una representación visual clara y comprensible de
los componentes y sus interacciones en el nuevo sistema.
Este enfoque de modelado permite una representación visual concisa y efectiva de la
arquitectura, lo que facilita la comprensión tanto para los desarrolladores como para
los interesados en el proyecto. Además, el C4 Model fomenta una comunicación clara
y colaborativa entre los miembros del equipo de desarrollo, alineando la comprensión
y las decisiones arquitectónicas en todos los niveles del sistema.

55
4.3.2 Diagrama de contexto del sistema
Este diagrama muestra una vista de alto nivel de la arquitectura propuesta.
Figura 18. Diagrama de contexto del Sistema
La propuesta consiste en establecer una capa de interoperabilidad que actúe como un
puente entre el Sistema Legacy y los nuevos sistemas desarrollados. Esta capa
interactúa directamente con la base de datos del Sistema Legacy y proporcionará
servicios a los sistemas desarrollados por SeLA, así como a otros sistemas externos
que requieran acceder a la información de la empresa. De esta manera, se garantizará
una comunicación fluida y eficiente entre los diferentes sistemas, permitiendo la
interoperabilidad y facilitando el intercambio de datos de manera segura y confiable.
En el contexto mencionado, los funcionarios de la empresa seguirán utilizando el
Sistema Legacy como parte de sus operaciones diarias. Sin embargo, se implementará
un nuevo sistema de cobranza que estará disponible para ciertos usuarios, como los
cajeros y los funcionarios de los bancos. Estos usuarios podrán utilizar el nuevo
sistema para realizar tareas específicas relacionadas con la cobranza de servicios.
Además, se brindará acceso a los clientes a través de la página web de la empresa,
donde podrán obtener información en tiempo real sobre sus deudas.

56
Además de brindar acceso a los usuarios internos de la empresa, la capa de
interoperabilidad también tiene la capacidad de exponer servicios a sistemas o
aplicaciones externas. Esto incluye aplicaciones móviles bancarias, mediante las
cuales los clientes podrán realizar sus pagos a través de internet.
4.3.3 Diagrama de contenedores
Este diagrama se centra en la capa de interoperabilidad y el sistema de cobranza.
Figura 19. Diagrama de contenedores de la Capa de Interoperabilidad

57
Este diagrama de contenedores se centra en la capa de interoperabilidad, cuyo
objetivo es facilitar la comunicación entre el Sistema Legacy y los nuevos sistemas
desarrollados. Para lograr esto, se desarrollarán proyectos individuales llamados
"servicios interoperables" que se encargarán de leer o escribir información en la base
de datos del Sistema Legacy y proporcionar servicios web para los nuevos sistemas
requeridos.
La implementación de estos servicios interoperables permitirá desacoplar las
dependencias entre los nuevos sistemas o servicios que se van a desarrollar. Cada
proyecto se enfocará en cumplir un requerimiento específico y brindará una interfaz de
programación clara y definida para interactuar con el Sistema Legacy. Esto asegura
que los nuevos sistemas puedan acceder y utilizar los datos necesarios sin tener que
depender directamente del Sistema Legacy.
El nuevo Sistema de Cobranza se integrará con las API4
proporcionadas por el servicio
de CobranzaAPI.
Además, la página web del Sistema de Cobranza se comunicará con los servicios
proporcionados por el proyecto WebPageAPI. Esta comunicación permitirá a los
clientes acceder en tiempo real a su información acerca de sus deudas y pagos
realizados.
Asimismo, los servicios interoperables permiten a las aplicaciones bancarias ofrecer
funcionalidades adicionales a sus clientes, como consultas de estado, y el pago de
consumo de agua.
El siguiente diagrama de contenedores se centra en el nuevo sistema de cobranza
web.
4
API: Interfaz de Programación de Aplicaciones

58
Figura 20. Diagrama de contenedores del nuevo sistema de cobranza
El nuevo sistema de cobranza web está separado en dos capas: la capa backend y la
capa frontend.
El proyecto backend es el que interactúa con la capa interoperable y es donde se
encuentra toda la lógica del negocio, mientras que en el frontend se diseñan las
interfaces de usuario.
4.3.4 Diagrama de componentes
El enfoque principal del modelado del diagrama de componente se centra en la capa
de interoperabilidad, específicamente en el servicio de cobranza API. También
modelamos el diagrama del nuevo sistema de cobranza.
a) Diagrama de contenedores del servicio de Cobranza API

59
Figura 21. Diagrama de componentes Cobranza API
Para implementar el servicio interoperable CobranzaAPI se propone desarrollar un
proyecto del tipo Web API, separado por responsabilidades.
En el paquete Repository se encuentran definidas las clases que se encargan de
interactuar con la base de datos local.
En el paquete Controllers se encuentra toda la lógica del negocio, y es el encargado
de interactuar con la base de datos del Sistema Legacy, a través de conexión ODBC.
Por último, en el paquete de API se definen todas las rutas necesarias para acceder a
los servicios.

60
b) Diagrama de componentes del Sistema de Cobranza Backend
Figura 22. Diagrama de componentes Cobranza Backend
El proyecto backend del nuevo sistema de cobranza está dividido en responsabilidades
y va a ser desarrollado siguiendo el patrón MVC y con el framework Laravel.
En el paquete Models se define toda la interacción con la base de datos utilizando
ORM5
. En los Controllers se define toda la lógica del negocio y es el lugar por donde
el nuevo sistema va a interactuar con el Sistema Legacy a través de la capa
5
ORM: Object Relation Model

61
interoperable. Finalmente, en Route API se definen todas las rutas necesarias acceder
a los servicios
c) Diagrama de componentes del Sistema de Cobranza Frontend
Figura 23. Diagrama de componentes Cobranza Frontend
Para la capa del frontend se propone desarrollar una SPA6 con un Framework
JavaScript como Vue.js. La comunicación con los servicios brindados por el backend
se realizará a través del protocolo REST.
6
SPA: Single Page Application

62
4.3.5 Diagrama de clases
Se modela el diagrama de clases para el Servicio de Cobranza API y para el Sistema
Cobranza Backend.
a) Diagrama de Clases Servicio Cobranza API
Figura 24. Clases Servicio Cobranza API

63
En el diagrama de clases Servicio Interoperable de Cobranza API, se presentan las
clases que encapsulan la lógica necesaria para interactuar con la base de datos del
Sistema Legacy.
b) Diagrama de Clases Modelo Cobranza Backend
Figura 25. Clases Modelo Cobranza Backend7
En el diagrama de clases Modelo del nuevo sistema de cobranza, se representan las
entidades que interactúan con la base de datos utilizando Eloquet, el ORM del
framework Laravel.
Estas entidades se corresponden directamente con las tablas de la base de datos
PostgreSQL, donde se almacenan los datos del sistema de cobranza. El ORM se
7
Los atributos de las clases están detallados en la Figura 28. Modelo Relacional del Sistema de
Cobranza

64
encarga de manejar la persistencia y recuperación de los objetos en la base de datos,
proporcionando una forma sencilla y eficiente de trabajar con las tablas en la base de
datos.
c) Diagrama de clases Controlador Cobranza Backend
Figura 26. Clases Controlador Cobranza Backend

65
En el diagrama de clases del nuevo sistema de cobranza, se representan los
controladores que contienen la lógica de negocio. Estos controladores son
responsables de recibir las solicitudes del usuario, procesar los datos, interactuar con
las entidades y servicios correspondientes, y generar las respuestas adecuadas par
cada solicitud.
Los controladores actúan como intermediarios entre las vistas (interfaz de usuario) y
el modelo de datos.
4.4 Análisis y Diseño de la Base de Datos
Se modela la base de datos del servicio interoperable y del nuevo sistema de cobranza.
4.4.1 Modelo relacional de los servicios de interoperabilidad
Esta base de datos se utiliza para seguridad y auditoría de la capa de interoperabilidad.
Se registra al usuario quien realiza una petición y se almacenan en un historial todas
las peticiones realizadas por un usuario.
Figura 27. Modelo Relacional del servicio interoperable

66
Diccionario de datos:
Table: users
Columna Tipo Nulo Comentarios
id (Primaria) int(11) No Clave primaria de la tabla users
ventanilla int(11) No
Número de ventanilla del cajero, o el
administrador
cuenta varchar(20) No Cuenta del usuario
password varchar(255) No Password del usuario
rol varchar(20) No Permisos del usuario
nombre varchar(100) No Nombre completo del usuario
entidad varchar(50) No Entidad asociada con el usuario
sucursal varchar(100) No Sucursal asociada con el usuario
alta bit(1) No Estado del usuario True - False
Table: historials
Columna Tipo Nulo Comentarios
id (Primaria) int(11) No Clave primaria de la tabla historials
fecha datetime No Fecha y hora del registro
accion varchar(255) No Descripción de la acción realizada
users_id int(11) No Clave foránea a la tabla: users
pla_nfac int(11) No Número de factura
pla_matr int(11) No Número de matrícula del cliente SeLA
pla_dive int(11) No Extensión de la matrícula del cliente
4.4.2 Modelo relacional de la base de datos del sistema de cobranza
Se presenta el modelo relacional de la base de datos del nuevo sistema de cobranza,
donde se registran todos los pagos realizados por los clientes. Es importante destacar
que se ha garantizado la compatibilidad con el Sistema Legacy, ya que cada nuevo
pago se registra primero en dicho sistema antes de ser registrado en la nueva base de
datos. Esto asegura una continuidad y coherencia en el registro de pagos entre ambos
sistemas.

67
Figura 28. Modelo Relacional del Sistema de Cobranza
Diccionario de Datos:
Table: cajeros
Columna Tipo NuloPred. Comentarios
id (Primaria) bigint(20) No Clave primaria
ventanilla int(11) No
Número único de la ventanilla asignado al
cajero
entidad varchar(100)Sí SeLA
Nombre de la entidad a la que pertenece el
cajero
sucursal varchar(100)Sí SeLA Nombre de la sucursal de banco
cantidad_facturaint(11) Sí 50
Porcentaje de facturas mínimas que puede
cobrar el cajero en consumo de agua
user_id bigint(20) No Id de la tabla users
created_at timestamp Sí NULLCampo de auditoría
updated_at timestamp Sí NULLCampo de auditoría

DISEÑO DE UNA ARQUITECTURA PARA LA IMPLEMENTACIÓN DE INTEROPERABILIDAD CON SISTEMAS LEGACY

DISEÑO DE UNA ARQUITECTURA PARA LA IMPLEMENTACIÓN DE INTEROPERABILIDAD CON SISTEMAS LEGACY

Recommended

Recommended

More Related Content

Similar to DISEÑO DE UNA ARQUITECTURA PARA LA IMPLEMENTACIÓN DE INTEROPERABILIDAD CON SISTEMAS LEGACY

Similar to DISEÑO DE UNA ARQUITECTURA PARA LA IMPLEMENTACIÓN DE INTEROPERABILIDAD CON SISTEMAS LEGACY (20)

More from Saul Mamani

More from Saul Mamani (15)

DISEÑO DE UNA ARQUITECTURA PARA LA IMPLEMENTACIÓN DE INTEROPERABILIDAD CON SISTEMAS LEGACY