Barrapunto

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.

Hombre, estoy de acuerdo en que detallar hasta el más nimio detalle en un diagrama UML es un coñazo además de un trabajo que luego se va a aprovechar bien poco, pero este tipo de herramientas funcionan muy bien para hacer, por lo menos, el "armazón" del programa. Hacer un diagrama de clases más o menos sencillo y con los principales métodos y atributos de cada clase es bastante sencillo y más rápido que programar todo el código. Luego, eso si, hay que rellenar.

Creo que el principal error al enfrentarse con este tipo de programas, es que esperamos que nos resuelva la vida. Siempre hay que trabajar un poco, no nos van a dar todo hecho.

Y por cierto, una ventaja muy importante que veo en primero hacer un par de modelos gráficos y luego empezar a programar es que facilita mucho la coordinación entre miembros de un grupo de programación. Cuando varias personas participan en el mismo proyecto esto es un tema serio. Aunque claro, esto se puede obviar para hacer nuestros propios programas en solitario.

Un saludo.