Barrapunto

Se usa sólo en las empresas serias, ese es el problema. Tampoco es una directiva a seguir al 100%; no tiene que abarcar un proyecto al completo.

Como casi todos los aspectos de ingenieria de software, su extension en S. Libre es casi nula.

Yo tengo una pequeña empresa de software y estoy evaluando este tipo de alternativas, con muy buenas impresiones por el momento. En concreto, estoy viendo AndroMDA, un proyecto Open Source, con un excelente soporte por parte del "cabecilla" del proyecto, y con un gran recorrido por delante.

El MDA puede ir muy bien o muy mal, dependiendo de a qué tipo de programas te dediques. Principalmente influyen dos factores: cuánto «se deja» modelizar tu sistema, y el trabajo previo que haya sobre el tema en concreto.

Si el tema al que te dedicas tiene trabajo previo hecho, te ahorrarás gran parte de las tareas difíciles: definir los metamodelos que vas a usar, las funciones de transformación, etc. Si no, no tendrás más remedio que ponerte con ello, por lo que has de tener en cuenta que el primer desarrollo será mucho más costoso en tiempo que los demás.

Además, si al final tienes que definir (o modificar) metamodelos que se ajusten a tus necesidades, puedes encontrarte con partes realmente difíciles de estructurar, lo que probablemente te obligue a pasar bastantes horas de trabajo con lápiz y papel intentando poner orden a tus ideas. Esto no es malo de por sí, pero la «sensación de productividad» decrece bastante, y eso podría desanimarte (¡o «desanimar» a tu jefe!).

Yo estoy ahora mismo con un PFC que trata de generación de código para determinado tipo de sistemas en tiempo real, y parece que la cosa llegará a funcionar y todo. Supongo que la clave del éxito es, precisamente, encontrar una solución de compromiso entre la flexibilidad de tu metamodelo y la facilidad para transformarlo después en código.

Desde los años 70 se nos viene hablando de la generación de código a partir de modelos visuales, lo que ha degenerado en los lenguajes gráficos tipo UML, las herramientas CASE, y demás.

Es posible generar código a partir de un lenguaje gráfico com UML, pero es tan práctico como escribir un libro mediante jeroglíficos. Cualquiera que haya usado UML para generar código sabe que al final tienes que detallar tanto el modelo gráfico para que genere código util, que habría resultado más facil hacerlo mediante un lenguaje no gráfico.

Los simbolismos pueden ayudar a representar ideas más o menos simples de un solo vistazo, pero para representar ideas complejas, como puede ser un libro o un programa completo, es mejor un lenguaje articulado convencional. Si acabas detallando el modelo gráfico mucho, se pierde el valor fundamental de lo gráfico, porque los detalles son tantos que acaban pasando desapercibidos para la vista.

¿Para hablar con las personas qué usáis, dibujos o palabras?. Al final va a resultar que van a llegar ahora una panda de lingüistas de Oxford y nos van a convencer de que expresarse mediante dibujos o jeroglíficos es más práctico que mediante palabras.

Y todos jugando al Pictionary, ese juego de mesa donde tienes que adivinar algo sin que el otro pueda decir una palabra.

Pero os aseguro a vosotros, filósofo-informáticos, por mucho que os pese, que los programas CASE y las herramientas UML sólo sirven para dos cosas: 1. Hacer dibujitos para la documentación, y 2. Generar diagramas de clases a partir del código. Recalco, primero haces el código, y después el dibujito. Todo lo demás está condenado al fracaso.

Quk.

No me dejan opinar con mi nick en Barrapunto por no ser ni socialista ni nacionalista.

Hola,
llevo algún tiempo trabajando en I+D en el campo de MDA y, si alguno quiere, podemos hablar offline para más información (asier.azaceta{at}esi.es).
De momento, lo que me gustaría aclarar es que MDA no es generación de código. Efectivamente la generación de código forma parte de MDA, porque es una "transformación", pero solo es un tipo de transformación (modelo a texto), y lleva muchos años en el mercado como para ser realmente novedoso.
Mucho más innovador es el uso de transformaciones de modelo a modelo, para pasar de unas capas de abstracción a otras, o para cambiar el punto de vista del desarrollo, o para combinar varios modelos en uno, etc...
En cualquier caso, el uso de MDA no está todavía extendido al público en general y solo los "early adopters" están realmente haciendo trabajo en este campo.
Uno de los factores clave ahora mismo es el retorno de la inversión (ROI) ya que para poder sacar partido a MDA tienes que tener una infraestructura (herramientas, transformaciones, metamodelos...) que ahora mismo, en muchos casos, tienes que desarrollar tu mismo.
En cualquier caso creo que tiene un futuro bastante prometedor y se está avanzando a pasos de gigante, por lo que previsiblemente en estos años veremos muchos cambios (2006 creo que dará frutos muy interesantes en este punto).

No quiero extenderme más, así que si quieres contactame offline y hablamos, estoy muy interesado en conocer gente interesada en el tema, sobre todo de cara a la adopción!! ah! y si me permitís, dejadme anunciar la segunda edición de una conferencia sobre el tema, este año, en Bilbao!!:
European Conference on MDA - Foundations and Applications (ECMDA-FA) - http://www.ecmda-fa.org/ [ecmda-fa.org]

Lástima que Olivanova tenga una política de cobro de 'tanto por línea', todo el tiempo que te ahorras en programación hay que pagárselo a ellos.
Y si intentas haces algo especial con el código generado lo tienes muy dificil ya que es casi ilegible.