¿Qué es UML?

¿Qué es UML?

El Lenguaje Unificado de Modelado (UML) es una notación gráfica de estándar abierto para el desarrollo de sistemas propuesta por el Grupo de Gestión de Objetos. La notación se basa en trabajos de Booch, Rumbaugh y Jacobson. UML es un lenguaje de modelado para expresar y diseñar documentos, especialmente útil para el diseño orientado a objetos. El lenguaje puede utilizarse desde el diseño inicial general hasta el diseño detallado muy específico a lo largo de todo el ciclo de vida del desarrollo de software. La definición de UML se establece como sigue:

• Lenguaje Unificado de Modelado ( UML ) es un lenguaje gráfico para el modelado y desarrollo de sistemas de software. Los diagramas UML se convierten en un producto común de trabajo que los desarrolladores utilizan para discutir todas las fases del desarrollo de software, desde el análisis de requisitos, el diseño y la implementación. El objetivo aquí es modelar el sistema de software antes de construirlo.
• Cita: “El Lenguaje Unificado de Modelado (UML) es una familia de notaciones gráficas, respaldadas por un único meta-modelo, que ayudan a describir y diseñar sistemas de software, especialmente sistemas de software construidos utilizando el estilo orientado a objetos (OO).” [Martin Fowler – UML Distilled] pág. 1.

 ¿Por qué UML?

A medida que las arquitecturas de software crecen en tamaño y complejidad, también aumenta la necesidad de modelos de software. UML es el lenguaje de modelado dominante en la industria del software. Actualmente es un estándar de facto adoptado por el Grupo de Gestión de Objetos, el consorcio de software más grande del mundo. Es difícil encontrar un proyecto de software con más de 10 desarrolladores que no utilice UML de alguna manera para especificar su arquitectura.

Aquí hay algunos hechos adicionales sobre el uso de UML en nuestro proceso de desarrollo de software:

• El software está volviéndose cada vez más complejo: una versión bastante antigua de Windows XP tiene más de 40 millones de líneas de código.
• Un solo programador no puede gestionar esta cantidad de código en su totalidad.
• El código no es fácilmente comprensible para los desarrolladores que no lo escribieron.
• Necesitamos representaciones más simples para sistemas complejos: el modelado es una forma de manejar la complejidad.

¿Qué es un modelo?

• Un modelo es una abstracción de la cosa real, dejando de lado los detalles.
• “La colección de todos los elementos que describen su sistema, incluyendo sus conexiones entre sí, constituyen su modelo.” (Russ y Hamilton 12).

Cuando usamos UML para crear modelos de un sistema bajo desarrollo antes de codificar el software, estos representan el problema de forma simplificada. Proporcionan una estructura para resolver problemas. Ayudan a comprender cómo se puede proceder con el problema actual. También permiten experimentar con múltiples soluciones. Dado que los modelos se crean antes del desarrollo real del sistema, podemos comprender diferentes posibilidades, problemas, opciones, etc. Esto también conduce a una reducción de los costos de desarrollo. Dado que el tiempo no se desperdiciará en pruebas y errores, el producto estará listo en menos tiempo. Los modelos también ayudan a gestionar la complejidad del problema, por lo que la planificación del desarrollo, la asignación de recursos como máquinas, programadores, testers, puede hacerse fácilmente.

¿Qué NO es UML?

• UML no es una notación, sino un lenguaje.
• UML no es propiedad de nadie. Está abierto para ser usado por cualquiera que desee usarlo. No es propietario.
• UML no es un proceso ni un método.
• UML fomenta el uso de técnicas orientadas a objetos y ciclos de vida de desarrollo de software iterativos.
• UML no es difícil. Es amplio, pero no es necesario conocerlo por completo. Además, no es necesario usar ni comprender cada pequeño aspecto de él.
• UML no es costoso en tiempo. Si se utiliza adecuadamente, el uso de UML reduce los costos de desarrollo. Al mismo tiempo, ofrece la ventaja de una comprensión y comunicación más fáciles, mayor productividad y mejor calidad.
• UML no está limitado. Es lo suficientemente flexible como para permitir un vocabulario más nuevo (conceptos, palabras y términos), propiedades (información adicional sobre las palabras) y semántica (reglas del lenguaje) que son necesarios para un dominio específico.

