El lenguaje unificado de modelado (UML, por sus siglas en inglés, Unified Modeling

Language) es el lenguaje de modelado de sistemas de software más conocido y utilizado en la

actualidad; está respaldado por el Object Management Group (OMG).
Es un lenguaje gráfico para visualizar, especificar, construir y documentar un sistema. UML
ofrece un estándar para describir un "plano" del sistema (modelo), incluyendo aspectos
conceptuales tales como procesos, funciones del sistema, y aspectos concretos como
expresiones de lenguajes de programación, esquemas de bases de datos y compuestos
reciclados.
Es importante remarcar que UML es un "lenguaje de modelado" para especificar o para
describir métodos o procesos. Se utiliza para definir un sistema, para detallar los artefactos en
el sistema y para documentar y construir. En otras palabras, es el lenguaje en el que está
descrito el modelo.
Se puede aplicar en el desarrollo de software gran variedad de formas para dar soporte a una
metodología de desarrollo de software (tal como el Proceso Unificado Racional, Rational
Unified Process o RUP), pero no especifica en sí mismo qué metodología o proceso usar.
UML no puede compararse con la programación estructurada, pues UML significa Lenguaje
Unificado de Modelado, no es programación, solo se diagrama la realidad de una utilización en
un requerimiento. Mientras que programación estructurada es una forma de programar como
lo es la orientación a objetos, la programación orientada a objetos viene siendo un
complemento perfecto de UML, pero no por eso se toma UML solo para lenguajes orientados
a objetos.
UML cuenta con varios tipos de diagramas, los cuales muestran diferentes aspectos de las
entidades representadas.

Estandarización de UML[editar]
Desde el año 2004, UML es un estándar aprobado por la ISO como ISO/IEC 19501:2005
Information technology — Open Distributed Processing — Unified Modeling Language (UML)
Versión 1.4.2.
En el año 2012 se actualizó la norma a la última versión definitiva disponible en ese momento,
la 2.4.1, dando lugar a las normas ISO/IEC 19505-1

Historia[editar]
Antes de UML 1.x[editar]
Después de que la Rational Software Corporation contratara a James Rumbaugh de General
Electric, en 1994, la compañía se convirtió en la fuente de los dos esquemas de modelado
orientado a objetos más populares de la época: Object-Modeling Technique (OMT) de
Rumbaugh, que era mejor para análisis orientado a objetos, y el Método Booch (de Grady
Booch) que era mejor para el diseño orientado a objetos. Poco después se les unió Ivar
Jacobson, el creador del método de ingeniería de software orientado a objetos. Jacobson se
unió a Rational, en 1995, después de que su compañía Objectory AB fuera comprada por
Rational. Los tres metodologistas eran conocidos como los Tres Amigos, porque se sabía de
sus constantes discusiones sobre las prácticas metodológicas.
En 1996 Rational concluyó que la abundancia de lenguajes de modelado estaba alentando la
adopción de la tecnología de objetos, y para orientarse hacia un método unificado, encargaron
a los Tres Amigos que desarrollaran un "lenguaje unificado de modelado" abierto. Se consultó
con representantes de compañías competidoras en el área de la tecnología de objetos durante
la OOPSLA '96; eligieron "cajas" para representar clases en lugar de la notación de Booch que
utilizaba símbolos de "nubes".
Bajo la dirección técnica de los Tres Amigos (Rumbaugh, Jacobson y Booch) fue organizado
un consorcio internacional llamado UML Partners en 1996 para completar las especificaciones
del UML, y para proponerlo como una respuesta al OMG RFP. El borrador de la especificación
UML 1.0 de UML Partners fue propuesto a la OMG en enero de 1997. Durante el mismo mes,
la UML Partners formó una Fuerza de Tarea Semántica, encabezada por Cris Kobryn y
administrada por Ed Eykholt, para finalizar las semánticas de la especificación y para
integrarla con otros esfuerzos de estandarización. El resultado de este trabajo, el UML 1.1, fue
presentado ante la OMG en agosto de 1997 y adoptado por la OMG en noviembre de 1997.

