Ojala este post, por su título, que es UML, solo estuviera escrito pensando en quienes no han estudiado informática, para los autodidactas, o para quienes no son informáticos pero trabajan con ellos y necesitan conocer “sus dibujos”, o para los que subcontratan software y no son informáticos o para cualquier otro que necesite entender mínimamente un diseño software o transmitir sus ideas sobre el mismo.
Y quizás así debería ser. Pero también está pensado para recién licenciados en informática, ya que cada vez me encuentro con más ingenieros informáticos que tienen graves problemas a la hora de interpretar o dibujar diagramas UML. Y este es un tema que tenéis que solucionar ya, porque produce errores de verdad, si de verdad [lo he vivido].
Este post no es un tutorial de UML (hay miles por la web), solo pretende introducirte en que es UML, por qué es importante conocer un mínimo (al menos, unas cuantas cosas, y un par de diagramas UML) y que te den muchas ganas de leerte algún libro sobre el tema (te recomiendo el UML Distilled, apenas 200 paginitas)
Que es UML y por que son importantes los diagramas UML
El “Lenguaje Unificado de Modelado” o UML (de Unified Modeling Language) no es ni un método, ni una metodología, ni un ciclo de vida, ni similar. UML es sólo un lenguaje gráfico (símbolos que cuando los vemos todos interpretamos lo mismo) para representar partes de un sistema de software (diseño, comportamiento, arquitectura, etc.), con diagramas UML. Abajo, un ejemplo (un diagrama sobre una refactorización).
Así, por ejemplo, cuando alguien quiere representar una clase, dibuja un cuadrado y todos sabemos a qué se refiere. Cuando dibuja una flecha cuya punta es un triangulo, todos sabemos que es herencia. Y así sucesivamente.
Esto tiene su lógica razón de ser: nos vale para comunicarnos e interpretar todos lo mismo al ver esos diagramas UML.
El problema viene cuando muchas veces, muchas, hay quien olvida que es UML, o lo desconoce, y saca el Visio, o similar, y da rienda libre a su capacidad artística, dibujando cuadrados cuando quiere pintar ficheros, y que luego otros interpretan como una clase UML [lo he vivido]. Y quien dice cuadrados, dice nubecitas, trapecios, cubos, etc.
Los peores errores y peligros vienen cuando alguien usa inconscientemente los mismos símbolos de los diagramas UML… pero queriendo decir otras cosas. Pasa mucho con las flechas, se pinta una flecha cualquiera queriendo decir “asociación” entre objetos (paso de mensajes), pero se usa la flecha de herencia, y al final se implementa cualquier cosa [lo he vivido].
Llevándolo a extremo más simplista del mundo, como mínimo, habría que conocer dos flechas, solo dos, la que termina en triangulo (herencia) y la que no (asociación). Saber que una clase en un cuadrado (sin esquinas redondeadas), que un objeto es un cuadrado con el nombre de la clase subrayado y “: “delante del mismo. Y no pintar una cosa por otra.
Y de los 14 diagramas UML saber dibujar bien dos, los diagramas UML de clases y de secuencia. Sólo eso.
Terminando…
UML, en su plenitud, es un lenguaje gráfico muy extenso. La versión 2.2 tiene 14 diagramas UML divididos en dos categorías (7 representan información estructural, y otros 7 representan comportamiento). Pero en la práctica no necesitas todo eso, pero si necesitas saber que es UML, y un mínimo, que no será de más de 10 símbolos.
Conocer ese mínimo te permitirá (seas informático o no) saber dibujar un diseño, o cómo se va a comportar el sistema. Entender, y que se te entienda. Y evitar que se te malinterprete.
Como os decía, el que es para mi el mejor libro UML, que más claros deja los diagramas UML y por que es UML importante es UML Distilled de Fowler, el que firmó el manifiesto ágil entre otros (¿alguien dijo que UML no vale en entornos ágiles?). Otro recomendado, para mi lejos del anterior, es el de Ambler, sobre UML en entornos ágiles.
Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.
También soy profe de la Universidad Rey Juan Carlos.
- Las 3 matrices de priorización Ágil - 19 octubre, 2023
- Etapas del Agile Product Management - 12 octubre, 2023
- Agile Product Management: DINÁMICA «Árbol Solución Oportunidad» + «Valores Esperados» - 5 octubre, 2023
Pingback: Bitacoras.com
Todavía en muchas entrevistas, al hablar con titulados varios (informáticos o no), me ponen caras raras al preguntar por UML, ingeniería del software, ciclos de vida…Da la sensación de que lo ven obsoleto, pasado de moda…
Creo que es fundamental que sin centrarnos en la documentación, los jóvenes informáticos entiendan la necesidad de facilitar y acelerar la comunicación entre miembros de un equipo. UML ayuda en todo esto. Cuántas conversaciones habré visto entre analista y programador que se zanjaban con un diagrama en papel en 10 segundos…
También es importante tu comentario sobre Fowler, puesto que muchos autollamados agilistas, huyen de UML y cualquier tipo de documentación como la peste…
Como es habitual, acertado el post, Javier. Saludos.
Hola Roberto,
Pasa mucho. Hay cosas en la profesión que aunque en tiempos se usaran mal no por ello hay que tirarlas.
Gracias
Hola a todos,
cuando yo lo estudié en la carrera muchas veces se vendía como una herramienta con la cual diseñarías el software a modo de planos y luego vendría otro y picaría el código. En este blog Javier ya ha discutido algo con lo que estoy totalmente de acuerdo, la ingeniería del software no es como construir un edificio o construir un coche, en la mayoría de los casos dichos diagramas deberán ser retocados, con suerte poco, dependerá mucho de la experiencia del equipo de desarrollo. Quizás sea este un motivo por el cual nuevos informáticos no lo conocen/caiga en desuso. Aún así me parece un factor clave para diferenciar entre lo que es un informático y un ingeniero informático. En mi opinión, aún en el caso de que hubiese que retocar los diagramas, es muy útil para hacerse una primera idea de cómo funcionará un sistema, hace dos semanas un compañero me presentó un nuevo subsistema a implementar y para que lo entendiese me dió dos opciones, un diagrama de secuencia o el texto que habían escrito los ingenieros de requisitos… claramente me quedé con lo primero, ya que es mucho más esquemático, rápido y directo. Para otra cosa que lo encuentro superútil es para documentación, como bien ha dicho Javier, un diagrama de clases y un diagrama de secuencia son para mi la forma más rápida de entender un sistema, aunque a veces parezca de «la vieja escuela».
Saludos
HOLA QUISISERA SABER SI ESTA HERRAMIENTA ES UN SOFTARE LIBRE O CON LICENCIA?
Es un software libre.
Buen post!
Ay mucha gente que pasa de los gráficos sean o no UML.
Y si le preguntas:
– ¿Por que no preparas antes gráficos, antes de hacer la tarea?
Y pre responden:
– Porque es mas faena.
Y yo me quedo con la cara de que coño ( ¬¬ ).
Otra cosa que les digo es: que no hace falta saber todos los tipos de Diagramas UML, solo con saber los basico/los mas usados.
Muy de acuerdo con los comentarios.
Añado que usar un lenguaje grafico como UML no sólo sirve para documentar un software o transmitir información entre informáticos, también ayuda mucho a tomar decisiones de diseño o reflexionar sobre una posible solución antes de implementar.
Saludos.
Javier te Felicito, lograste una sonrisa en mi rostro luego de leer tu post, todo lo que aprendí en la facultad si sirve :D, aunque actualmente en la empresa donde estoy no le vean la importancia y me miren con cara rara cuando pregunto por un diagrama de clases o de comunicación para entender el software que quieren desarrollar.
Me alegro mucho de la sonrisa. No tanto por lo de tu empresa, pero ánimo con ello!
Esta información me ayudado a entender, lo primordial de aprender y poner en práctica, este lenguaje gráfico. Para desarollar Software o programas, así sea un programa sencillo. Realmente ayuda bastante a desarrollar también la lógica y como dar solución a un problema planteado de dicho sistema (sea real o virtual)
Hola quisiera saber si este es un software libre?
hola estoy en mi primer año de carrera de IT y lo del libro es un dato muy iteresante para mi lo voy a leer y tambien me ayuda a entender mejor todo sobre UML que es lo que me interesa saber bien