Lenguaje Unificado de Modelado

UML

Es el lenguaje de modelado de sistemas de software más conocido y utilizado en la

actualidad; está respaldado por el OMG (Object Management Group) [de sus siglas en
inglés Grupo de Gestión de Objetos) es un consorcio dedicado al cuidado y el
establecimiento de diversos estándares de tecnologías orientadas a objetos, tales como
UML, XMI, CORBA. Es una organización sin ánimo de lucro que promueve el uso de
tecnología orientada a objetos mediante guías y especificaciones para las mismas.]

Es un lenguaje gráfico para visualizar, especificar, construir y documentar un sistema de

software. UML ofrece un estándar para describir un "plano" del sistema (modelo),
incluyendo aspectos conceptuales tales como procesos de negocios y funciones del
sistema, y aspectos concretos como expresiones de lenguajes de programación,
esquemas de bases de datos y componentes de software reutilizables.

Es importante resaltar que UML es un "lenguaje" para especificar y no para describir

métodos o procesos. Se utiliza para definir un sistema de software, 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 una gran variedad de formas para
dar soporte a una metodología de desarrollo de software (tal como el Proceso Unificado
Racional 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

(Lengua de Modelación Unificada), 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, sin embargo, la orientación a
objetos viene siendo un complemento perfecto de UML, pero no por eso se toma UML
sólo para lenguajes orientados a objetos

UML cuenta con varios tipos de diagramas, los cuales muestran diferentes aspectos de
las entidades representadas.

• Historia de UML

UML fue desarrollado en un esfuerzo para simplificar y consolidar el gran número de

métodos de desarrollo orientado a objetos que habían surgido.

Los métodos de desarrollo orientados a objetos.

Los métodos de desarrollo para los lenguajes de programación tradicionales, tales como
Cobol y Fortran, emergieron en los años 70 y llegaron a ser ampliamente difundidos en
los 80. Principalmente entre ellos estaba el Análisis estructurado y el diseño
estructurado [Yourdon-79] y sus variantes tales como diseño estructurado de tiempo real
[Ward-85] y otros. Estos métodos originalmente desarrollados por Constantine,
DeMarco, Mellor, Ward, Yourdon, y otros, alcanzaron cierta penetración en el área de
los grandes sistemas, especialmente para los proyectos contratados por el gobierno en
los campos aeroespacial y de defensa, en los cuales los contratistas insistieron en un
proceso de desarrollo organizado y en una amplia documentación del diseño e
implementación del sistema. Los resultados no fueron siempre tan buenos como se
esperaba – muchos sistemas de ingeniería de software asistidos por computador (CASE)
fueron poco mas que generadores de informes que extraían diseños después de que la
implantación estuviera terminada- pero los métodos incluían buenas ideas que fueron
usadas eficientemente en algunos casos en la construcción de grandes sistemas. La
aplicaciones comerciales fueron mas reacias a a adoptar grandes sistemas CASE y
métodos de desarrollo. La mayoría de los negocios desarrollaba su software
internamente según sus necesidades, sin la relación de enfrentamiento entre cliente y
contratista que caracterizaba los grandes proyectos del gobierno. Los sistemas
comerciales se percibían como mas simples, tanto si lo eran en verdad como si no, y por
tanto había menos necesidad de una revisión por parte de una organización externa.

El primer lenguaje que es generalmente reconocido como orientado a objetos es Simula

67, desarrollado en 1967. Este lenguaje nunca tuvo un significativo seguimiento, aunque
influyo notablemente en los desarrolladores de varios de los lenguajes orientados a
objetos posteriores. El movimiento de la orientación a objeto se convirtió en activo con
la amplia difusión de la disponibilidad de Smalltalk a principios de los 80, seguidos por
otros lenguajes orientados a objetos. El uso real de los lenguajes orientados fue limitado
al principio, pero la orientación a objetos atrajo mucho la obtención. Aproximadamente
5 años después de que Smalltalk llegara a ser conocido, fueron publicados los primeros
métodos de desarrollo orientado a objetos por Shlaer/Mellor y Coad/Yourdon.

Durante los siguientes cinco años, aparecieron muchos libros de metodologías

orientadas a objetos, cada uno con su propio conjunto de conceptos, definiciones,
notación, terminología y procesos. Algunos añadieron nuevos conceptos útiles, pero en
general hubo gran similitud entre los conceptos propuestos por los diferentes autores. En
general, surgió un núcleo de conceptos comunes, junto con una gran variedad de
conceptos aceptados por uno o dos autores pero no utilizados ampliamente. Incluso en el
núcleo de conceptos comunes, hay pequeñas discrepancias entre los métodos que hacían
una comparación detallada algo capciosa, especialmente para el lector ocasional.

Esfuerzo de Unificación

En 1996, el Object Management Group (OMG) publico una petición de propuestas para
un enfoque estándar sobre el modelado orientado a objetos. Los autores de UML
(Booch, Jacobson y Rumbaugh) empezaron a trabajar con metodologos y
desarrolladores de otras compañías, para generar una propuesta atractiva a los miembros
de OMG, así como también un lenguaje de modelado, que seria ampliamente aceptado
por los fabricantes de herramientas, metodologos, y desarrolladores, quienes serian los
usuarios eventuales. Empezaron también varios esfuerzos competitivos. Finalmente,
todas las propuestas se unieron final de UML que fueron sometidas a consideración del
OMG en septiembre de 1997. El producto final es una colaboración entre muchas
personas.

Estandarización
El lenguaje Unificado de Modelado fue adoptado unánimemente por los miembros de
OMG como estándar en noviembre de 1997. OMG asumió la responsabilidad de futuros
desarrollos en el estándar de UML.

En UML 2.0 hay 13 tipos diferentes de diagramas. Para comprenderlos de manera

concreta, a veces es útil categorizarlos jerárquicamente, como se muestra:

Los Diagramas de Estructura enfatizan en los elementos que deben existir en el

sistema modelado:

 Diagrama de clases

Un diagrama de clases es un tipo de diagrama estático que describe la estructura de un

sistema mostrando sus clases, atributos y las relaciones entre ellos. Los diagramas de
clases son utilizados durante el proceso de análisis y diseño de los sistemas, donde se
crea el diseño conceptual de la información que se manejará en el sistema, y los
componentes que se encargaran del funcionamiento y la relación entre uno y otro.

 Diagrama de componentes

Un diagrama de componentes representa la separación de un sistema de software en

componentes físicos (por ejemplo archivos, cabeceras, módulos, paquetes, etc.) y
muestra las dependencias entre estos componentes.

 Diagrama de objetos
Los diagramas de objetos utilizan un subconjunto de los elementos de un diagrama de
clase. Los diagramas de objetos no muestran la multiplicidad ni los roles, aunque su
notación es similar a los diagramas de clase. Una diferencia con los diagramas de clase
es que el compartimiento de arriba va en la forma, Nombre de objeto: Nombre de clase.
Por ejemplo, Miguel: Persona.

 Diagrama de despliegue

El Diagrama de Despliegue es un tipo de diagrama del Lenguaje Unificado de

Modelado que se utiliza para modelar el hardware utilizado en las implementaciones de
sistemas y las relaciones entre sus componentes. Los elementos usados por este tipo de
diagrama son nodos (representados como un prisma), componentes (representados como
una caja rectangular con dos protuberancias del lado izquierdo) y asociaciones.

 Diagrama de paquetes

Muestra como un sistema está dividido en agrupaciones lógicas mostrando las

dependencias entre esas agrupaciones. Dado que normalmente un paquete está pensado
como un directorio, los diagramas de paquetes suministran una descomposición de la
jerarquía lógica de un sistema.

Los Diagramas de Comportamiento enfatizan en lo que debe suceder en el sistema

modelado:

 Diagrama de actividades

Representa los flujos de trabajo paso a paso de negocio y operacionales de los

componentes en un sistema. Un Diagrama de Actividades muestra el flujo de control
general. En SysML el diagrama de Actividades ha sido extendido para indicar flujos
entre pasos que mueven elementos físicos (e.g., gasolina) o energía (e.g., presión). Los
cambios adicionales permiten al diagrama soportar mejor flujos de comportamiento y
datos continuos.

 Diagrama de casos de uso

Define una notación gráfica para representar casos de uso llamada modelo de casos de
uso. UML no define estándares para que el formato escrito describa los casos de uso, y
así mucha gente no entiende que esta notación gráfica define la naturaleza de un caso de
uso; sin embargo una notación gráfica puede solo dar una vista general simple de un
caso de uso o un conjunto de casos de uso. Los diagramas de casos de uso son a menudo
confundidos con los casos de uso. Mientras los dos conceptos están relacionados, los
casos de uso son mucho más detallados que los diagramas de casos de uso.

 Diagrama de estados
Se usan para representar gráficamente máquinas de estados finitos. Las Tablas de
Transiciones son otra posible representación. Hay muchas formas de diagramas de
estados que difieren levemente y tienen semánticas diferentes.

Los Diagramas de Interacción son un subtipo de diagramas de comportamiento, que

enfatiza sobre el flujo de control y de datos entre los elementos del sistema modelado:

 Diagrama de secuencia

Es uno de los diagramas más efectivos para modelar interacción entre objetos en un
sistema. Un diagrama de secuencia muestra la interacción de un conjunto de objetos en
una aplicación a través del tiempo y se modela para cada método de la clase. Mientras
que el diagrama de casos de uso permite el modelado de una vista business del
escenario, el diagrama de secuencia contiene detalles de implementación del escenario,
incluyendo los objetos y clases que se usan para implementar el escenario, y mensajes
pasados entre los objetos.

 Diagrama de colaboración

Esencialmente es un diagrama que muestra interacciones organizadas alrededor de los

roles. A diferencia de los diagramas de secuencia, los diagramas de colaboración
muestran explícitamente las relaciones de los roles. Por otra parte, un diagrama de
colaboración no muestra el tiempo como una dimensión aparte, por lo que resulta
necesario etiquetar con números de secuencia tanto la secuencia de mensajes como los
hilos concurrentes.

Un diagrama de colaboración es también un diagrama de clases que contiene roles de

clasificador y roles de asociación en lugar de sólo clasificadores y asociaciones.

 Diagrama de tiempos (UML 2.0)

Es una gráfica de formas de onda digitales que muestra la relación temporal entre varias
señales, y cómo varía cada señal en relación a las demás.

Un cronograma puede contener cualquier número de señales relacionadas entre sí.

El propósito primario del diagrama de tiempos es mostrar los cambios en el estado o la
condición de una línea de vida (representando una Instancia de un Clasificador o un Rol
de un clasificador) a lo largo del tiempo lineal. El uso más común es mostrar el cambio
de estado de un objeto a lo largo del tiempo, en respuesta a los eventos o estímulos
aceptados.