Historia de UML

El lenguaje UML comenzó a gestarse en octubre de 1994, cuando Rumbaugh se unió a la compañía Rational
fundada por Booch (dos reputados investigadores en el área de metodología del software).
El objetivo de ambos era unificar dos métodos que habían desarrollado: el método Booch y el OMT (Object Modelling
Tool ). El primer borrador apareció en octubre de 1995. En esa misma época otro reputado investigador, Jacobson,
se unió a Rational y se incluyeron ideas suyas. Estas tres personas son conocidas como los “tres amigos”. Además,
este lenguaje se abrió a la colaboración de otras empresas para que aportaran sus ideas. Todas estas
colaboraciones condujeron a la definición de la primera versión de UML.

Es un lenguaje de modelado visual que se usa para especificar, visualizar, construir y documentar artefactos de un
sistema de software. Se usa para entender, diseñar, configurar, mantener y controlar la información sobre los
sistemas a construir.
UML capta la información sobre la estructura estática y el comportamiento dinámico de un sistema. Un sistema se
modela como una colección de objetos discretos que interactúan para realizar un trabajo que finalmente beneficia a
un usuario externo.
El lenguaje de modelado pretende unificar la experiencia pasada sobre técnicas de modelado e incorporar las
mejores prácticas actuales en un acercamiento estándar.
UML no es un lenguaje de programación. Las herramientas pueden ofrecer generadores de código de UML para una
gran variedad de lenguaje de programación, así como construir modelos por ingeniería inversa a partir de programas
existentes.

La notación UML se deriva y unifica las tres metodologías de análisis y diseños más extendidas.
Metodología de Grady Booch para la descripción de conjuntos de objetos y sus relaciones.
Técnica de modelado orientada a objetos de James Rumbaugh (OMT: Object - Modelling Technique).
Aproximación de Ivar Jacobson (OOSE: Object- Oriented Software Engineering) mediante la metodología de casos
de uso (use case).
El desarrollo de UML comenzó a finales de 1994 cuando Grady Booch y Jim Rumbaugh de Rational Software
Corporation empezaron a unificar sus métodos. A finales de 1995, Ivar Jacob son y su compañía Objectory se
incorporaron a Rational en su unificación, aportando el método OOSE.

De las tres metodologías de partida, las de Bco. y Rumbaugh pueden ser descritas como centradas en objetos, ya
que sus aproximaciones se enfocan hacia el modelado de los objetos que componen el sistema, su relación y
colaboración.
Por otro lado, la metodología de Jacobson es más centrada a usuario, ya que todo en su método se deriva de los
escenarios de uso. UML se ha ido fomentando y aceptando como estándar desde el OMG, que es también el origen
de CORBA, el estándar líder en la industria para la programación de objetos distribuidos.

En 1997 UML 1.1 fue aprobada por la OMG convirtiéndose en la notación estándar de facto para el análisis y el
diseño orientado a objetos.
UML es el primer método en publicar un meta-modelo en su propia notación, incluyendo la notación para la mayoría
de la información de requisitos, análisis y diseño. Se trata pues de un meta-modelo auto-referencial (cualquier
lenguaje de modelado de propósito general debería ser capaz de modelarse a sí mismo).

Objetivos

Durante el desarrollo del UML sus autores tuvieron en cuenta:

Proporcionar una notación y semánticas suficientes para poder alcanzar una gran cantidad de aspectos del
modelado contemporáneo de una forma directa y económica.
Proporcionar las semánticas suficientes para alcanzar aspectos del modelado que son de esperar en un futuro, como
por ejemplo aspectos relacionados con la tecnología de componentes, el cómputo distribuido, etc.
Proporcionar mecanismos de extensión de forma que proyectos concretos puedan extender el meta-modelo a un
coste bajo.
Proporcionar mecanismos de extensión de forma que aproximaciones de modelado futuras podrían desarrollarse
encima del UML.
Permitir el intercambio del modelos entre una gran variedad de herramientas.
Proporcionar semánticas suficientes para especificar las interfaces a bibliotecas para la comparición y el
almacenamiento de componentes del modelo.

Ser tan simple como sea posible pero manteniendo la capacidad de modelar toda la gama de sistemas que se
necesita construir.
UML es un lenguaje de modelado de propósito general que pueden usar todos los modeladores.
UML no pretende ser un método de desarrollo completo.
Debe ser un lenguaje universal, como cualquier lenguaje de propósito general.
Imponer un estándar mundial.

