ILE. Estrategia

Después del artículo donde presentaba los conceptos en los que se basa la filosofía de ILE, querría expresar la estrategia que utilizo en el desarrollo de aplicaciones en As400 con el objetivo de reducir los tiempos de desarrollo y también de mantenimiento. Intentaré explicarlo por aproximación paso a paso y lo desarrollaré en detalle en próximos artículos.

Programas antiguos

En los programas que desarrollábamos hace años, todo el código fuente estaba en un único miembro que se compilaba para generar un objeto ejecutable. Así, los programas eran muy largos y complejos y donde se incluía la gestión de varias pantallas e informes y el mantenimiento de diferentes ficheros o tablas. Eran programas monolíticos. 

Se solían incluir varias pantallas (de subfichero de registros, de mantenimiento de un registro, etc.) en el mismo programa para evitar el crear muchos programas en un proceso online puesto que el coste de "levantar", cargar en memoria y abrir los ficheros de utiliza un programa era muy alto. 

Desventajas:

• Los programas eran muy largos y se hacían muy complejos de seguir y de entender. Tenían miles de líneas.
• El código no era limpio y muchas veces se reutilizaban indicadores o variables 
• El mantenimiento del programa para añadir nuevas funcionalidades o para realizar correcciones llevaba mucho tiempo debido a que era tan complejo. Muchas veces se incluían "chapuzas" para poder "solucionar" la petición.

Programa monolítico

Esta solución no parecía la mejor para el desarrollo y mantenimiento de aplicaciones pero era lo que había... hasta que llegó ILE para facilitar las cosas.

ILE aporta una solución

La apuesta de ILE era permitir facilitar el desarrollo de aplicaciones con la posibilidad de dividir el código fuente en diferentes objetos y posteriormente unir ("linkar") en un solo ejecutable. 

Con  ILE ahora tenemos herramientas para que el programa anterior lo podamos "dividir" en código fuente más pequeños y "controlables" y unirlos todos para crear un solo objeto ejecutable... ¡y sin perder rendimiento en tiempo de ejecución! 

Así, sobre el ejemplo anterior, podríamos tener un programa (un solo ejecutable) "linkado" de los siguientes objetos:

• Un módulo (con su código fuente) que se encargue de presentar y gestionar una pantalla de lista de registros
• Un módulo (con su código fuente) que se encargue de presentar y gestionar una pantalla de un mantenimiento de un registro
• Un módulo (con su código fuente) que se encargue de generar un informe.
• Un programa de servicio que tenga un módulo con los fuentes de los componentes genéricos y reutilizables en diferentes programas.

Programa ILE

Ventajas:

• Código más simple ya que está dividido en varios módulos y cada módulo sólo gestiona una funcionalidad con lo que el código es más corto y legible.
• El mantenimiento para añadir nuevas funcionalidades o para correcciones es más simple.
• Desarrollar sólo una vez y poder usar en cualquier programa funciones o componentes de lógica de negocio al encapsularlo en un programa de servicio.

Por contra, para sacar toda la potencia a ILE, es necesario un nivel mayor de abstracción y nivel de diseño de aplicaciones antes de comenzar a "tirar" líneas de código.

Adicionalmente a lo anterior, yo he utilizado ILE para separar en capas el desarrollo de aplicaciones, de forma que unos objetos se encargan de la representación visual y otros objetos se encargan de la gestión de la base de datos  y de la lógica de negocio asociada a cada aplicación.

Un paso más allá

En mi experiencia con el desarrollo de aplicaciones en Rpg con ILE y conociendo la filosofía de otros lenguajes de desarrollo e intentado incluir ciertas filosofías y mejoras con el desarrollo con ILE. Así he incorporado:

• El desarrollo "en capas"
• Uso plantillas de programas

Desarrollo en capas

Lo he utilizado en la parte online de la aplicaciones. La idea es separar la presentación visual de la gestión de la base de datos y de la lógica de negocio. La organización sería así:

• Un programa de servicio con un módulo donde están los componentes relacionados con el acceso y mantenimiento de la base de datos, con la lógica de negocio relacionada con la aplicación que se está desarrollando y las validaciones a realizar.
  Por  ejemplo, podrían ser componentes de siguiente estilo:
• Obtener_Lista_Clientes,  Obtener_Cliente        (de acceso a BD)
• Genera_Cliente, Actualiza_Cliente, Borra_Cliente       (de mantenimiento de BD)
• Calcula_Riesgo_Cliente       (de lógica de negocio)
• Valida_Direccion_Cliente        (de validación)
  
• Un módulo que contiene el código fuente asociado a una pantalla.
  
  Por ejemplo, a un pantalla de lista de registros (subfichero). Este código SOLO gestiona la pantalla, cargarla, presentarla, recuperar los datos introducidos en pantalla y obtener los mandatos pulsados por el usuario en la pantalla.NO conoce nada de la base de datos, ni de la lógica de negocio, etc. cuando necesite algo relacionado con estos conceptos se lo "pedirá a quién lo conoce" a través del uso de componentes del programa de servicio anterior.

Al tener el acceso a la base de datos y la lógica negocio separado de la presentación visual se pueden realizar modificaciones en la base de datos o en la lógica sin tener que modificar los módulos de los procesos visuales. 
Por ejemplo, podrían existir varios módulos de pantalla que utilizan la versión inicial del componente de Calcula_Riesgo_Cliente. En esta versión inicial se utilizaban dos ficheros y se realizaban cuatro cálculos. Ahora se cambia el código del componente Calcula_Riesgo_Cliente con un nuevo acceso a otro fichero y con dos nuevos cálculos. Hay que modificar y compilar el programa de servicio pero, ¡¡¡¡los módulos que lo utilizan NO hay que cambiarlos y ni siquiera compilarlos !!!!

Uso de plantillas

Basado en el punto anterior, sería posible desarrollar una serie de plantillas de módulos de gestión de una pantalla ya que siempre (en general) el funcionamiento es igual según el tipo de pantalla. Las funcionalidades de un programa de lista de subfichero es siempre igual, lo único que cambian son los datos que se presentan. Lo mismo para un módulo que permita presentar y gestionar una pantalla para mantener un registro.

Todo ello permite "ahorrar" el tiempo de codificación ya que hay código invariable y que ya esta probado y sólo hay que centrarse en incluir lo específico de las funcionalidad que estamos desarrollando.

Podríamos tener dos plantillas para módulos de pantalla:

• Módulo para Lista de registros para acceder a un mantenimiento.
  Será una pantalla con un subfichero donde se presentan registros para realizar un mantenimiento. Tendrá en cabecera unos campos de búsqueda para restringir la información que aparece en el subfichero. Por cada registro del subfichero tendrá un campo de opción para poder acceder al módulo que realiza el mantenimiento (actualización, borrado o consulta). Y tendrá un mandato para dar de alta un nuevo registro accediendo al módulo de mantenimiento (en modo alta) y otro mandato para finalizar el programa.
• Módulo para Mantenimiento de un registro.
  Será una pantalla de mantenimiento de un registro que sería llamado desde la plantilla anterior y que podría hacer las acciones de alta, modificación, borrado o consulta de registro. Al acceder, recuperaría los datos (a través del componente) del registro a mantener, permitiría al usuario incluir o modificar la información, validaría la información y tendría dos mandatos, uno para confirmación la acción y otro para retornar al programa de lista.

También se podrían tener plantillas relacionados con los componentes de acceso a la base de  datos.

• Componente para Recuperar un registro o una lista de registros de la base de datos.
  Se puede desarrollar una plantilla con SQL para recuperar un registro o un conjunto de registros de la base de datos para quien se lo solicite.
• Componente para Insertar, Actualizar y Borrar un registro de un fichero.
  La plantilla tendría las acciones con SQL para realizar una insercción, actualización o borrado de un registro.

Próximos artículos

En los próximos artículos explicaré el uso que realizo de Ds (estructuras de datos) y os podré ejemplos de los componentes de acceso a la base de datos y de validaciones que realizo y que me sirven de plantilla para el desarrollo de aplicaciones utilizando ILE y separación de capas.