Objetivo de UML

• Un lenguaje de modelado visual y no un lenguaje de programación visual. Aunque algunas herramientas de modelado tienen generadores de código y algunas pueden realizar la ingeniería inversa de modelos a partir de código.
• Se pretende crear diagramas que puedan apoyar el proceso de desarrollo de software, sin embargo, UML NO es un proceso ni un método de desarrollo de software. Por tanto, UML es independiente del proceso.
• Un lenguaje estándar para crear planos de software.
• Herramienta de comunicación.
• Un lenguaje para documentar requisitos, arquitectura, pruebas, planificación de proyectos, etc.
• Está destinado a sistemas de software, pero puede modelar otros sistemas.
• Está destinado a apoyar el proceso de desarrollo orientado a objetos.
• Puede capturar tanto las estructuras estáticas como el comportamiento dinámico de un sistema.
• Los diagramas UML pueden ayudar a los interesados a comprender, discutir y acordar los requisitos.
• Los diagramas UML pueden ayudar a abstraer procesos complejos hasta un nivel más fácil de comprender.
• Los diagramas UML ayudan a facilitar la resolución de problemas.

¿Qué proporciona un lenguaje de modelado?

• Elementos de modelo: Conceptos y semántica
• Notación: Representación visual de los elementos de modelo
• Guías: Consejos y sugerencias para usar los elementos en la notación

Breve historia

En la década de 1980, cuando comenzamos a modelar, había muchas metodologías diferentes. Y cada metodología tenía sus propias notaciones. El problema era que si diferentes personas usaban notaciones distintas, en algún momento alguien tenía que hacer una traducción. Muchas veces, un símbolo significaba una cosa en una notación y algo completamente diferente en otra notación. En 1991, todos empezaron a publicar libros. Grady Booch lanzó su primera edición. Ivar Jacobson publicó la suya, y Jim Rumbaugh lanzó su metodología OMT. Cada libro tenía sus fortalezas y sus debilidades. OMT era muy fuerte en análisis, pero más débil en diseño. La metodología Booch era más fuerte en diseño y más débil en análisis. Y Objectory de Ivar Jacobson era muy buena en experiencia de usuario, algo que ni Booch ni OMT consideraban realmente en aquel entonces. Booch y Jacobson fusionaron sus dos métodos en 1994, y luego Rumbaugh se unió en 1995. UML 1.1 se publicó en 1997 por parte de OMG, incluyendo aportes de otros, por ejemplo, Yourden. La versión UML v2.x es la más actual.

Fechas de lanzamiento

• 1995 – UML 0.8
• 1996 – UML 0.9 – Los Tres Amigos
• 1997 – OMG asume el control.
• 1997 – OMG UML 1.1
• 1998 – OMG UML 1.2
• 1999 – OMG UML 1.3
• 2001 – OMG UML 1.4
• 2003 – OMG UML 1.5
• 2003 – OMG UML 2.0 – Adoptado
• 2005 – OMG UML 2.0 – Final
• 2006 – OMG UML 2.1
• UML2.1.2(11/04/07) – Versión actual a partir del 27/05/08

La motivación de la unificación de métodos por parte de los “tres Amegos”

• Hecho de que los métodos individuales evolucionen hacia otros de forma independiente
• Unificación de semántica y notación para aportar estabilidad al mercado de diseño orientado a objetos
• Anticipación de que la unificación mejoraría los métodos individuales anteriores

Socios de UML

