Hace un par de días el autor de uno de mis blogs preferidos se preguntaba si el UML estaba pasado de moda. Lo del uso o desuso del UML es un tema que me toca la fibra. En principio yo pienso que no ha terminado de extenderse todo lo que se presumía, pero aún así lo creo algo imprescindible y a mi modo de ver se irá propagando poco a poco.
Uno de los primeros problemas que veo es el modo en el que empezó a enseñarse. Los que como yo lo hayáis estudiado hace unos siete años, seguramente, habréis aprendido toda una metodología cerrada en la que empezabais por los casos de uso, seguías con los diagramas de clases y así sucesivamente en un orden fijo preestablecido, bastante aburrido por cierto, en el que lo último que dibujaríais sería el diagrama de despliegue. Ni que decir tiene que en mi caso me limité a aprobar la asignatura y después lo dejé un poco de lado (ummm ¿no hice eso con casi todas? ¡Ah! ¡No! Hice esa carrera por que me gustaba :p ).
Afortunadamente parece que este modo de ver las cosas ha ido cambiando. En realidad todo es mucho más flexible pero tal vez no hemos entendido aún que hay miles de formas de usar UML y su uso tiene que ser diferente en base al perfil de quien lo haga:
Una vez escogida la herramienta más adecuada la forma de aplicar UML vendrá determinada en gran medida por el entorno en el que nos encontremos. Puede influir en ello la carga de trabajo, los conocimientos de UML de todo el equipo de trabajo, la naturaleza de los proyectos, etc.
En definitiva cada equipo debe encontrar su modo idóneo de utilizar UML, los ingenieros debemos acostumbrar a programadores y altos mandos a recibir pequeñas raciones de diagramas cuando lo creamos necesario. No olvidemos tampoco que en este país muchos ponen en duda que nuestro trabajo sea una ingeniería y en parte se debe a que todas nuestras metodologías de trabajo están verdes, por eso creo, aplicando un símil con el mundo de la construcción (como no) que nuestra herramienta CASE debe ser lo mismo para nosotros que el AutoCAD para un arquitecto.
Uno de los primeros problemas que veo es el modo en el que empezó a enseñarse. Los que como yo lo hayáis estudiado hace unos siete años, seguramente, habréis aprendido toda una metodología cerrada en la que empezabais por los casos de uso, seguías con los diagramas de clases y así sucesivamente en un orden fijo preestablecido, bastante aburrido por cierto, en el que lo último que dibujaríais sería el diagrama de despliegue. Ni que decir tiene que en mi caso me limité a aprobar la asignatura y después lo dejé un poco de lado (ummm ¿no hice eso con casi todas? ¡Ah! ¡No! Hice esa carrera por que me gustaba :p ).
Afortunadamente parece que este modo de ver las cosas ha ido cambiando. En realidad todo es mucho más flexible pero tal vez no hemos entendido aún que hay miles de formas de usar UML y su uso tiene que ser diferente en base al perfil de quien lo haga:
- Un programador debe saber "leer" UML y no tiene por qué escribirlo. Parece una tontería pero leer bien un diagrama de clases que modela el diseño de una parte de la aplicación significa que sabremos como escribir el código de esas clases: una herencia se convertirá en un "extends" (fácil), pero ¿y una agregación? ¿y una composición? Esto implica también que quien haga el diseño debe saber lo que está pintando ya que repercutirá en el código.
- Probablemente las capas altas de tu organización y los clientes finales no habrán ni oído hablar de este lenguaje, así que mostrarles un diagrama de interacción o estados puede ser bastante inútil. Sin embargo no se debe desechar la posibilidad de enseñarles algún diagrama de casos de uso, despliegue, o incluso de clases orientado al análisis (preferiblemente representando las clases como cajas simples, sin los compartimentos de atributos y métodos).
- Por supuesto que los que se encuentren entre los dos extremos (analistas de cualquier tipo, coordinadores, etc.) deberían saber leer y escribir UML.
Una vez escogida la herramienta más adecuada la forma de aplicar UML vendrá determinada en gran medida por el entorno en el que nos encontremos. Puede influir en ello la carga de trabajo, los conocimientos de UML de todo el equipo de trabajo, la naturaleza de los proyectos, etc.
En definitiva cada equipo debe encontrar su modo idóneo de utilizar UML, los ingenieros debemos acostumbrar a programadores y altos mandos a recibir pequeñas raciones de diagramas cuando lo creamos necesario. No olvidemos tampoco que en este país muchos ponen en duda que nuestro trabajo sea una ingeniería y en parte se debe a que todas nuestras metodologías de trabajo están verdes, por eso creo, aplicando un símil con el mundo de la construcción (como no) que nuestra herramienta CASE debe ser lo mismo para nosotros que el AutoCAD para un arquitecto.
No hay comentarios:
Publicar un comentario