La reconstrucción II - Arquitectura de mi aplicacion

Arquitectura de software - Sistema multinivel básico

La figura anterior es una de las actuales propuestas de arquitectura del software, por capas o niveles. Nada nuevo si consideramos que el desarrollar sistemas es una actividad que pretende resolver un problema y al mismo tiempo es un problema… nada resulta mejor que dividir.

Mi aplicación, aunque es cliente servidor con programas monolíticos, tiene esta característica, una arquitectura “interna” por capas.

Visual Basic 6 sin ser un lenguaje orientado a objetos ya permitía hacer esta división; módulos de clase que combinados con el componente ADO dan la persistencia de los datos, módulos .BAS con funciones de uso general donde se definen las reglas del negocio y la presentación o interfaz grafica donde se procesan los eventos realizados por los usuarios.

La reconstrucción de mi aplicación debe darse en los mismos términos, sobre la base de una arquitectura por capas. Desde luego que no en un cliente monolítico incapaz de integrarse con otras aplicaciones… !!!!!… Integración de aplicaciones, sin duda un gran tema que abordare posteriormente.

Ejemplo de persistencia de datos en mi aplicación VB6

-para ver mejor click sobre cualquier imagen-

Definicion de los campos de la clase ClsImpuestoArt, basicamente son campos de una tabla de la base de datos.

En la misma clase se define el procedimiento CargaTablaImpuesto que llenara la clase.

En una forma o en un módulo, se intancia la clase

En la misma forma donde se define, se llena la clase Articulo80 ejecutando su metodo CargaTablaImpuesto. El llenado de la clase se hace generalmente al cargar la forma donde se usaran los datos.

Ya con los datos en memoria se utilizan de la siguiente forma:

Articulo80 y Articulo80A son tablas en la memoria del cliente, que se pueden recorrer rapidamente como se observa en la ultima figura. Por estos rumbos, el calculo del impuesto se aplica sobre los ingresos mensuales de un trabajador y dependiendo de su valor hay que buscar en estas tablas ciertos parametros para calcularlo.

Imaginense calcular el impuesto de 5000 trabajadores en un cliente que tenga que ir a la tabla de la base de datos.... Mejor tenerla en la memoria...

La reconstrucción I - Mi aplicación

Hace 12 años desarrolle en Visual Basic 6 algunos módulos de una aplicación utilizada para procesar y pagar la nomina en la Administración Pública, si tomo en cuenta la frase que dice “El software se deteriora en función de los cambios que sufre”, llego a la conclusión de que esta aplicación ya está demasiado estropeada. Aun sin la frase, a 12 años de cambios continuos, veo que el VB6 ya dio todo lo que tenía que dar.

Es software a la medida, desarrollado por personas que sabían bastante sobre las reglas del negocio y supieron plasmar desde el modelo de base de datos las características necesarias para dar solución a una necesidad especifica. Desde la última vez que sufrió un gran cambio, en 2007, con motivo de su implementación en otra dependencia, sabía que era necesario reescribir la aplicación en una plataforma más moderna para darle mayor flexibilidad y adaptabilidad, sin embargo no me fue posible.

Hoy, por enésima vez intento reescribir la aplicación, ahora en Visual Studio, es una tarea muy grande para una sola persona, pero si no empiezo nunca terminare. Me propongo actualizar algunos módulos, pero lo más importante será definir una arquitectura de desarrollo. Ya en VB6 tuve éxito desarrollando muchos componentes reutilizables -los famosos User Controls- y módulos .bas con funciones de uso general… Además, definí clases de “persistencia” de los datos, esto último ayudado por los Class Modules de VB6 y el componente ADO… Ya no viene al caso pero bien pude haber escrito algo sobre el uso y abuso del ADO Activex Data Object… Vaya que abuse de él, para bien…

Día a día iré avanzando algo y por supuesto lo traeré a este blog. Sin duda algo interesante resultara de esto… Muchos tips de un veterano programador….

Características de mi aplicación

Mi aplicación, así la llamare de hoy en adelante, es cliente-servidor, con un cliente “pesado” con toda la lógica del negocio cargada de ese lado. Cuando la construimos, no teníamos un amplio conocimiento de la programación de la base de datos INFORMIX, solo del SQL estándar, esto fue lo que nos obligo a cargarle todo al cliente, que cabe bien decirlo nos aguanto y aguanta de todo. Mi aplicación es soportable desde los equipos con procesador Pentium y menos de 1MB de RAM… Con los nuevos procesadores y las capacidades de RAM de los equipos actuales, mi aplicación ejecuta sin problema.

Una característica de mi aplicación es traer grandes cantidades de información de la base de datos, procesarlos y regresar el resultado a la base de datos. Cuando hicimos el primer prototipo nos dimos cuenta que los continuos accesos a la base de datos, ese ir y venir de la información entre el cliente y el servidor, retardaba el proceso principal de cálculo de la nomina de 30,000 trabajadores… No eran horas de proceso, eran días… No sabíamos entonces una regla de oro… Los accesos a la base de datos son “carísimos” en medida de tiempo… Permítanme reiterarlo porque muchos todavía no lo saben… Si tu aplicación tiene que leer muchos registros, miles de registros, de una base de datos, no vayas por ellos uno a uno… No metas en un bucle la sentencia “select” …

La solución fue simple, diseñamos consultas SQL que traen al cliente la mayor cantidad de datos posible de un solo golpe… Una vez resuelto el “gran query” por el manejador de base de datos (RDBMS), la transferencia de información entre cliente y servidor sobre la misma conexión es rapidísima no importa que sean miles de registros. Ya con la información en la memoria del cliente mi aplicación procesa la nomina en minutos.

Mi aplicación, utilizada por más de 200 usuarios repartidos en toda la republica, no mantiene conexiones permanentes con la base de datos, trabaja en modo desconectado la mayor parte del tiempo. Solo cuando es necesario actualizar la información se establece la conexión al RDBMS y trae la mayor cantidad de datos que necesite el proceso en operación…

Con el tiempo me di cuenta que el haber construido mi aplicación de esa manera resulto ventajoso, llegamos a demostrar que mi aplicación podía correr sobre cualquier base de datos con mínimos cambios. Solo reconfigurar el ODBC, modificar algunas consultas SQL no tan estándar y actualizar la cadena de conexión en el componente de acceso a base de datos. Hicimos la prueba con el modulo de censo de recursos humanos corriendo sobre MySql… El mayor trabajo fue cargar los datos de una base de datos a otra…