• Corporación Rational Software
• IBM
• Hewlett-Packard
• I-Logix
• ICON Computing
• Intellicorp
• MCI Systemhouse
• Microsoft
• ObjecTime
• Oracle
• Tecnología Platinum
• Taskon
• Texas Instruments/Sterling Software
• Unisys

Entrada de notación UML para diferentes métodos antes de la unificación

UML representa la unificación de las notaciones Booch, OMT y Objectory, así como las mejores ideas de varios otros metodólogos, como se muestra en la figura siguiente. Al unificar las notaciones utilizadas por estos métodos orientados a objetos, el Lenguaje Unificado de Modelado proporciona la base para una norma de facto en el dominio del análisis y diseño orientado a objetos, fundada en una amplia base de experiencia de usuarios.

El papel de la notación

La notación desempeña un papel importante en cualquier modelo: es el pegamento que une el proceso. La notación tiene tres funciones:

• Sirve como el lenguaje para comunicar decisiones que no son evidentes o que no pueden inferirse directamente del código.
• Proporciona semántica suficientemente rica para capturar todas las decisiones estratégicas y tácticas importantes.
• Ofrece una forma lo suficientemente concreta para que los humanos puedan razonar y para que las herramientas la manipulen.

El Lenguaje Unificado de Modelado (UML) proporciona una notación muy robusta, que evoluciona desde el análisis hasta el diseño. Algunos elementos de la notación (por ejemplo, clases, asociaciones, agregaciones, herencia) se introducen durante el análisis. Otros elementos de la notación (por ejemplo, indicadores de implementación de contención y propiedades) se introducen durante el diseño.

Beneficios de UML

UML puede aplicarse a diversosdominios de aplicación (por ejemplo, banca, finanzas, internet, aeroespacial, salud, etc.) Puede utilizarse con todos los principales objetos y componentes métodos de desarrollo de software y para diversos plataformas de implementación.

• Sabe exactamente lo que está obteniendo
• Tendrá costos de desarrollo más bajos
•  Su software se comportará como usted espera. Menos sorpresas
•  Se toman las decisiones correctas antes de que se le entregue código mal escrito. Menores costos totales
• Podemos desarrollar sistemas más eficientes en memoria y procesador
• Los costos de mantenimiento del sistema serán menores. Se producirá menos reaprendizaje
• Trabajar con un nuevo desarrollador será más fácil.
• La comunicación con programadores y contratistas externos será más eficiente.

Vistas UML 4 + 1

UML consta de las siguientes cuatro vistas del sistema en desarrollo (véase Fig. 3) [Eriksson & Penker, 1998; Kruchten, 2000]:

• Vista de casos de uso: muestra la funcionalidad del sistema tal como la perciben los actores externos; se describe mediante diagramas de casos de uso y ocasionalmente mediante diagramas de actividad.
• Vista lógica: muestra cómo se diseña esta funcionalidad dentro del sistema, en términos de su estructura estática y comportamiento dinámico; se describe mediante diagramas de clases y objetos (modelo estático) y diagramas de transición de estado, secuencia, colaboración y actividad (modelo dinámico)
• Vista de componentes: muestra la organización de los componentes de software; se describe mediante diagramas de componentes.
• Vista de despliegue: muestra la configuración física (despliegue) de los nodos de procesamiento en tiempo de ejecución dentro de computadoras y dispositivos, y los componentes, procesos y objetos que residen en ellos; se describe mediante diagramas de despliegue.
• Vista de proceso: muestra el aspecto concurrente del sistema en tiempo de ejecución, como tareas, hilos, procesos e interacciones, y aborda problemas de comunicación y sincronización de estos hilos; se describe mediante diagramas dinámicos (diagramas de transición de estado, secuencia, colaboración y actividad) y diagramas de implementación (diagramas de componentes y de despliegue).

Cada sistema consta de la estático y el dinámicomodelo. El modelo estático se representa en los diagramas de clases y objetos. Sin embargo, revela poco sobre el comportamiento del sistema. El comportamiento del sistema se captura gráficamente mediante escenarios (es decir, diagramas de casos de uso), diagramas de secuencia, diagramas de transición de estado y diagramas de actividad. Estos constituyen el modelo dinámico del sistema. El comportamiento del sistema es el comportamiento total de todos los objetos pertenecientes al sistema.