Mediante el fomento del uso de UML OMG pretende alcanzar los siguientes objetivos:
Proporcionar a los usuarios un lenguaje de modelado visual expresivo y utilizable para el desarrollo e intercambio de
modelos significativos.
Proporcionar mecanismos de extensión y especialización.
Ser independiente del proceso de desarrollo y de los lenguajes de programación.
Proporcionar una base formal para entender el lenguaje de modelado.
Fomentar el crecimiento del mercado de las herramientas OO.
Soportar conceptos de desarrollo de alto nivel como pueden ser colaboraciones, frameworks, patterns, y
componentes.
Integrar las mejores prácticas utilizadas hasta el momento.

El UML debe entenderse como un estándar para modelado y no como un estándar de proceso software. Aunque
UML debe ser aplicado en el contexto de un proceso, la experiencia ha mostrado que organizaciones diferentes y
dominios del problema diferentes requieren diferentes procesos. Por ello se han centrado los esfuerzos en un meta-
modelo común (que unifica las semánticas) y una notación común que proporcione una representación de esas
semánticas. De todas formas, los autores de UML fomentan un proceso guiado por casos de uso, centrado en la
arquitectura, iterativo e incremental. Bajo estas líneas genéricas proponen el proceso software definido en una de las
extensiones del UML (Objectory Extension for Software Enginnering) , pero en general el proceso software es
fuertemente dependiente de la organización y del dominio de aplicación

Los conceptos y modelos de UML pueden agruparse en las siguientes áreas conceptuales:

Estructura estática:

Cualquier modelo preciso debe primero definir su universo, esto es, los conceptos clave de la aplicación, sus
propiedades internas, y las relaciones entre cada una de ellas. Este conjunto de construcciones es la estructura
estática. Los conceptos de la aplicación son modelados como clases, cada una de las cuales describe un conjunto
de objetos que almacenan información y se comunican para implementar un comportamiento. La información que
almacena es modelada como atributos; La estructura estática se expresa con diagramas de clases y puede usarse
para generar la mayoría de las declaraciones de estructuras de datos en un programa.

Comportamiento dinámico:

Hay dos formas de modelar el comportamiento, una es la historia de la vida de un objeto y la forma como interactúa
con el resto del mundo y la otra es por los patrones de comunicación de un conjunto de objetos conectados, es decir
la forma en que interactúan entre sí. La visión de un objeto aislado es una maquina de estados, muestra la forma en
que el objeto responde a los eventos en función de su estado actual. La visión de la interacción de los objetos se
representa con los enlaces entre objetos junto con el flujo de mensajes y los enlaces entre ellos. Este punto de vista
unifica la estructura de los datos, el control de flujo y el flujo de datos.

Construcciones de implementación:
Los modelos UML tienen significado para el análisis lógico y para la implementación física. Un componente es una
parte física reemplazable de un sistema y es capaz de responder a las peticiones descritas por un conjunto de
interfaces. Un nodo es un recurso computacional que define una localización durante la ejecución de un sistema.
Puede contener componentes y objetos.

Mecanismos de extensión:
UML tiene una limitada capacidad de extensión pero que es suficiente para la mayoría de las extensiones que
requiere el día a día sin la necesidad de un cambio en el lenguaje básico. Un estereotipo es una nueva clase de
elemento de modelado con la misma estructura que un elemento existente pero con restricciones adicionales.

Organización del modelo:

La información del modelo debe ser dividida en piezas coherentes, para que los equipos puedan trabajar en las
diferentes partes de forma concurrente. El conocimiento humano requiere que se organice el contenido del modelo
en paquetes de tamaño modesto. Los paquetes son unidades organizativas, jerárquicas y de propósito general de
los modelos de UML. Pueden usarse para almacenamiento, control de acceso, gestión de la configuración y
construcción de bibliotecas que contengan fragmentos de código reutilizable.

Elementos de anotación
Los elementos de anotación son las partes explicativas de los modelos UML. Son comentarios que se pueden aplicar
para describir, clasificar y hacer observaciones sobre cualquier elemento de un modelo.
El tipo principal de anotación es la nota que simplemente es un símbolo para mostrar restricciones y comentarios
junto a un elemento o un conjunto de elementos

