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. Para dar un par de ejemplos existía el método de Coad/Yourdon propuesta por Peter Coad y Edward Yourdon o el método Shlaer/Mellor de los informáticos y teóricos del software Sally Shlaer y Stephen Mellor. La falta de un orden y una forma común de hablar daba como resultado el hecho de 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 conscientes 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:
-
Grady Booch (método Booch): Grady Booch era un ingeniero estadounidense, graduado de la Academia de la fuerza aerea, era jefe en Rational Software. Él fue el responsable de acuñar el termino “Diseño orientado a objetos” (OOD) a principios de los años 80. El método Booch implementado en el año 1991 era conocido por ser excelente para para la fase de diseño detallado y arquitectura de sistemas complejos.
-
James Rumbaugh: James Rumbaugh era un científico de la computación con un doctorado en el MIT, que trabajó por mas de 25 años en los laboratorios de investigación y desarrollo de general electric. Es el autor del método OMT (Object Modeling Technique) en el año 1991. El método de Rumbaugh era el mas popular y robusto de la época en el ámbito académico y empresarial porque era de dominio público. Destacaba por su increíble capacidad para modelar datos y sistemas de información corporativos.
-
Ivar Jacobson: Era un ingeniero y científico sueco que trabajó durante décadas en el gigante de las telecomunicaciones Ericsson donde tuvo que diseñar sistemas telefónicos masivos que nunca podían fallar. Es el autor del método OOSE (Object Oriented Software Engineering). A Jacobson se le atribuye la creación de un invento revolucionario que cambió para siempre la informática: los casos de uso.
En 1994 Rumbaugh se unió a Rational y junto a Booch se dedicaron a la resolución del problema. Para octubre del años 1995 la empresa Rational adquiere la empresa de Jacobson; Objectory AB y con ésto ahora las tres mentes brillantes 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. Por un lado Booch hace su aporte a UML con la estructura de diseño y los diagramas de interacción. Se encargó de definir cómo se debían conectar las clases a nivel micro y nivel macro, aportando un enfoque muy técnico y muy robusto a la arquitectura de software. Por el lado de Rumbaugh se agregó el diagrama de clases actual. Rumbaugh era un maestro estructurando los datos, las relaciones (herencia, agregación) y las bases de datos. La forma limpia en la que hoy en día se dibujan rectángulos para representar clases y lineas para unirlas es en gran medida una herencia de su método OMT. Finalmente Jacobson aporta el enfoque centrado en el usuario. Mientra que Booch y Rumbaugh pensaban en términos de código y datos, Jacobson pensaba en las personas. Él agrega los diagramas de casos de uso a UML y es por él que hoy en día UML sirve tanto para programadores como para clientes.
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.
¿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.