UML 1.x[editar]
Como notación de modelado, la influencia de la OMT domina UML (por ejemplo, el uso de
rectángulos para clases y objetos). Aunque se quitó la notación de "nubes" de Booch, sí se
adoptó la capacidad de Booch para especificar detalles de diseño en los niveles inferiores. La
notación de "Casos de Uso" del Objectory y la notación de componentes de Booch fueron
integrados al resto de la notación, pero la integración semántica era relativamente débil en
UML 1.1, y no se arregló realmente hasta la revisión mayor de UML 2.0.
Conceptos de muchos otros métodos orientados a objetos (MOO) fueron integrados
superficialmente en UML con el propósito de hacerlo compatible con todos los MOO. Además,
el grupo tomó en cuenta muchos otros métodos de la época, con el objetivo de asegurar
amplia cobertura en el dominio de los sistemas en tiempo real. Como resultado, UML es útil en
una gran variedad de problemas de ingeniería, desde procesos sencillos y aplicaciones de
solamente un usuario a sistemas concurrentes y distribuidos.

UML 2.x[editar]
UML ha madurado considerablemente desde UML 1.1, varias revisiones menores (UML 1.3,
1.4 y 1.5) han corregido defectos y errores de la primera versión de UML. A estas le ha
seguido la revisión mayor UML 2.0 que fue adoptada por el OMG en 2005.
Aunque UML 2.1 nunca fue lanzado como una especificación formal, las versiones 2.1.1 y
2.1.2, aparecieron en 2007, seguidas por UML 2.2 en febrero de 2009. UML 2.3 fue lanzado
oficialmente en mayo de 2010. UML 2.4.1 fue lanzado oficialmente en agosto de 2011. UML
2.5.1 fue lanzado en octubre de 2012 como una versión "En proceso" que fue formalmente
liberada en junio de 2015.

Tipos de diagramas en UML 2.5[editar]

Existen dos clases principales de tipos de diagramas: diagramas estructurales y diagramas
de comportamiento. Estos últimos incluyen varios que representan diferentes aspectos de
las interacciones. Estos diagramas pueden ser categorizados jerárquicamente como se
muestra en el siguiente diagrama de clases:
Estructurales[editar]
Muestran la estructura estática de los objetos en un sistema.

 Diagrama de clases Los diagramas de clase son, sin duda, el tipo de diagrama UML más
utilizado. Es el bloque de construcción principal de cualquier solución orientada a objetos.
Muestra las clases en un sistema, atributos y operaciones de cada clase y la relación
entre cada clase. En la mayoría de las herramientas de modelado, una clase tiene tres
partes, nombre en la parte superior, atributos en el centro y operaciones o métodos en la
parte inferior. En sistemas grandes con muchas clases relacionadas, las clases se
agrupan para crear diagramas de clases. Las Diferentes relaciones entre las clases se
muestran por diferentes tipos de flechas.
 Diagrama de componentes Un diagrama de componentes muestra la relación estructural
de los componentes de un sistema de software. Estos se utilizan principalmente cuando
se trabaja con sistemas complejos que tienen muchos componentes. Los componentes se
comunican entre sí mediante interfaces. Las interfaces se enlazan mediante conectores.
 Diagrama de despliegue Un diagrama de despliegue muestra el hardware de su sistema y
el software de ese hardware. Los diagramas de implementación son útiles cuando la
solución de software se despliega en varios equipos, cada uno con una configuración
única.
 Diagrama de objetos Los diagramas de objetos, a veces denominados diagramas de
instancia, son muy similares a los diagramas de clases. Al igual que los diagramas de
clases, también muestran la relación entre los objetos, pero usan ejemplos del mundo
real. Se utilizan para mostrar cómo se verá un sistema en un momento dado. Debido a
que hay datos disponibles en los objetos, a menudo se utilizan para explicar relaciones
complejas entre objetos.
 Diagrama de paquetes Como su nombre indica, un diagrama de paquetes muestra las
dependencias entre diferentes paquetes de un sistema.
 Diagrama de perfiles El diagrama de perfil es un nuevo tipo de diagrama introducido en
