Modelando realidades

Un esquema que me ayuda a entender las aplicaciones que desarrollamos con GeneXus es el siguiente:

No es nada original, pero me sirve para clasificar los objetos que utilizamos en el desarrollo de nuestra aplicaciones.
Tenemos tres modelos o vistas de la misma realidad, cada uno con un nivel de abstraccion diferente:

Modelo Físico

Aquí se encuentran las tablas y sus estadísticas de uso y  de distribución de datos, los indices, los diferentes tablespaces. También pongo ahí, todos los servicios que mi aplicación deba utilizar para funcionar.
Este modelo es fundamental para el correcto funcionamiento y performance de la aplicación, pero su complejidad es la que Genexus nos ha escondido (para bien) por años.
La aplicación va a seguir funcionando correctamente si tengo o no tengo un indice, aunque puede tener mejor o peor performance.
En este nivel, es donde trabajan principalmente los administradores de base de datos (DBAs) y administradores de sistemas (servidores de aplicaciones, servidores web, proxys, servicios web consumidos, etc).
Los desarrolladores GeneXus se tiene que preocupar poco por este nivel, a no ser que tengan problema de performance. A este nivel funcionan la auditoria con triggers, la reorg, las herramientas de ingenieria reversa, data view.

Modelo Lógico.

Es donde se modela lógicamente la aplicación, sin preocuparme de como va a ser implementado,  con las transacciones, data providers, data selectors y demás.
Por deformación profesional, es lo que mas me gusta hacer.
Aquí nos preocupamos por subtipos, claves, relaciones de integridad y se logra modelar lo que ve el usuario.
La particularidad que tiene Genexus es que teniendo el modelo lógico definido, logra deducir y generar el diseño del modelo físico, ahorrando muchísimo trabajo. Esto trae como consecuencia que muchos desarrolladores GeneXus no tengan claros conceptos básicos de modelo físico, por lo que pueden cometer errores que hagan que sus aplicaciones funcionen lento.

Modelo Conceptual

Es donde desarrolla la aplicación, es lo que el usuario final ve.
A este nivel hay que preocuparse de la estética, la usabilidad, el diseño gráfico de la aplicación.
Es donde los desarrolladores GeneXus deberíamos pasar la mayor parte de nuestro tiempo para ser mas productivos.

Utilidad. 

Para que sirve todo esto?
En realidad, ayuda a entender un poco mas como desarrollamos y los diferentes roles que se necesitan para lograr aplicaciones que sean usables. Todos los niveles deben estar mínimamente bien resueltos para lograr que la aplicación funcione correctamente. Los conocimiento que se necesitan para lograr un buen funcionamiento en el modelo conceptual, son totalmente diferentes a los que se necesitan para el modelo físico.
Cuando un desarrollador GeneXus  utilizando patterns, necesita hacer usar el comando NEW (que trabaja al nivel casi físico) al cambiar de nivel, baja su productividad.
Por eso es bueno que se tengan la mayoría del grupo de desarrollo trabajando a nivel mas alto de abstracción y que las tareas de modelado (lógico) y de optimización (físico) sean realizado por especialistas siempre que sea posible y no sean cuello de botella en el desarrollo.

Supongo que en el futuro cercando la especialización hará que tengamos herramientas especializadas para cada uno de los modelados.

Por ejemplo, ya existen herramientas especializadas para la edición de temas, editor de patterns, para el nivel conceptual.

A nivel de modelo lógico, hay diagramas de módulos, diagramas de relación entre transacciones y demás que ayuda a visualizarlo, aunque aun son muy mejorables.

A nivel físico, es donde puede mejorar bastante mas. Se puede hacer modelos de instalación de las aplicaciones para ayudar a los administradores para hacer el deploy de las mismas y tambien herramientas especializadas para el DBA, para que puedan manejar el modelo fisico desde GeneXus y no teniendo que usar herramientas especificas de las plataformas. Por ejemplo, si se conociera la cardinalidad de las tablas y su crecimiento, se podrian planificar los recursos necesarios a lo largo del tiempo o estudiar los programas que accede a tablas muy grandes, etc.

Cosas que se me ocurren que podríamos tener es tener registro de los diferentes ambientes donde se instala la aplicación (desarrollo, test, pre-producción, producción), en que servidores se instala en producción. tener un registro de todos los servicios consumidos y publicados por mi aplicación, que directorio necesita o utiliza mi aplicación, etc.

Conclusión. 

La división en diferentes modelos (conceptual, lógico, físico) es bastante arbitraria, pero ayuda a entender problemas algo mas chicos y limitados, que son mas fáciles de entender y resolver los problemas que se producen en ellos.
El hecho que Genexus nos aísle de algunas complejidades técnicas de bajo nivel, no quiere decir que las mismas no existan y posiblemente sea momento de  brindarle herramientas a los profesionales de cada uno de los niveles herramientas adecuadas para que puedan cumplir con su tarea de forma productiva.