¿Qué es UML y Cómo se Estructura?
UML (Lenguaje Unificado de Modelado) es un lenguaje estándar que sirve para escribir los planos del software. Puede utilizarse para visualizar, especificar, construir y documentar todos los artefactos que componen un sistema.
El lenguaje UML se compone de tres elementos básicos: los bloques de construcción, las reglas y algunos mecanismos comunes. Estos elementos interactúan entre sí para dar a UML el carácter de completitud y no ambigüedad.
Los Tres Pilares de UML
1. Bloques de Construcción
Los bloques de construcción son las piezas fundamentales de UML y se dividen en tres categorías principales, que se detallarán extensamente en las siguientes secciones:
- Elementos: Son las abstracciones de primer nivel. (Ver sección «1. Elementos de UML»)
- Relaciones: Unen a los elementos entre sí. (Ver sección «2. Relaciones en UML»)
- Diagramas: Son agrupaciones de elementos que ofrecen vistas específicas del sistema. (Ver sección «3. Diagramas UML»)
2. Reglas de UML
UML proporciona un conjunto de reglas que dictan las pautas al realizar asociaciones entre objetos para obtener modelos bien formados. Estas son reglas semánticas que afectan a:
- Los nombres de los elementos.
- El alcance de dichos nombres.
- La visibilidad de estos nombres por otros elementos.
- La integridad entre los elementos.
- La ejecución, es decir, la vista dinámica del sistema.
3. Mecanismos Comunes
UML proporciona una serie de mecanismos comunes que sirven para que cada persona o entidad adapte el lenguaje a sus necesidades, pero dentro de un marco ordenado y siguiendo ciertas reglas para que en el trasfondo de la adaptación no se pierda la semántica propia de UML.
1. Elementos de UML: Los Ladrillos del Modelado
Los elementos son las abstracciones fundamentales en UML. Se clasifican principalmente en estructurales, de comportamiento, de agrupación y de anotación.
1.1. Elementos Estructurales
Los elementos estructurales en UML, en su mayoría, son las partes estáticas del modelo y representan aspectos conceptuales o materiales del sistema.
1.1.1. Clases
Una clase describe un conjunto de objetos que comparten los mismos atributos, métodos, relaciones y semántica. Las clases implementan una o más interfaces.
1.1.2. Interfaz
Una interfaz es una agrupación de métodos u operaciones que especifican un servicio de una clase o componente, describiendo su comportamiento (completo o parcial) externamente visible. UML permite emplear un círculo para representar las interfaces (notación «lollipop»), aunque también es común usar un clasificador de tipo clase con el estereotipo <<interface>> o con el nombre en cursiva.
1.1.3. Colaboración
Una colaboración define una interacción y un conjunto de roles que los participantes (objetos o clasificadores) desempeñan para lograr un objetivo común. Describe una sociedad de elementos que cooperan para proporcionar un comportamiento mayor que la suma de los comportamientos individuales.
1.1.4. Casos de Uso
Un caso de uso describe un conjunto de secuencias de acciones que un sistema ejecuta para producir un resultado observable de valor para un actor particular. Se emplea para estructurar los aspectos de comportamiento de un modelo desde la perspectiva del usuario.
1.1.5. Clase Activa
Una clase activa es una clase cuyas instancias son objetos activos, es decir, objetos que poseen su propio hilo de control y pueden iniciar actividad concurrente. Se representa con líneas de contorno más gruesas que una clase normal.
1.1.6. Componentes
Un componente es una parte modular, física y reemplazable de un sistema que encapsula su contenido y cuya manifestación es sustituible dentro de su entorno. Agrupa un conjunto de interfaces, archivos de código fuente, clases, colaboraciones y proporciona la implementación de dichos elementos.
1.1.7. Nodos
Un nodo es un elemento físico que existe en tiempo de ejecución y representa un recurso computacional, generalmente con capacidad de memoria y procesamiento.
Estos siete tipos son los elementos estructurales básicos que se pueden incluir en un modelo UML.
1.2. Elementos de Comportamiento
Los elementos de comportamiento son las partes dinámicas de un modelo UML. Representan el comportamiento del sistema en el tiempo y en el espacio. Los principales son:
1.2.1. Interacción
Una interacción define un comportamiento que comprende un conjunto de mensajes intercambiados entre un conjunto de objetos (o roles) dentro de un contexto particular para cumplir un objetivo específico.
1.2.2. Máquinas de Estados
Una máquina de estados especifica la secuencia de estados por los que pasa un objeto o una interacción durante su vida en respuesta a eventos, junto con sus respuestas y acciones.
1.3. Elementos de Agrupación (Paquetes)
Los elementos de agrupación forman la parte organizativa de los modelos UML. El principal elemento de agrupación es el paquete, que es un mecanismo de propósito general para organizar elementos en grupos. Los elementos estructurales, los elementos de comportamiento e incluso otros paquetes se pueden incluir en un paquete.
1.4. Elementos de Anotación (Notas)
Los elementos de anotación son las partes explicativas de los modelos UML. La principal es la nota, que permite adjuntar comentarios o restricciones a cualquier elemento o conjunto de elementos del modelo.
2. Relaciones en UML: Conectando los Elementos
Existen cuatro tipos principales de relaciones entre los elementos de un modelo UML: dependencia, asociación, generalización y realización. Estas se describen a continuación:
2.1. Relaciones de Dependencia
Una relación de dependencia es una relación semántica entre dos elementos, en la que un cambio en uno (el elemento independiente o proveedor) puede afectar la semántica del otro (el elemento dependiente o cliente).
2.2. Relaciones de Asociación
Una relación de asociación es una relación estructural que describe un conjunto de enlaces, los cuales son conexiones entre objetos. Especifica que objetos de un tipo están conectados con objetos de otro tipo (o del mismo tipo). Puede incluir multiplicidad, roles y navegabilidad.
2.3. Relaciones de Generalización
Una relación de generalización es una relación entre un elemento más general (la superclase o padre) y un elemento más específico (la subclase o hijo). El hijo hereda características del padre y puede añadir o modificar comportamiento y estructura. Es el mecanismo de herencia.
2.4. Relaciones de Realización
Una relación de realización es una relación semántica entre clasificadores, donde un clasificador (el cliente o realizante) especifica un contrato que otro clasificador (el proveedor o realizado) garantiza cumplir. Se usa comúnmente entre interfaces y las clases que las implementan, o entre casos de uso y las colaboraciones que los realizan.
3. Diagramas UML: Visualizando las Perspectivas del Sistema
Los diagramas se utilizan para representar diferentes perspectivas de un sistema, de forma que un diagrama es una proyección del mismo. UML proporciona un amplio conjunto de diagramas que normalmente se utilizan en pequeños subconjuntos para poder representar las diversas vistas de la arquitectura de un sistema.
3.1. Diagramas de Clases
Los diagramas de clases muestran un conjunto de clases, interfaces, colaboraciones y sus relaciones. Son los diagramas más comunes en el modelado de sistemas orientados a objetos y cubren la vista de diseño estática o la vista de procesos estática (si incluyen clases activas).
3.2. Diagramas de Objetos
Los diagramas de objetos muestran un conjunto de objetos y sus relaciones en un momento específico. Son como «fotos instantáneas» de instancias de los elementos encontrados en los diagramas de clases. Cubren la vista de diseño estática o la vista de procesos estática desde la perspectiva de casos reales o prototípicos.
3.3. Diagramas de Casos de Uso
Los diagramas de casos de uso muestran un conjunto de casos de uso, los actores (usuarios o sistemas externos) y sus relaciones. Son diagramas fundamentales en el modelado y organización del comportamiento del sistema desde la perspectiva del usuario.
3.4. Diagramas de Estados (o Máquinas de Estados)
Los diagramas de estados (o diagramas de máquinas de estados) muestran una máquina de estados, compuesta por estados, transiciones, eventos y actividades. Cubren la vista dinámica de un sistema y modelan comportamientos reactivos basados en eventos, describiendo el ciclo de vida de los objetos.
3.5. Diagramas de Interacción: Secuencia y Colaboración/Comunicación
Tanto los diagramas de secuencia como los diagramas de colaboración (ahora llamados diagramas de comunicación en UML 2.x y versiones posteriores) son tipos de diagramas de interacción. Estos diagramas muestran un conjunto de objetos y las relaciones entre ellos, incluyendo los mensajes que pueden enviarse entre los objetos. Cubren la vista dinámica del sistema.
- Los diagramas de secuencia enfatizan el ordenamiento temporal de los mensajes.
- Los diagramas de colaboración/comunicación muestran la organización estructural de los objetos que envían y reciben mensajes, así como los enlaces entre ellos.
Los diagramas de secuencia se pueden convertir en diagramas de colaboración/comunicación sin pérdida de información, y viceversa.
Diagrama de Secuencia:
Diagrama de Colaboración/Comunicación:
3.7. Diagramas de Actividades
Los diagramas de actividades son un tipo especial de diagramas de estados que se centran en mostrar el flujo de actividades (trabajo realizado) dentro de un sistema o proceso. Cubren la parte dinámica de un sistema y se utilizan para modelar el funcionamiento de un sistema, resaltando el flujo de control entre objetos o acciones.
3.8. Diagramas de Componentes
Los diagramas de componentes muestran la organización y las dependencias entre un conjunto de componentes de software. Cubren la vista de la implementación estática y se relacionan con los diagramas de clases, ya que un componente suele encapsular una o más clases, interfaces o colaboraciones.
3.9. Diagramas de Despliegue
Los diagramas de despliegue representan la configuración de los nodos de procesamiento en tiempo de ejecución y los componentes (o artefactos) que residen en ellos. Muestran la vista de despliegue estática de una arquitectura y se relacionan con los diagramas de componentes ya que, por lo común, los nodos contienen uno o más componentes.
Arquitectura de Software y las Vistas de UML (Modelo 4+1)
El desarrollo de un sistema con gran cantidad de software requiere que éste sea visto desde diferentes perspectivas. Diferentes interesados (usuario final, analistas, desarrolladores, integradores, jefes de proyecto, etc.) se enfocan en diferentes actividades en distintos momentos del ciclo de vida del proyecto, lo que da lugar a las diversas vistas del proyecto, dependiendo de qué aspecto interese más en cada instante.
Definición de Arquitectura de Software
La arquitectura de software es el conjunto de decisiones significativas sobre:
- La organización del sistema de software.
- La selección de elementos estructurales y sus interfaces, a través de los cuales se constituye el sistema.
- El comportamiento, tal como se especifica en las colaboraciones entre esos elementos.
- La composición de estos elementos estructurales y de comportamiento en subsistemas progresivamente más grandes.
- El estilo arquitectónico que guía esta organización: los elementos estáticos y dinámicos, sus interfaces, sus colaboraciones y su composición.
Una arquitectura no debe centrarse únicamente en la estructura y el comportamiento, sino que debe abarcar temas como el uso, funcionalidad, rendimiento, capacidad de adaptación, reutilización, comprensibilidad, restricciones, compromisos entre alternativas, así como aspectos estéticos. Para ello, se sugiere un modelo de arquitectura que permita describir mejor los sistemas desde diferentes vistas, donde cada una de ellas es una proyección de la organización y la estructura centrada en un aspecto particular del sistema. Un enfoque popular para esto es el Modelo de Vistas 4+1 de Philippe Kruchten, que UML soporta bien.
Las Vistas Arquitectónicas en UML
1. Vista de Casos de Uso (o Vista de Escenarios)
La vista de casos de uso (a menudo llamada vista de escenarios o, a veces, relacionada con la vista lógica) comprende la descripción del comportamiento del sistema tal y como es percibido por los usuarios finales, analistas y encargados de las pruebas. Se utilizan los diagramas de casos de uso para capturar los aspectos estáticos de esta vista, mientras que los aspectos dinámicos son representados por diagramas de interacción (secuencia, comunicación), diagramas de estados y diagramas de actividades para ilustrar los escenarios.
2. Vista de Diseño (o Vista Lógica)
La vista de diseño (o vista lógica) comprende las clases, interfaces y colaboraciones que forman el vocabulario del problema y de la solución. Esta vista soporta principalmente los requisitos funcionales del sistema, es decir, los servicios que el sistema debe proporcionar. Los aspectos estáticos se representan mediante diagramas de clases y diagramas de objetos, y los aspectos dinámicos con diagramas de interacción, diagramas de estados y diagramas de actividades.
3. Vista de Procesos
La vista de procesos comprende los hilos y procesos que forman los mecanismos de sincronización y concurrencia del sistema, cubriendo el rendimiento, la escalabilidad y la fiabilidad del sistema. Con UML, los aspectos estáticos y dinámicos se representan de manera similar a la vista de diseño, pero con un énfasis particular en las clases activas (que representan hilos o procesos), y cómo los objetos interactúan a través de los límites de los procesos.
4. Vista de Implementación (o Vista de Desarrollo)
La vista de implementación (o vista de desarrollo) comprende los componentes y los archivos que un sistema utiliza para ensamblar y hacer disponible el sistema físico. Se ocupa principalmente de la gestión de configuraciones de las distintas versiones del sistema, la organización del código fuente y las dependencias entre módulos. Los aspectos estáticos se capturan con los diagramas de componentes, y los aspectos dinámicos (como los scripts de construcción o los flujos de integración) pueden ser modelados con diagramas de actividad o diagramas de interacción.
5. Vista de Despliegue (o Vista Física)
La vista de despliegue (o vista física) de un sistema contiene los nodos (hardware) que forman la topología sobre la que se ejecuta el sistema y los artefactos (software ejecutable) que se despliegan en esos nodos. Se preocupa principalmente de la distribución, entrega e instalación de las partes que constituyen el sistema. Los aspectos estáticos de esta vista se representan mediante los diagramas de despliegue, y los aspectos dinámicos (como el inicio del sistema o la migración de componentes) con diagramas de interacción, diagramas de estados o diagramas de actividades.