gracias a todos por los comentarios!

Yo creo que hay varios motivos por los que algunos prefieren “dibujar” que programar:

- La metafora de la construcción, el que dibuja es arquitecto, el que escribe código albañil. Nada ha echo más daño al desarrollo de software que esta mala, malisima, metafora.
- Los dibujos ni hay que compilarlos ni generan excepciones en runtime, así que ningún cliente te enviara un error por haber echo mal un dibujo.
- Programar es dificil, programar bien es mucho más dificil. Dibujar un UML… seamos serios… si da igual que este mal o bien echo!, que luego no falla en runtime y si el programador protesta porque no entiende el diseño o esta bien pues que se apañe como pueda.

Dicho esto, yo uso el UML para algunas cosas, por ejemplo para compartir ideas de diseño con otros compañeros o bien para dejar documentación de partes complejas de algún proyecto (diagramas de secuencia por ejemplo me resultan muy utiles).

Yo más que decir que el UML este muerto lo que ocurre es que a través de la experiencia lo estamos poniendo en su verdadero lugar, es muy útil para algunas cosas, pero el software se hace escribiendo codigo, el UML es solo una ayuda no puede ser el centro del desarrollo, el centro es el código.

Yo creo que por 2 motivos:
- 1: no tengo idea de programar, ergo hago dibujitos
- 2: tengo que comunicarme con gente que no entiende de programación, ergo lo hago a través de dibujitos.

Cuando yo estudié creo que ni existía esto del UML, luego dejé la programación y hace pocos años he retomado el tema. Así que me salté esto de los UML.

Joserra! ¿no te veré en el Cadius de éste viernes? ¡Qué pena!

Y si en algún momento tocaba inventarse algún símbolo o improvisar, pues se hacía. Al fin y al cabo, una de las reglas de UML es que el lenguaje no está limitado.

Tu cuestionario:
- Usamos UML sobre todo para especificar el modelo de dominio (y sí, lo generamos a código). Y para pintar en las pizarras para discusiones sobre cómo hacer las cosas.
- solo un esuqema por Dios! Supongo que conoceré un 10% de la especificación UML.
- Generamos el modelo con el ArgoUML
- Reverse engineering no usamos… salvo que consideres a Hibernate que lo hace cuando te crea el modelo a partir de la BBDD
- Agilidad y UML no tienen nada que ver, creo. Una cosa es un modelo de hacer el desarrollo, una filosofía, y la otra una herramientas, que tú verás como la usas.

Salu2

Creo que UML es una buena herramienta para hacer diagramas de alto nivel de abstracción y punto. Cuando se abusa tratando de especificar TODO (para eso está el código, y así es de complicado) se vuelve ilegible.

Punteando tu cuestionario:
* sí lo uso aunque muy esporádicamente, por ejemplo para documentar un primer diseño o la interacción del usuario con el sistema. Siempre indicando qué sucede, no cómo va a implementarse. Si es para mostrar la estructura de objetos de negocio o clases del código tiene que ser muy muy acotado.
* ¿Totalmente especificado? Puede ser, pero nadie se toma el trabajo de leer y respetar esa especificación. Es sólo un dibujito, lo importante es que se entienda.
* Herramientas no, salvo para generar diagramas de clase (¡acotados!). Marcador, pizarra y borrador. Mucho más tarde, cuando el diseño está asentado tal vez valga la pena copiarlo a un documento.
* Lo del reverse engineering no es muy útil si es que va a ser completo (es decir un diagrama de toda una aplicación). Una herramienta automática te va a hacer un diagrama tan complicado como el código que representa.
* RUP… yo no conozco a nadie.
* UML + ágil, sí por supuesto. De hecho es muy útil. Todo pasa por entender que no hay que exagerar, que la idea es comunicar grandes rasgos de un módulo o sistema o la interacción con el usuario u otros sistemas y punto. Cuando se pretende documentar TODO en UML (incluso las modificaciones más pequeñas) se deja de ser ágil.