Model Driven Architecture

Estuve en la charla del martes del Dr Oscar Pastor sobre MDA (Model Driven Architecture) y durante la charla misma y después de ella surgieron algunos puntos interesantes.

Para quienes no lo sepan MDA significa que el modelo ES la arquitectura. El modelo gráfico es procesado por software, el que produce código compilable.

Como todo buen programador tengo mis reservas al respecto, pero puedo hablar con algo de autoridad al haber utilizado durante un tiempo algunos sistemillas gráficos para creación de videojuegos y al compararlo con mi experiencia con UML, ER y otros diagramas.

De forma breve y concisa algunos puntos que se plantearon y luego mi pensamiento al respecto:

• El lenguaje de modelado nunca cubrirá todas las posibilidades, por lo que siempre se contará con una herramienta útil para obtener programas que ya no necesitamos.
• Nuestros queridos C y C++ también son lenguajes de modelado. Sólo el ensamblador le habla directamente a la máquina. Ya tenemos lenguajes de modelado, sólo son basados en texto. Un lenguaje gráfico no es menos lenguaje por ser gráfico. Por otro lado si el diseño del lenguaje fuera obviamente limitado (no turing completo) siempre puede tomarse el camino de la extensibilidad. De todas formas el software tiende a ser muy similar.
• Es gráfico asi que no es un lenguaje de verdad
• Al aprender a programar lo hacemos con diagramas de flujo. Estos diagramas son capaces de representar cualquier algoritmo. Siempre existe alguna forma gráfica de representar las mismas ideas. Esto asumiendo que quisiéramos representar las mismas ideas, ya que no me cabe duda de que se han introducido construcciones en los lenguajes específicamente dirigidas a paliar problemas producidos por la naturaleza textual de los lenguajes actuales (namespaces, por ejemplo).
• El modelo gráfico de un sistema real sería gigante y tan complejo que complicaría mas de lo que aportaría (cubriría todas las paredes de la sala, dijo un profesor).
• El código completo de un sistema real abarcaría varias cuadras si lo imprimimos en papel. Pero no lo hacemos por que el código nunca se mira como una sola pieza. ¿Por qué habría de ser distinto en un diagrama? Un buen lenguaje permitirá separar el modelo en secciones y una buena herramienta permitirá tener las referencias a mano, de la misma forma en que los entornos modernos de desarrollo tienen completación de código y buscadores de objetos y funciones que abren el archivo adecuado dentro de todos los que conforman el sistema.
• Visualizar cambios entre versiones sería complejo.
• El versionado se hace con herramientas que procesan texto. Se necesitará una herramienta que procese el diagrama y lo pueda mostrar de forma adecuada, pero los conceptos básicos del control de versiones no cambian. Si el versionado se realizara sobre el código generado, claro, sería muy difícil entender.
• El producto resultante sería lento.
• Los primeros compiladores de C generaban ensamblador, el que a su vez era transformado a código ejecutable por otro compilador. No hay ninguna diferencia aquí, el compilador de modelos genera código intermediato que debe compilarse. En mi opinión esto debería evolucionar para eliminar la necesidad de un lenguaje intermediato, claro, de forma que el modelo sea realmente el software y no una abstracción del lenguaje intermediato.
• No hay herramientas y ya ha pasado bastante tiempo planteándose esta idea, ¿será que no se puede?
• Los compiladores de C++ tardaron largos años antes de poder compilar templates de la forma en que el standard especificaba. El lenguaje C tardó años antes de ser aceptado como un standard internacional. Estas cosas toman tiempo, mas aún cuando no hay concenso sobre cómo debe enfrentarse un problema (para un ejemplo ver SQL).

A fin de cuentas la impresión que me llevo es que parece una buena idea pero SOLO si se elimina el lenguaje intermediato de forma que el modelo siempre sea consistente con el resultado y no se esté persiguiendo representar otro lenguaje de forma gráfica (lo que haría el lenguaje gráfico superfluo). Un set reducido pero turing-completo de primitivas gráficas podría perfectamente convertirse en el lenguaje de preferencia.

El programador no desaparece, sólo deja de preocuparse de menudencias. En su tiempo todo programador debía manejar los registros de la CPU, hoy sólo quienes programan Kernels, drivers o plataformas embebidas lo hacen. En el futuro quizás recordemos con orgullo que debíamos administrar memoria manualmente (o tal vez no, hasta hoy la teoría y práctica de recolección de basura no ha dado los resultados prometidos).

Como puede verse mi postura no es 100% a favor pero no me parece algo utópico sino un posible camino de evolución. Ya veremos que dice el tiempo y el mercado.

--Madster