UML 2. Este es un tipo de diagrama que se utiliza muy raramente en cualquier
especificación.
 Diagrama de estructura compuesta Los diagramas de estructura compuesta se utilizan
para mostrar la estructura interna de una clase.
De comportamiento[editar]
Muestran el comportamiento dinámico de los objetos en el sistema.

 Diagrama de actividades Los diagramas de actividad representan los flujos de trabajo de

forma gráfica. Pueden utilizarse para describir el flujo de trabajo empresarial o el flujo de
trabajo operativo de cualquier componente de un sistema. A veces, los diagramas de
actividad se utilizan como una alternativa a los diagramas de máquina del estado.
 Diagrama de casos de uso Como el tipo de diagrama de diagramas UML más conocido,
los diagramas de casos de uso ofrecen una visión general de los actores involucrados en
un sistema, las diferentes funciones que necesitan esos actores y cómo interactúan estas
diferentes funciones. Es un gran punto de partida para cualquier discusión del proyecto, ya
que se pueden identificar fácilmente los principales actores involucrados y los principales
procesos del sistema.
 Diagrama de máquina de estados Los diagramas de máquina de estado son similares a
los diagramas de actividad, aunque las anotaciones y el uso cambian un poco. En algún
momento se conocen como diagramas de estados o diagramas de diagramas de estado
también. Estos son muy útiles para describir el comportamiento de los objetos que actúan
de manera diferente de acuerdo con el estado en que se encuentran en el momento.
 Diagrama de interacción. Los diagramas de interacción incluyen distintos tipos de
diagramas:
o Diagrama de secuencia Los diagramas de secuencia en UML muestran cómo los
objetos interactúan entre sí y el orden en que se producen esas interacciones. Es
importante tener en cuenta que muestran las interacciones para un escenario en
particular. Los procesos se representan verticalmente y las interacciones se muestran
como flechas. Los diagramas de secuencia de UML forman parte de un modelo UML y
solo existen dentro de los proyectos de modelado UML.
o Diagrama de comunicación El diagrama de comunicación se llamó diagrama de
colaboración en UML 1. Es similar a los diagramas de secuencia, pero el foco está en
los mensajes pasados entre objetos.
o Diagrama de tiempos Los diagramas de sincronización son muy similares a los
diagramas de secuencia. Representan el comportamiento de los objetos en un marco
de tiempo dado. Si es solo un objeto, el diagrama es directo, pero si hay más de un
objeto involucrado, también se pueden usar para mostrar interacciones de objetos
durante ese período de tiempo.
o Diagrama global de interacciones Los diagramas generales o globales de interacción
son muy similares a los diagramas de actividad. Mientras que los diagramas de
actividad muestran una secuencia de procesos, los diagramas de interacción
muestran una secuencia de diagramas de interacción. En términos simples, pueden
llamarse una colección de diagramas de interacción y el orden en que suceden. Como
se mencionó anteriormente, hay siete tipos de diagramas de interacción, por lo que
cualquiera de ellos puede ser un nodo en un diagrama de vista general de interacción.
¿Qué es UML?
El Lenguaje Unificado de Modelado (UML) fue creado para forjar un lenguaje de
modelado visual común y semántica y sintácticamente rico para la arquitectura, el
diseño y la implementación de sistemas de software complejos, tanto en estructura
como en comportamiento. UML tiene aplicaciones más allá del desarrollo de software,
p. ej., en el flujo de procesos en la fabricación.

Es comparable a los planos usados en otros campos y consiste en diferentes tipos de

diagramas. En general, los diagramas UML describen los límites, la estructura y el
comportamiento del sistema y los objetos que contiene.

UML no es un lenguaje de programación, pero existen herramientas que se pueden

usar para generar código en diversos lenguajes usando los diagramas UML. UML
guarda una relación directa con el análisis y el diseño orientados a objetos.

UML y su función en el modelado y diseño orientados