Relaciones
Existen cuatro tipos de relaciones entre los elementos de un modelo UML. Dependencia, asociación, generalización
y realización, estas se describen a continuación

Dependencia
Es una relación semántica entre dos elementos en la cual un cambio a un elemento (el elemento
independiente) puede afectar a la semántica del otro elemento (elemento dependiente). Se representa como una
línea discontinua, posiblemente dirigida, que a veces incluye una etiqueta.

Asociación
Es una relación estructural que describe un conjunto de enlaces, los cuales son conexiones entre objetos. La
agregación es un tipo especial de asociación y representa una relación estructural entre un todo y sus partes. La
asociación se representa con una línea continua, posiblemente dirigida, que a veces incluye una etiqueta. A menudo
se incluyen otros adornos para indicar la multiplicidad y roles de los objetos involucrados
Generalización
Es una relación de especialización / generalización en la cual los objetos del elemento especializado (el hijo) pueden
sustituir a los objetos del elemento general (el padre). De esta forma, el hijo comparte la estructura y el
comportamiento del padre. Gráficamente, la generalización se representa con una línea con punta de flecha vacía.
Realización
Es una relación semántica entre clasificadores, donde un clasificador especifica un contrato que otro clasificador
garantiza que cumplirá. Se pueden encontrar relaciones de realización en dos sitios: entre interfaces y las clases y
componentes que las realizan, y entre los casos de uso y las colaboraciones que los realizan. La realización se
representa como una mezcla entre la generalización y la dependencia, esto es, una línea discontinua con una punta
de flecha vacía .

Diagramas

Diagramas
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 usan en pequeños
subconjuntos para poder representar las cinco vistas principales de la arquitectura de un sistema.

Diagramas de Clases
Muestran un conjunto de clases, interfaces y colaboraciones, así como sus relaciones. Estos diagramas son los 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 (sí incluyen clases activas).

Diagramas de Objetos
Muestran un conjunto de objetos y sus relaciones, son como fotos instantáneas de los diagramas de clases y cubren
la vista de diseño estática o la vista de procesos estática desde la perspectiva de casos reales o prototípicos.

Diagramas de Casos de Usos

Muestran un conjunto de casos de uso y actores (tipo especial de clases) y sus relaciones. Cubren la vista estática
de los casos de uso y son especialmente importantes para el modelado y organización del comportamiento.

Diagramas de Secuencia y de Colaboración

Tanto los diagramas de secuencia como los diagramas de colaboración son un tipo de diagramas de interacción.
Constan de un conjunto de objetos y sus relaciones, incluyendo los mensajes que se pueden enviar unos objetos a
otros. Cubren la vista dinámica del sistema. Los diagramas de secuencia enfatizan el ordenamiento temporal de los
mensajes mientras que los diagramas de colaboración muestran la organización estructural de los objetos que
envían y reciben mensajes. Los diagramas de secuencia se pueden convertir en diagramas de colaboración sin
perdida de información, lo mismo ocurren en sentido opuesto.

Diagramas de Estados
Muestran una maquina de estados compuesta por estados, transiciones, eventos y actividades. Estos diagramas
cubren la vista dinámica de un sistema y son muy importantes a la hora de modelar el comportamiento de una
interfaz, clase o colaboración.

Diagramas de Actividades
Son un tipo especial de diagramas de estados que se centra en mostrar el flujo de actividades dentro de un sistema.
Los diagramas de actividades 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.

Diagramas de Componentes
Muestra la organización y las dependencias entre un conjunto de componentes. Cubren la vista de la
implementación estática y se relacionan con los diagramas de clases ya que en un componente suele tener una o
más clases, interfaces o colaboraciones

Diagramas de Despliegue
Representan la configuración de los nodos de procesamiento en tiempo de ejecución y los componentes que residen
en ellos. Muestran la vista de despliegue estática de una arquitectura y se relacionan con los componentes ya que,
por lo común, los nodos contienen uno o más componentes.

Lenguaje unificado de modelado

De Wikipedia, la enciclopedia libre
Saltar a: navegación, búsqueda
Collage de diagramas UML.

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 OMG (Object Management Group).

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 de negocio, 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 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
sólo para lenguajes orientados a objetos.

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