secciones

UML: Tres modos para tres objetivos

“Tres modos para los Reyes Elfos bajo el cielo…”. Err… no, no era esto.

En su weblog Martin Fowler comparte sus reflexiones sobre los modos en que se puede usar el UML: como un bosquejo cuando se hace el modelo conceptual, como un modelo o plano cuando se diseña la solución o como un lenguaje de programación directamente con generación automática de código.

Cada uno de estos modos precisa de distintas herramientas (un simple programa de diagramado servirá para el modo bosquejo mientras que para el modo lenguaje se precisará de completos entornos de desarrollo).

Sobre el uso del UML como lenguaje de programación (“dentro de poco no necesitaremos programadores”) no parece muy optimista: Es más rápido escribir código que hacer un diagrama de lo que ese código hace.

6 Comentarios
Salva
9 enero 2004, 01:21 — #1
De hecho la empresa Wolfram (la misma que la creadora de Matlab) ha creado un programa que, mediante diagramas de blog o de flujos, genera el código en C optimizado.

Así que como esto se ponga de moda, mejor que deje la carrera y me dedica a la carpintería.

Un saludo.
Jose Alberto
9 enero 2004, 17:00 — #2
Salva... Que escribir código es sólo una parte de desarrollar una aplicación y no digamos ya de un producto comercial.

Es cierto que el buen funcionamiento de una aplicación informática depende en gran medida de la calidad del código, por eso, cualquier herramienta que nos ayude con ésto bienvenida será.

Yo debo ser algo torpe porque nunca he conseguido aprender bien UML, tengo unos cuantos libros, he intentado aplicarlo en el desarrollo de algunas aplicaciones, pero nada, no termino de pillarle el "quid"...

Un saludo.
Juanjo Navarro
13 enero 2004, 13:20 — #3
Salva, no sólo la escritura de código es sólo una parte del desarrollo software, sino que está por ver si hay una forma de programar que sea "mejor que programar".

Vale, está claro que puede haber una herramienta que a partir de un diagrama de flujo (o UML) te genere código. Pero... ¿cuanto tiempo se tardará en hacer ese diagrama respecto a lo que se tarda en escribir directamente las líneas de código?

Jose Alberto, tampoco yo lo he utilizado mucho, quiero hacerlo más a menudo. Yo le veo mucha utilidad en los dos primeros modos que describo en el artículo, para realizar la arquitectura del sistema sobre papel.

De esta manera la arquitectura queda explicita en un documento y no solo en tu cabeza. Por ejemplo, leyendo algunos libros de patrones de software, el esquema UML ayuda mucho a entender la estructura que el texto describe. Esto mismo creo que es aplicable a nuestros propios proyectos.
Albin
17 marzo 2004, 11:24 — #4
Nunca lo generarán todo. Tu a UML le dices, recibo este InputStream (por poner un ejemplo) y devuelvo este String (por poner otro ejemplo) pero no tienes forma de que adivine qué transformaciones existen por el medio.
Dirceu Navarro
Dirceu Navarro
14 abril 2004, 02:38 — #5
Algo que siempre me he preguntado es como pasar del modelado a la programación, por ejemplo en los diagramas de secuencia se tienen muchos objetos (de interfaz de usuario, controladores, entidad, etc), pero a la hora de programar como se define todo eso, si en los lenguajes de programación como por ejemplo el Delphi o el CBuilder, solo se tienen objetos de interfaz de usuario (Forms) y usualmente la mayoría de las personar programan como si esos objetos de interfaz de usuario fuera los controladores y fueran de todo. Existe alguna mejor forma de que el UML no solo sea unos diagramas que la mayoría de la gente no puede aplicar cuando quiere hacer incluso un simple programa?
Juanjo Navarro
14 abril 2004, 09:45 — #6
Dirceu, la forma de pasar de uno a otro es precisamente esa: implementando el diagrama.

Lo que dices de programar todo en en los Forms es claramente un error de programación. Diseña unos buenos diagramas UML (con una complicación adecuada a la aplicación que estés haciendo, no vayas a poner 10 clases para un HelloWorld) y después llevalo a la programación. Es así de simple. Nadie te obliga a programarlo todo en los Forms, de hecho muchos directamente te lo desaconsejamos :-)

Un saludo.

Comentarios cerrados para este artículo

Anterior: El síndrome NIH (Not Invented Here) Siguiente: Libro: The Mythical Man-Month