Evolución del Modelado

El Modelo Visual de un problema

Pasada la época de los pioneros, la utilización de representaciones visuales esquemáticas de procesos y estructuras se extendió como una mejor manera de expresar un problema. Así se produjeron gran número de soluciones con diverso alcance, que evolucionaron en los últimos veinte años junto a los cambios de enfoque en la construcción de software. El modelo Entidad-Relación o Relacional desde fines de los 70, luego el análisis y diseño estructurado en los 80, y todavía hoy el modelo Orientado a Objetos, son los grandes creadores de notaciones de modelado visual. Sea por inercia o por real valor en la representación de un problema, algunos de estos estilos continúan teniendo plena vigencia: si bien la Orientación a Objetos es hoy dominante y ofrece una solución más consistente como modelo de análisis, diseño o programación, el modelo relacional continúa siendo la forma usual de representación de estructuras de datos. Los grandes actores en el manejo de datos son compañias propietarias de Bases Relacionales (Oracle, Sybase, DB2, SQL Server), aún basados en los principios de Codd y en el SQL como método de acceso.

Sin hablar de las representaciones históricas de diagramas de flujo, el primer intento de notación fue el estructurado: aunque la evolución posterior demostró sus limitaciones y complicaciones, aún muchos sistemas continúan documentados y construídos siguiendo sus técnicas, y mas, algunos centros de estudio lo siguen teniendo como materia de estudio, y como consecuencia, varias generaciones de profesionales continúan influenciados por los conceptos estructurales, al menos en América Latina.

Particularmente en la descripción y diseño de estructuras de datos, es un hecho la coexistencia entre las primeras notaciones y otras nuevas basadas en la orientación a objetos: las distintas propuestas a través del tiempo en general siguen siendo utilizadas, y distintas herramientas ofrecen la posibilidad de una u otra representación.

Todas -o casi todas- las teorías de modelado visual, proponen alguna forma en que los artefactos que describen el modelo puedan avanzar en algún grado en su implementación, sea en la descripción del SQL necesario para la creación de tablas (modelos ER), o la generación del código que cree clases y métodos (UML, modelos OO). Pero un inconveniente repetido en este nivel de uso de modelos, fue la desincronización entre este esquema descripto una vez estabilizado un modelo, y el estado final del problema, que prosigue siendo definido y refinado fuera del dominio de la herramienta visual. Si bien muchas herramientas incluyeron ingeniería inversa, para agregar o redefinir en el modelo los objetos realmente implementados, el problema de la asincronía entre el modelo real y el modelo visual subsiste. Este problema es el que atacan, en general, las herramientas CASE que producen diseño basado en un modelo.

Sincronización del modelo y el código ejecutado

La mayor objeción que se le ha hecho usualmente al uso de un modelo es que éste no está sincronizado con la aplicación en ejecución: cuanto más avanza el ciclo de desarrollo y mantenimiento de una aplicación, más diferiría el modelo respecto del código real construído y ejecutado. Este fue un argumento usual contrario a las primeras herramientas CASE, y es uno de los argumentos comunes provinientes de las variantes de Extreme Programming, así como últimamente lo es entre los teóricos de Software Factory, el emprendimiento de Microsoft sustentado en las ideas de Jack Greenfield y otros: El modelado correspondería a una época temprana del diseño de un sistema, que luego no resulta actualizado cuando se van produciendo nuevas iteraciones de desarrollo. En éste esquema, el modelo (visual) es "un bosquejo en una pizarra", que debe transladarse separadamente a código. Sin embargo, este argumento es anacrónico, al menos para UML, y probablemente para otras aproximaciones al diseño basado en modelos. Existe un amplio número de investigaciones sobre este aspecto, con distintas soluciones que permiten que un modelo se traduzca en código, y que un modelo pueda ser ampliado, reducido, o reestructurado, sin que pierda contacto con el código generado.

Capacidad de un modelo para traducirse a código

La otra gran objeción hecha al uso de modelos para representar un problema es que un modelo, especialmente si está basado en elementos visuales, difícilmente pueda desarrollar plenamente una solución: Jack Greenfield, defendiendo su visión de Factorías de Software, explica este punto de vista:

While stereotypes and tags can be used to decorate UML models, experience shows that more precise language features are required to support compilation, debugging, testing and other development tasks. Unlike MDA, we do not propose to use UML where programmatic manipulation of models is a key requirement. We use UML for discussion, sketching diagrams on whiteboards and napkins, using the UML static structure and sequence chart notations that are now almost universally recognized by developers.

While models play an important role, they are not the whole solution. Scaling up to higher levels of productivity will require the ability to rapidly configure, adapt and assemble independently developed, self-describing, location independent components to produce families of similar but distinct systems. It will require a transition from craftsmanship to manufacturing like the ones we have seen in other industries, and it will eventually produce more advanced earmarks of industrialization, such as supply chains, value chain integration, and mass customization. This vision cannot be achieved with models alone.

El camino de integración

Estos dos argumentos son atendibles, y más aún, en el caso de los conceptos derivados por Greenfield a partir de su cuestionamiento, proponen un nivel más alto de articulación de modelos. Sin embargo, puede afirmarse que son aplicables a una etapa previa de las herramientas y teorías de soporte del modelado. En su primera época, los modelos estructurales (Gane, Sarson, Yourdon) claramente divorciaban una visión genérica del problema, de su visión de detalle. Los modelos de datos (ER) sólo resolvían un aspecto, y todos ellos tenían grandes dificultades para afrontar modificaciones tardías. Pero no es la situación actual, que ha contado con los antecedentes de una década o más. De ésto especialmente se tratará aquí. Veremos que existen distintas vías de superación de éste límite.