Sobre modelos y GeneXus.

Un amigo me dijo que no había entendido que era lo que había querido decir en el post sobre MDE y DSL y me preguntaba sobre que eran los modelos y para que servían.

No soy especialista en la materia y voy a tratar de explicar como es mi visión de los modelos y hacia donde pienso que podría extenderse su utilización con las herramientas actuales.

Que es un modelo?

Un modelo es una representación simplificada de la realidad. Es una abstracción de un determinado proceso, generalmente mas sencillo de entender para quien lo mira.

Para que sirven los modelos?

Esta representación de la realidad, generalmente toman una característica del problema y lo representan de tal forma que pueda ser entendido en forma mas fácil por quien lo utiliza.

Por ejemplo, en un sistema de computación que utiliza una base de datos, el modelo de datos, es algo que muestra como están compuestas las tablas, que campos tienen, que relaciones existen entre las diferentes tablas, que indices se utiliza, etc.

Este modelo, no es la aplicación completa, sino que es una visión parcial del sistema, y sirve como herramienta de comunicación entre las personas que van a utilizar dicha base de datos, que pueden ser los administradores de la base de datos, los desarrolladores de la aplicación, quienes tiene que extraer datos para la confección de reportes, los encargados de seguridad, etc.

En muchas disciplinas existen modelos y son usados desde hace mucho tiempo. Por ejemplo en la construccion se hacen maquetas y planos. Algunos de estos planos son especializados para conexiones electricas, otros para la estructura, otros para los caños de agua y hay un monton de etc. Dependiendo la etapa del proyecto, se tienen menor o mayor nivel de detalle (o nivel de abstraccion).

Que ventaja tiene el tener modelos en el desarrollo de sistemas?.

La ventaja de la utilización de diferentes modelos y trabajar con un repositorio donde se guarde el conocimiento de la aplicación (en el caso de GeneXus, es la KB) es que de dichos modelos, se puede deducir muchas características de la aplicación final, y generar automáticamente dicha aplicación.

Por ejemplo, de un conjunto de estructuras visibles por el usuario (que en GeneXus mal llamamos transacciones) se puede deducir a través de un proceso de normalización la estructura de la base de datos en tercera forma normal.

Al hacer una modificación en el modelo de datos, la herramienta puede comparar dichos modelos y deducir cuales son los programas que reorganizan la base de datos y permiten pasar los datos de una estructura a la nueva.

Esto tiene enormes ventajas en la adaptabilidad de la aplicación a los cambios, pues permite realizar cambios en los modelos, con un lenguaje conocido y dominado por el especialista del area

y esto va a generar los cambios a la base de datos.

Si esta metodología, se extiende a todas las demás características importantes del sistema, las ventajas son muy grandes.

Porque no usar modelos y lenguajes para el dominio para todas las áreas de la aplicación?

La respuesta es simple. Al realizar un modelo, estamos simplificando la realidad (o abstrayendo). Toda abstracción, es una perdida de detalles, que puede no adaptarse correctamente a todos los casos. El desafío es lograr modelos que sean sencillos de utilizar y entender, pero que sean lo suficientemente generales como para abarcar muchos casos.

Dando algunos ejemplos de como podrían ser los modelos dentro de una aplicación.

Modelo de requerimientos.

Se pueden escribir requerimientos en lenguaje del usuario, pero que van a quedar asociados a determinados módulos (al principio) y a objetos específicos (cuando la aplicación este desarrollada).

Estos requerimientos van a poder tener asociadas pruebas de aceptación.

Cuando los requerimientos cambien, van a estar mas claros que hoy cuales son las areas afectadas por dicho cambio, pudiendose medir el impacto del cambio.

Cuando el cambio se haya realizado, podran ejecutarse nuevamente las pruebas de aceptacion si las mismas son automáticas o se podria tener la posibilidad de marcar el requerimiento como cumplido o faltante.

Modelo de Pruebas.

La gente de Abstracta, está trabajando en GXTest, donde se hoy ya se puede tener un modelo de los test que deseo realizar en mi aplicación. Cuando cambio mi aplicación las pruebas se adaptan a dicho cambio, por ejemplo si cambio la posición de un botón, o el nombre de un control, el modelo plantea posibles soluciones a dicho cambio.

Si les interesa el tema, pueden ver la charla de GXtest en el Encuentro GeneXus.

Modelo de Seguridad.

La definición de usuarios, controlar quien se puede conectar a mi aplicación (autenticación) y que puede ejecutar un determinado usuario (autorización) son características que casi todas las aplicaciones comparten. Seria bastante sencillo implementar un modelo donde el administrador de la seguridad de la aplicación defina donde se va a encontrar la lista de usuarios, como se van a poder conectar a la aplicación y definir quien puede acceder a que parte de la aplicación.

Ahorraría mucho trabajo a cada una de las empresas que hoy definimos esquemas de seguridad que varían de una plataforma a otra.

Modelo de Auditoria.

Es un modelo donde el usuario final elige que funcionalidad quiere auditar. Se relaciona con el modelo de datos y con el modelo de la aplicación.

Las cosas a auditar pueden variar mucho de una aplicacion a otra, pero el modelo abstracto es mas o menos parecido. Se podrian registrar intentos de acceso a partes del sistema no autorizado, cantidad de meses que se debe guardar determinada informacion de aditoria y muchos etc. Los cambios en esta parte del sistema es constante, y seria bueno poder manejarla en forma independiente a la aplicación.

Modelo de Reglas de la aplicación.

En los últimos años, han aparecido varios manejadores de reglas (BRMS), que permiten que el usuario final, defina un conjunto de reglas, que las aplicaciones utilicen en el momento de la ejecución. Esto brindará a nuestras aplicaciones mucha mayor flexibilidad. Por ejemplo podríamos brindar un conjunto de reglas para la definición de descuentos para los clientes en las facturas y nuestro programa pudiera llamar al manejador de reglas, que nos diga que descuento hacerle a determinado cliente y que sean los gerentes que definan que reglas seguir para llegar a dicho descuento.

En el Encuentro Genexus, Luciano Silveira dará charla sobre este tema, que pinta muy interesante.

Hablando del Encuentro, también hay una charla de Gastón especifica sobre Genexus y sus lenguajes de dominio y otra sobre MDD (de Pedro Molina), que son recomendables si estos temas les interesan.

En fin, el post quedó larguísimo y tengo que terminarla, pero hay varios ejemplos mas que se me ocurren.

Creo que es un buen momento para poner énfasis en el tema, pues vamos a salir todos beneficiados si hacemos las cosas bien.