Si queremos mapear las cinco vistas anteriores a las fases del ciclo de vida iterativo de la figura 3, podríamos decir lo siguiente:

• Análisis Orientado a Objetos (OOA), que desarrolla un modelo de los requisitos de los usuarios desde la perspectiva del usuario, se mapea a la vista de caso de uso.
• Diseño Orientado a Objetos (OOD) añade detalles y decisiones de diseño (desde la perspectiva del desarrollador) al análisis y se mapea a la vista lógica.
• Finalmente, la implementación o programación orientada a objetos (OOP) se mapea a la vista de proceso, despliegue y componente.

Diagramas UML 2

UML tiene varios tipos diferentes de diagramas que pueden utilizarse para describir un modelo desde diferentes puntos de vista. Hay dos categorías amplias de diagramas y luego se dividen nuevamente en subcategorías:

• Diagramas estructurales – Eldiagramas estructuralesrepresentan el aspecto estático del sistema. Estos aspectos estáticos representan aquellas partes de un diagrama que forman la estructura principal y por tanto estable. Estas partes estáticas se representan mediante clases, interfaces, objetos, componentes y nodos.
• Diagramas comportamentales – Cualquier sistema puede tener dos aspectos, estático y dinámico. Por lo tanto, un modelo se considera completo cuando ambos aspectos se cubren completamente.
  Los diagramas comportamentales capturan básicamente el aspecto dinámico de un sistema. El aspecto dinámico puede describirse más a fondo como las partes cambiantes/móviles de un sistema.

Diagramas estructurales

• Diagrama de clases – diagrama de la estructura estática de las clases y interfaces del sistema y sus relaciones o asociaciones (incluyendo herencia, agregación y asociación), incluyendo las operaciones y atributos de las clases. Los modos de presentación son: Asociación, Herencia, Dependencia. Este es un diagrama muy común en UML.
• Diagrama de objetos – es un diagrama de la estructura estática de un sistema en un momento o situación específica (instantánea) que ilustra una relación en un sistema.
• Diagrama de componentes – es un diagrama que describe la organización y las dependencias de los componentes dentro del sistema.
• Diagrama de estructura compuesta – es un diagrama que explora instancias en tiempo de ejecución de instancias interconectadas que colaboran a través de enlaces de comunicación.
• Diagrama de paquetes – es un diagrama que muestra cómo un sistema se divide en agrupaciones lógicas y qué dependencias pueden existir entre estas agrupaciones.
• Diagrama de despliegue – es un diagrama que describe cómo las unidades físicas distribuibles (componentes de software desplegables, aplicaciones, servidores, aplicaciones, hardware, etc.) constituyen la arquitectura del sistema distribuido.

Diagramas comportamentales

• Diagrama de casos de uso – diagrama de los casos de uso (funciones/servicios de software) y el papel de los actores (usuarios – tanto humanos como sistemas). Este diagrama está desde la perspectiva del usuario.
• Diagrama de actividad – es un diagrama de la naturaleza dinámica de un sistema mediante la modelación del flujo de control de actividad a actividad. Representa cómo un sistema (por ejemplo: objeto/clase) responde a un evento interno. (nota: los eventos externos se describen mediante un Diagrama de estado). Para la modelación de procesos de negocio, puedes utilizar este diagrama para modelar la lógica de un caso de uso o regla de negocio.
• Diagrama de estado (también conocido como Diagrama de estado, Diagrama de máquina de estados) – es un diagrama de cómo un sistema (por ejemplo: objeto/clase) responde a un evento externo. (nota: los eventos internos se describen mediante un Diagrama de actividad).

Diagramas de tipo de interacción– interacciones de las partes organizativas del modelo.

