UML - Conceptos básicos
Con una búsqueda sencilla vemos que UML son las siglas de Lenguaje Unificado de Modelado o en inglés Unified Model Language.
Sin embargo considero que esta única definición sólo sirve para quién ya tiene nociones del tema más no para quién recién empieza, por eso prefiero abordar primero 3 preguntas fundamentales en el orden específico que garanticen una mejor compresión del tema a estudiar. Estas 3 preguntas y su orden son: ¿Qué es UML?, ¿Por qué existe?, ¿Para qué sirve UML?. Estas preguntas abordan diferentes aspectos de este tema: ‘Definición’, ‘Justificación’ y ‘Objetivo’ en el mismo orden.
Al final responderemos una última pregunta: ¿Cómo? aunque de forma bastante superficial
La idea detrás de utilizar esta forma de estudio es la de alinear la ejecución técnica ( saber hacer las cosas) con el contexto del problema ( entender que se está haciendo y por qué se está haciendo).
¿Qué es UML?
UML es un estándar rico semántica y sintácticamente, adoptado a nivel internacional tanto por organismos como por empresas, enfocado en la representación de la arquitectura, el diseño y la implementación de sistemas de software tanto en estructura como en comportamiento. La idea detrás de UML es la de estandarizar un único lenguaje de modelado en el que se acuerda cuales son los símbolos utilizados, los métodos para usar esos símbolos y los problemas que resuelven el uso de esos símbolos. Si todos hablamos el mismo lenguaje con las mismas reglas la comunicación entre personas y la comprensión de los sistemas se hace mucho mas fácil.
Por el contrario si cada quién utiliza símbolos diferentes con significados diferentes, entender la representación gráfica de un sistema u otro se convierte en un problema de torre de babel.
¿Por qué existe UML?
Para entender de dónde nace UML hay que ver un poco de historia.
En la década de 1980 el mundo del software vivía cambios muy interesantes: Por un lado los equipos de cómputo se volvían cada vez mas capaces, con características nuevas y por lo tanto emergían sistemas que hacían uso de interfaces gráficas (GUI) bastante llamativas para el público en general, por otro lado el lenguaje de programación C++ empezaba a ver la luz del sol y con él una nueva forma de pensar y resolver los problemas de software que crecían en complejidad: la orientación a objetos.
La orientación a objetos es un paradigma que nació como respuesta a la necesidad de los desarrolladores por abordar la ejecución de software que progresivamente se hacia cada vez mas complejo y difícil de mantener con el paradigma de la programación estructurada tradicional.
En este contexto entre los años 1989 y 1994 se vivía una autentica fiebre por el mundo de la orientación a objetos: todos querían subirse a este tren, hablar y pensar en términos de objetos, resolver la complejidad de los sistemas con una forma mas estructurada y lógica, sin embargo no existían reglas claras en cuanto a comunicación.
El software es un problema complicado y por lo tanto para su entendimiento hace falta no solo palabras sino gráficos. Los humanos entendemos mejor las cosas si utilizamos dibujos para explicar un tema en lugar de miles de palabras cayendo como gotas de lluvia, de ahí el dicho: una imagen vale mas que mil palabras.
Así pues para poder entender estos sistemas en este nuevo contexto de orientación a objetos había que hacer dibujos o mejor dicho representaciones gráficas de los sistemas, sus elementos, sus comportamientos y los datos que se mueven a través de los mismos. Conforme el mundo del software crecía en tamaño y dificultad aparecían “estándares” para estos dibujos o representaciones gráficas: ¿cómo hacemos estos gráficos?, ¿que significa cada uno? ¿cómo se utilizan?, ¿en que orden?, ¿que problemas abordan?, etc.
El problema principal en todo esto, es que cada quien respondía a estas preguntas de la forma en la que mejor lo consideraba haciendo que al mismo tiempo llegasen a existir mas de 50 métodos de modelado o formas organizadas de hacer estas representaciones gráficas. La falta de un orden y una forma común de hablar es que entender cada sistema requería aprender un “lenguaje nuevo”. Esto era insostenible para los desarrolladores que se movían entre empresas y proyectos así como para aquellas organizaciones dedicadas a crear software de modelado.
Una de estas empresas consciente de este problema era Rational Software Company quienes buscaban la forma de mejorar la construcción de sus herramientas CASE en medio de esta torre de babel creciente. En esta empresa trabajaba uno de los protagonistas de UML: Grady Booch, creador de uno de los métodos de modelado mas populares de la época, conocido simplemente como el método Booch.
Pero Booch no estaba solo en esta historia. Existían otros dos métodos que dominaban la escena: el OMT (Object Modeling Technique) de James Rumbaugh y el OOSE (Object-Oriented Software Engineering) de Ivar Jacobson. Cada uno tenía sus fortalezas: Booch era fuerte en diseño, OMT en análisis y OOSE en el concepto de casos de uso, que hoy nos parece obvio pero en su momento fue una novedad.
En 1994 Rumbaugh se unió a Rational y al poco tiempo lo hizo Jacobson. Los tres, conocidos desde entonces como los tres amigos, se pusieron una meta ambiciosa: en lugar de competir entre ellos, unificar sus tres métodos en uno solo que conservara lo mejor de cada uno. El resultado de ese esfuerzo fue presentado en 1996 y enviado en 1997 al OMG (Object Management Group), el organismo encargado de los estándares en el mundo del software orientado a objetos, que lo adoptó oficialmente ese mismo año. Había nacido UML.
Por eso existe UML: no porque alguien lo inventara desde cero en un escritorio, sino porque la industria ya no podía permitirse 50 formas distintas de dibujar lo mismo.
¿Para qué sirve UML?
Ya sabemos qué es y por qué existe, ahora la pregunta práctica: ¿para qué me sirve a mí, que escribo código?
UML sirve para comunicar, documentar y razonar sobre un sistema antes y durante su construcción. Cuando un sistema es pequeño y lo hace una sola persona, todo cabe en la cabeza. Cuando el sistema crece, el equipo crece o el tiempo pasa y hay que volver a un código escrito hace meses, la cabeza ya no alcanza: hacen falta dibujos que muestren qué piezas existen, cómo se relacionan y cómo se comportan.
En concreto, UML te permite visualizar la estructura de un sistema (qué clases, componentes y piezas lo forman), especificar su comportamiento (qué hace, en qué orden y ante qué eventos) y dejar constancia de las decisiones de diseño para que otros —o tu yo del futuro— las entiendan sin tener que leer miles de líneas de código.
Igual de importante es entender lo que UML no es: no es una metodología ni un proceso de desarrollo, no te dice en qué orden trabajar ni cómo organizar tu equipo. Tampoco es un lenguaje de programación: un diagrama no se ejecuta, es una representación. Y por sí solo no garantiza un buen diseño; es una herramienta de comunicación, y como toda herramienta, su valor depende de quién la usa.
¿Cómo?
Esta es la pregunta técnica y su respuesta completa daría para varios artículos, así que aquí va solo el mapa general.
UML define un conjunto de diagramas, donde cada diagrama responde a una pregunta distinta sobre el sistema. Se agrupan en dos grandes familias: los diagramas estructurales, que muestran qué cosas existen y cómo se relacionan, y los diagramas de comportamiento, que muestran qué hace el sistema y en qué orden.
Entre los estructurales, el mas conocido es el diagrama de clases: muestra las clases del sistema, sus atributos, sus métodos y las relaciones entre ellas. Junto a él están el diagrama de objetos, el diagrama de paquetes, el diagrama de componentes y el diagrama de despliegue, que muestra en qué máquinas o nodos corre cada parte del sistema.
Entre los de comportamiento, los mas usados son el diagrama de casos de uso, que muestra qué actores interactúan con el sistema y para qué; el diagrama de secuencia, que muestra el orden de los mensajes entre objetos en el tiempo; el diagrama de actividades, parecido a un diagrama de flujo para procesos; y el diagrama de estados, que muestra por qué estados pasa un objeto y qué eventos lo hacen cambiar.
No hace falta aprenderse todos de memoria para empezar: con entender el diagrama de clases, el de casos de uso y el de secuencia ya se tiene una base sólida para leer y dibujar la gran mayoría de los diseños que uno se encuentra en la práctica.
CONCLUSIÓNUML es el lenguaje común que la industria del software adoptó para dejar de hablar cada uno en su propio dialecto: sirve para comunicar, documentar y razonar sobre sistemas complejos, nació de la unificación de los métodos de Booch, Rumbaugh y Jacobson bajo el OMG, y se usa a través de diagramas estructurales y de comportamiento de los cuales basta dominar unos pocos para empezar.