a objetos
Hay muchos paradigmas o modelos para la resolución de problemas en la informática,
que es el estudio de algoritmos y datos. Hay cuatro categorías de modelos para la
resolución de problemas: lenguajes imperativos, funcionales, declarativos y
orientados a objetos (OOP). En los lenguajes orientados a objetos, los algoritmos se
expresan definiendo 'objetos' y haciendo que los objetos interactúen entre sí. Esos
objetos son cosas que deben ser manipuladas y existen en el mundo real. Pueden ser
edificios, artefactos sobre un escritorio o seres humanos.

Los lenguajes orientados a objetos dominan el mundo de la programación porque

modelan los objetos del mundo real. UML es una combinación de varias notaciones
orientadas a objetos: diseño orientado a objetos, técnica de modelado de objetos e
ingeniería de software orientada a objetos.

UML usa las fortalezas de estos tres enfoques para presentar una metodología más
uniforme que sea más sencilla de usar. UML representa buenas prácticas para la
construcción y documentación de diferentes aspectos del modelado de sistemas de
software y de negocios.

La historia y los orígenes de UML

"The Three Amigos" (los tres amigos) de la ingeniería de software, como se los
conocía, habían desarrollado otras metodologías. Se asociaron para brindar claridad a
los programadores creando nuevos estándares. La colaboración entre Grady, Booch y
Rumbaugh fortaleció los tres métodos y mejoró el producto final.
Los esfuerzos de estos pensadores derivaron en la publicación de los documentos
UML 0.9 y 0.91 en 1996. Pronto se hizo evidente que varias organizaciones, incluidas
Microsoft, Oracle e IBM, consideraron que UML era esencial para su propio desarrollo
de negocios. Ellos, junto con muchas otras personas y compañías, establecieron los
recursos necesarios para desarrollar un lenguaje de modelado hecho y derecho. "Los
tres amigos" publicaron la Guía del usuario para el Lenguaje Unificado de Modelado
en 1999, y una actualización que incluye información sobre UML 2.0 en la segunda
edición de 2005.

OMG: Tiene un significado diferente

Según su sitio web, el Object Management Group® (OMG®) es un consorcio
internacional sin fines de lucro y de membresía abierta para estándares tecnológicos,
fundado en 1989. Los estándares de OMG son promovidos por proveedores, usuarios
finales, instituciones académicas y agencias gubernamentales. Los grupos de trabajo
de OMG desarrollan estándares de integración empresarial para una amplia gama de
tecnologías y una gama incluso más amplia de industrias. Los estándares de modelado
de OMG, incluidos UML y Model Driven Architecture® (MDA®), permiten un eficaz
diseño visual, ejecución y mantenimiento de software y otros procesos.

OMG supervisa la definición y el mantenimiento de las especificaciones de UML. Esta

supervisión ofrece a los ingenieros y programadores la capacidad de usar un lenguaje
para muchos propósitos durante todas las etapas del ciclo de vida del software en
sistemas de cualquier tamaño.

La finalidad de UML según OMG

El OMG define los propósitos de UML de la siguiente manera:

 Brindar a arquitectos de sistemas, ingenieros y desarrolladores de software las

herramientas para el análisis, el diseño y la implementación de sistemas
basados en software, así como para el modelado de procesos de negocios y
similares.
 Hacer progresar el estado de la industria permitiendo la interoperabilidad de
herramientas de modelado visual de objetos. No obstante, para habilitar un
intercambio significativo de información de modelos entre herramientas, se
requiere de un acuerdo con respecto a la semántica y notación.

UML cumple con los siguientes requerimientos:

 Establecer una definición formal de un metamodelo común basado en el

estándar MOF (Meta-Object Facility) que especifique la sintaxis abstracta del
UML. La sintaxis abstracta define el conjunto de conceptos de modelado UML,
sus atributos y sus relaciones, así como las reglas de combinación de estos
conceptos para construir modelos UML parciales o completos.
  Brindar una explicación detallada de la semántica de cada concepto de
modelado UML. La semántica define, de manera independiente a la tecnología,
cómo los conceptos UML se habrán de desarrollar por las computadoras.
 Especificar los elementos de notación de lectura humana para representar los