• Diagrama de secuencia – es un diagrama de la interacción y el flujo de mensajes entre objetos y el orden relativo de tiempo de los mensajes
• Diagrama de comunicación(también conocido como Diagramas de colaboración de UML1) – es un diagrama de cómo los sistemas colaboran entre sí para realizar una tarea y las asociaciones que deben existir entre los sistemas. El diagrama de colaboración es el resultado de tomar el diagrama de secuencia y describir su interacción con el diagrama de clases. En resumen, este diagrama muestra el flujo de mensajes entre objetos y las asociaciones básicas (relaciones) entre clases
• Diagrama de tiempo – es un diagrama que explora el comportamiento de uno o más objetos durante un período de tiempo determinado.
• Diagrama de vista general de interacción – es un diagrama de la interacción y el control de flujo entre los diagramas de interacción (diagrama de secuencia, diagrama de comunicación, diagrama de tiempo, diagrama de vista general de interacción).

Perfil UML

El perfil UML no es exactamente un diagrama, sino un perfil para describir extensiones y subconjuntos de UML. Los subconjuntos se describen utilizando el Lenguaje de Restricción de Objetos (OCL). Las extensiones se crean definiendo estereotipos, que son etiquetas que pueden decorar cualquier elemento del modelo. Por ejemplo, podríamos etiquetar una clase como «persistente» y usar la etiqueta para identificar una clase cuyas instancias se almacenan más allá de la vida útil de la ejecución del sistema. Informalmente —y esto es ideológicamente incorrecto— un perfil es cualquier conjunto de extensiones y subconjuntos de UML, ya sea que se escriban usando estos mecanismos o no. Formalmente, un perfil es la definición de OCL y estereotipos que describen las reglas, que en UML 2 se capturan en un paquete.

Diagramas relacionados para el desarrollo de software

Entre las diferencias entre las metodologías de OOAD y la evolución de los estándares de UML, los nombres de los diagramas y sus funciones pueden evolucionar con el tiempo. Aquí hay algunos ejemplos de diagramas y/o productos de trabajo que podrían o no formar parte de UML1 o UML2, pero que podrían usarse en metodologías de OOAD:

• Diagrama de contexto del sistema
• Diagrama de relaciones entidad (similar al Diagrama de clases) con ERD conceptual, lógico y físico
• Análisis de robustez

Conclusión

Hemos examinado los orígenes y la definición de UML para proporcionar una comprensión simplificada de qué es y qué puede ofrecernos. También hemos analizado cómo podemos beneficiarnos de su uso en nuestro próximo proyecto de desarrollo y explorado brevemente las vistas arquitectónicas, modelos y tipos de diagramas disponibles en UML 2. UML no es un proceso, sino una notación visual estándar abierta para el desarrollo de sistemas intensivos en software. Los componentes necesarios para un proyecto exitoso requieren tres aspectos: una notación, un proceso y una herramienta:

Solo notación – puedes aprender una notación (por ejemplo, UML), pero si no sabes cómo usarla (proceso), probablemente fracasarás.

Proceso Solo – Es posible que tengas un gran proceso, pero si no puedes comunicar el proceso (notación), probablemente fracasarás. Y por último

Sin Soporte de Herramienta – si no puedes documentar eficazmente los artefactos de tu trabajo (herramienta), probablemente pierdas mucho tiempo y finalmente fracases.

Herramienta Automatizada de UML

Visual Paradigm es una herramienta automatizada que garantiza que tendrás éxito en tus proyectos de software con:

1. Edición de sintaxis sencilla para minimizar la necesidad de memorizar notación
2. Soporte para procesos y conjunto de herramientas de desarrollo de software ágiles y populares, y los más fáciles
3. Automatizado para agilizar cualquier tamaño de proyecto, informe de producto y artefacto en tiempo real

Recursos de UML

1. Guía completa sobre los 14 tipos de diagramas UML – Cybermedian
   • Esta guía ofrece una visión general de los 14 tipos de diagramas UML compatibles con la edición comunitaria de Visual Paradigm. Explica cómo los diagramas UML ayudan a visualizar sistemas intensivos en software y describe la funcionalidad proporcionada por cada tipo de diagrama. La guía también destaca la versatilidad de Visual Paradigm para apoyar diversos diagramas UML según las necesidades de modelado11.
2. Aprende modelado UML con las mejores herramientas gratuitas de UML (tanto en línea como de escritorio) – Cybermedian
   • Este artículo discute los beneficios de usar Visual Paradigm para el modelado UML, destacando su soporte para la última norma UML 2.x y su amplia gama de tipos de diagramas. También menciona las capacidades de integración de la herramienta con plataformas de desarrollo populares y su amplia adopción en el ámbito académico y la industria12.
3. Aprender por ejemplo: Diagramas de Máquina de Estados UML – Cybermedian
   • Este recurso se centra en los diagramas de máquina de estados UML y recomienda Visual Paradigm como una herramienta ideal para crear estos diagramas. Proporciona una visión detallada sobre cómo los diagramas de máquina de estados pueden modelar el comportamiento dinámico de los sistemas y destaca la integración de Visual Paradigm con herramientas y plataformas de desarrollo13.
4. Diagramas UML: Una guía completa – Cybermedian
   • Esta guía completa explica la importancia de los diagramas UML en el desarrollo de software y cómo Visual Paradigm apoya diversos tipos de diagramas UML. Cubre diagramas estructurales, comportamentales e interacción, proporcionando perspectivas sobre cómo se puede utilizar Visual Paradigm para crear modelos UML efectivos14.
5. Herramienta en línea gratuita de diagramas UML – Cybermedian
   • Este artículo presenta Visual Paradigm Online (VP Online) Edición Express, una herramienta en línea gratuita para crear diagramas UML. Destaca la facilidad de uso de la herramienta, la ausencia de limitaciones y su compatibilidad con diversos navegadores web, convirtiéndola en una opción accesible para la creación de diagramas UML personales y no comerciales15.
6. Comprender los diagramas de tiempo UML: Una guía completa – Cybermedian
   • Esta guía explica los diagramas de tiempo UML y su importancia en los sistemas en tiempo real. Discute cómo se puede utilizar Visual Paradigm para crear estos diagramas, centrándose en la representación visual de las restricciones de tiempo y duración dentro de un sistema16.
7. La guía completa sobre los diagramas UML 2.5 – Cybermedian
   • Esta guía ofrece una visión general de los diagramas UML 2.5 y destaca a Visual Paradigm como una elección principal para la modelización completa. Discute la versatilidad de la herramienta, su interfaz amigable y sus sólidas capacidades de generación de código, lo que la hace adecuada para profesionales de diversos sectores17.
8. Una guía completa sobre el diagrama de clases UML – Cybermedian
   • Esta guía se centra en los diagramas de clases UML y en cómo Visual Paradigm apoya su creación. Discute la amplia adopción de la herramienta en el ámbito académico y su uso en el diseño y análisis de sistemas y bases de datos. La guía también menciona la disponibilidad de ejemplos y plantillas para comenzar rápidamente con la modelización UML18.
9. Tutorial de diagrama de paquetes UML usando Visual Paradigm – Cybermedian
   • Este tutorial muestra los pasos para crear un diagrama de paquetes UML usando Visual Paradigm. Explica la importancia de los diagramas de paquetes para organizar sistemas grandes y proporciona una guía paso a paso para crearlos usando Visual Paradigm19.
10. La guía completa sobre modelado visual para el desarrollo de software ágil – Cybermedian
    • Esta guía discute el papel de las herramientas UML en el desarrollo de software ágil y destaca a Visual Paradigm como una elección popular. Explica cómo Visual Paradigm ofrece una interfaz amigable y funciones como validación, generación de código y ingeniería inversa para mejorar el proceso de modelado20.