conceptos individuales de modelado UML, así como las reglas para combinarlos
en una variedad de diferentes tipos de diagramas que corresponden a
diferentes aspectos de los sistemas modelados.
 Definir formas que permitan hacer que las herramientas UML cumplan con
esta especificación. Esto se apoya (en una especificación independiente) con
una especificación basada en XML de formatos de intercambio de modelos
correspondientes (XMI) que deben ser concretados por herramientas
compatibles.

UML y el modelado de datos

El UML es popular entre programadores, pero no suele ser usado por desarrolladores
de bases de datos. Una razón es sencillamente que los creadores de UML no se
enfocaron en las bases de datos. A pesar de ello, el UML es efectivo para el modelado
de alto nivel de datos conceptuales y se puede usar en diferentes tipos de diagramas
UML. Puedes encontrar información sobre la multidimensionalidad de un modelo de
clases orientado a objetos en una base de datos relacional en este artículo
sobre Modelado de bases de datos en UML.

Tipos de diagramas UML

UML usa elementos y los asocia de diferentes formas para formar diagramas que
representan aspectos estáticos o estructurales de un sistema, y diagramas de
comportamiento, que captan los aspectos dinámicos de un sistema.

Diagramas UML estructurales

 Diagrama de clases El diagrama UML más comúnmente usado, y la base

principal de toda solución orientada a objetos. Las clases dentro de un sistema,
atributos y operaciones, y la relación entre cada clase. Las clases se agrupan
para crear diagramas de clases al crear diagramas de sistemas grandes.
 Diagrama de componentes Muestra la relación estructural de los elementos
del sistema de software, muy frecuentemente empleados al trabajar con
sistemas complejos con componentes múltiples. Los componentes se
comunican por medio de interfaces.
 Diagrama de estructura compuesta Los diagramas de estructura compuesta
se usan para mostrar la estructura interna de una clase.
 Diagrama de implementación Ilustra el hardware del sistema y su software.
Útil cuando se implementa una solución de software en múltiples máquinas
con configuraciones únicas.
  Diagrama de objetos Muestra la relación entre objetos por medio de ejemplos
del mundo real e ilustra cómo se verá un sistema en un momento dado. Dado
que los datos están disponibles dentro de los objetos, estos pueden usarse para
clarificar relaciones entre objetos.
 Diagrama de paquetes Hay dos tipos especiales de dependencias que se
definen entre paquetes: la importación de paquetes y la fusión de paquetes. Los
paquetes pueden representar los diferentes niveles de un sistema para revelar
la arquitectura. Se pueden marcar las dependencias de paquetes para mostrar
el mecanismo de comunicación entre niveles.

Diagramas UML de comportamiento

 Diagramas de actividades Flujos de trabajo de negocios u operativos

representados gráficamente para mostrar la actividad de alguna parte o
componente del sistema. Los diagramas de actividades se usan como una
alternativa a los diagramas de máquina de estados.
 Diagrama de comunicación Similar a los diagramas de secuencia, pero el
enfoque está en los mensajes que se pasan entre objetos. La misma
información se puede representar usando un diagrama de secuencia y objetos
diferentes.
 Diagrama de panorama de interacciones Hay siete tipos de diagramas de
interacciones. Este diagrama muestra la secuencia en la cual actúan.
 Diagrama de secuencia Muestra cómo los objetos interactúan entre sí y el
orden de la ocurrencia. Representan interacciones para un escenario concreto.
 Diagrama de máquina de estados Similar a los diagramas de actividades,
describen el comportamiento de objetos que se comportan de diversas formas
en su estado actual.
 Diagrama de temporización Al igual que en los diagramas de secuencia, se
representa el comportamiento de los objetos en un período de tiempo dado. Si
hay un solo objeto, el diagrama es simple. Si hay más de un objeto, las
interacciones de los objetos se muestran durante ese período de tiempo
particular.
 Diagrama de caso de uso Representa una funcionalidad particular de un
sistema. Se crea para ilustrar cómo se relacionan las funcionalidades con sus
controladores (actores) internos/externos.