UNIVERSIDAD

INDOAMERICA

FACULTAD DE INGENIERIA EN SISTEMAS

INGENIRIA DEL SOTFWARE

EDISON MOYOLEMA
 
 
 QUE ES UML
Lenguaje Unificado de Modelado (LUM o 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 y funciones del sistema, y
aspectos concretos como expresiones de lenguajes de
programación, esquemas de bases de datos y
componentes reutilizables.
 Es importante resaltar 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 entregando 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, sin embargo, 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.
 EL NACIMIENTO DE UML
 Antes de UML 1.x
 Después de que la Rational Software Corporation
contratara a James Rumbaugh de General Electric en 1994, la
compañíá se convirtió en la fuente de los dos esquemas de
modelado orientado a objetos más populares de la época: el
OMT (Object-modeling technique) 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íá de software orientado a objetos.
Jacobson se unió a Rational en 1995,. Los tres metodologistas
eran conocidos como los Tres Amigos, porque se sabia de sus
constantes argumentos 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.
 Bajo la dirección técnica de los Tres Amigos fue
organizado un consorcio internacional llamado UML Partners
en 1996 para completar las especificaciones del Lenguaje
Unificado de Modelado (UML), 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
UML 1.x
 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, si se adoptó la capacida 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 OO fueron
integrados superficialmente en UML con el propósito de
hacerlo compatible con todos los métodos OO. 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 variedad de problemas de
ingeniería, desde procesos sencillos y aplicaciones de
un sólo usuario a sistemas concurrentes y distribuidos.
 OBJETOS Y UML
Un objeto se representa de la misma forma
que una clase. En el compartimento superior
aparecen el nombre del objeto junto con el
nombre de la clase subrayados, según la
siguiente sintaxis: nombre_del_objeto:
nombre_de_la_clase Puede representarse un
objeto sin un nombre específico, entonces
sólo aparece el nombre de la clase.
 ESTRUCTURA UML
Organización de la superestructura
 El bloque de construcción básico del UML es un
diagrama. La estructura de los diagramas UML está
reflejado por el diagrama de la figura 2, de acuerdo
con la especificación del UML 2.0 del Object
Development Group. Los detalles sobre estos
diagramas específicos se organizan de acuerdo a
esta estructura taxonómica, que da la perspectiva
a los diagramas y a sus interrelaciones. Los
diagramas de interacción comparten propiedades y
atributos similares, como lo hacen los diagramas
estructurales y de comportamiento. En color azul
se distinguen aquellos diagramas que aparecen en
esta versión del UML.

Diagramas de Estructura y Diagramas de
comportamiento
 Los diagramas estructurales representan
elementos y así componen un sistema o una
función. Estos diagramas pueden reflejar las
relaciones estáticas de una estructura, como lo
hacen los diagramas de clases o de paquetes, o
arquitecturas en tiempo de ejecución, tales como
diagramas de Objetos o de Estructura de
Composición. Los diagramas de comportamiento
representan las características de comportamiento
de un sistema o proceso de negocios y, a su vez,
incluyen a los diagramas de: actividades, casos de
uso, maquinas de estados, tiempos, secuencias,
repaso de interacciones y comunicaciones.

BLOQUES DE
CONTRUCCION UML
Bloques de construcción del UML
 El vocabulario del UML engloba tres tipos
de bloques de construcción:
 1. Cosas
 2. Relaciones
 3. Diagramas
 Las cosas son abstracciones del mundo
real; las relaciones conectan estas cosas; los
diagramas agrupan colecciones de cosas.
 Cosas
 Hay cuatro tipos de cosas en el UML:
 1. Cosas de estructura
 Las cosas estructurales son los nombres de los modelos
UML. Éstas son mayormente las partes estáticas de un
modelo, representando elementos que son bien conceptuales
o bien físicos.
 Los siguientes elementos – clases, interfaces,
colaboraciones, casos de uso, componentes y nodos – son las
cosas estructurales básicas que nos pueden ayudar en un
modelo de UML. Hay algunas variaciones en estos elementos,
tales como actores, señales y utilidades (tipos de clases).
 2. Cosas de comportamiento
 Las cosas de comportamiento son las partes dinámicas
de los modelos del UML. Éstas son los verbos de un modelo,
representando el comportamiento en el tiempo y en el
espacio.
 Los dos siguientes elementos – interacciones y máquinas
de estado – son las cosas de comportamiento básicas que nos
pueden ayudar en un modelo de UML. Semánticamente,
estos elementos están conectados a varios elementos
 3. Cosas de agrupamiento
 Las cosas de agrupamiento son las partes de
organización de los modelos del UML. Éstas son las cajas en
las que se puede descomponer un modelo.
 Los paquetes son las cosas de agrupamiento básicas con
que podemos organizar un modelo de UML. Hay algunas
variaciones, tales como subsistemas (tipos de paquetes).
 4. Cosas de anotación
 Las cosas de anotación son las partes de explicación de
los modelos del UML. Éstas son los comentarios que podemos
aplicar para describir cualquier elemento en un modelo.
 Las notas son las cosas de anotación básicas que
podemos incluir en un modelo de UML. Normalmente
utilizamos notas para adornar nuestros diagramas con
restricciones o comentarios que son expresadas en texto
formal o informal.

 Relaciones
 Hay tres tipos de relaciones en el UML:
 1. Relaciones de asociación
 Una asociación es una relación de estructura que
describe un conjunto de enlaces, siendo un enlace una
conexión entre objetos. La agregación es un tipo especial de
asociación, representando una relación de estructura entre
un todo y sus partes.
 2. Relaciones de dependencia
 Una dependencia es una relación semántica entre dos
cosas en las que un cambio en una cosa (la cosa
independiente) puede afectar a las semánticas de la otra
cosa (la cosa dependiente). También hay variaciones, tales
como «includes» y «extends».
 3. Relaciones de generalización
 Una generalización es una relación de
especialización/generalización en la que los objetos del
elemento especializado (el hijo) son sustituibles por objetos
del elemento generalizado (el padre). De esta forma, el hijo
 Diagramas
Un diagrama es la presentación gráfica de un
conjunto de elementos, la mayoría de las
veces como si se tratara de un grafo
conectado de vértices (cosas) y de arcos
(relaciones). Nosotros dibujamos diagramas
para visualizar un sistema desde diferentes
perspectivas. En teoría, un diagrama puede
contener cualquier combinación de cosas y
relaciones. Sin embargo, en la práctica sólo
aparece un número pequeño de
combinaciones que sean consistentes con las
cinco vistas comprendidas en la arquitectura
de un sistema de software. La notación UML
incluye nueve tipos de diagramas:
 1. Diagrama de clase
 Un diagrama de clase muestra un conjunto de
clases, interfaces, colaboraciones y sus relaciones. Este
diagrama es el que más se encuentra en los sistemas
de modelado orientado a objetos. Los diagramas de
clase dirigen la visión de diseño estática de un sistema.
 2. Diagrama de objeto
 Un diagrama de objeto muestra un conjunto de
objetos y sus relaciones. Este diagrama representa una
fotografía estática de instancias de las cosas que se
encuentran en un diagrama de clase. Los diagramas de
objeto dirigen la visión de diseño estática o la visión de
proceso estática de un sistema, al igual que los
diagramas de clase, pero desde la perspectiva del
mundo real.
 3. Diagrama de caso de uso
 Un diagrama de caso de uso muestra un conjunto
de casos de uso y actores (un tipo especial de clase) y
sus relaciones. Los diagramas de casos de uso dirigen la
visión de caso de uso estática de un sistema. Estos
diagramas son importantes a la hora de organizar y
 4. Diagrama de secuencia
 5. Diagrama de colaboración
 Estos diagramas son tipos de diagramas de interacción.
Un diagrama de interacción muestra una interacción, que
consiste de un conjunto de objetos y sus relaciones,
incluyendo los mensajes que pueden enviarse entre ellos. Los
diagramas de interacción dirigen la visión dinámica de un
sistema.
 Un diagrama de secuencia es un diagrama de
interacción que enfatiza el orden de los mensajes en el
tiempo. Un diagrama de colaboración es un diagrama de
interacción que enfatiza la organización estructural de los
objetos que envían y reciben mensajes. Los diagramas de
secuencia y los diagramas de colaboración son isomórficos,
es decir, se pueden transformar el uno en el otro.
 6. Diagrama de estado
 Un diagrama de estado muestra una máquina de estado,
que consta de estados, transiciones, eventos, acciones y
actividades. Los diagramas de estado dirigen la visión
dinámica de un sistema. Estos diagramas son importantes a
la hora de modelar el comportamiento de una interfaz, clase
o colaboración, y enfatizan el comportamiento de un objeto
ordenado por los eventos que se suceden, lo cual es
especialmente útil en los sistemas de tiempo real.
 7. Diagrama de actividad
 Un diagrama de actividad es un tipo especial de
diagrama de estado que muestra el flujo de actividad a
actividad dentro de un sistema. Los diagramas de actividad
dirigen la visión dinámica de un sistema. Estos diagramas son
importantes a la hora de modelar la función de un sistema y
enfatizan el flujo de control entre los objetos.
 8. Diagrama de componente
 Un diagrama de componente muestra las organizaciones
y dependencias entre un conjunto de componentes. Los
diagramas de componente dirigen la visión de
implementación estática de un sistema. Estos diagramas se
relacionan con los diagramas
 de clase en el sentido de que un componente,
normalmente, engloba a una o varias clases, interfaces o
colaboraciones.
 9. Diagrama de despliegue
 Un diagrama de despliegue muestra la configuración de
los nodos que se procesan en tiempo de ejecución y los
componentes que están dentro de ellos. Los diagramas de
despliegue dirigen la visión de despliegue estática de una
arquitectura. Estos diagramas se relacionan con los
diagramas de componente en el sentido de que un nodo
 MECANISMO COMUNES
DE UML
 Mecanismos comunes del UML
 La construcción de los bloques del UML
resulta más sencilla y más armoniosa, si se
realiza de acuerdo a un patrón de
características comunes.
 En UML se aplican de forma consistente
estos cuatro mecanismos comunes:

 1. Especificaciones
 Detrás de cada parte de la notación gráfica del UML hay una
especificación que proporciona una declaración textual de la sintaxis
y semánticas de dicho bloque de construcción. Por ejemplo, detrás
de un icono de clase hay una especificación que proporciona el
conjunto completo de atributos, de operaciones (incluyendo sus
formatos completos) y de comportamientos que engloba dicha clase;
visualmente, dicho icono de clase podría mostrar únicamente una
pequeña parte de esta especificación.
 2. Adornos
 La mayoría de los elementos en el UML tienen una notación
gráfica y directa que proporciona una representación visual de los
aspectos más importantes del elemento. Por ejemplo, la notación de
clase también expone los aspectos más importantes de una
 clase, principalmente su nombre, sus atributos y sus
operaciones. Pero una especificación de clase puede incluir otros
detalles, tales como si es abstracta o la visibilidad de sus atributos y
de sus operaciones. Muchos de estos detalles se pueden añadir
como adornos textuales o gráficos dentro del rectángulo básico de la
clase.
 3. Divisiones comunes
 A la hora de modelar sistemas orientados a objetos, el mundo
aparece dividido como mínimo en un par de formas. Por ejemplo,
está la división de clase y de objeto. Una clase es una abstracción,
mientras que un objeto es una manifestación concreta de dicha
abstracción en el UML. Podemos modelar tanto las clases como los
objetos. Gráficamente, el UML distingue un objeto de una clase, ya
 4. Mecanismos de extensión
 El UML proporciona un lenguaje estándar para escribir modelos
de software, pero no es posible para un lenguaje cerrado expresar
todos los detalles de todos los modelos en todos los dominios a lo
largo de todo el tiempo. Por esta razón, el UML es un lenguaje
abierto, que se puede extender de forma controlada. Los
mecanismos de extensión del UML incluyen:
 • Estereotipos
 Un estereotipo extiende el vocabulario del UML, permitiendo
que podamos crear nuevos tipos de bloques de construcción que son
derivados a partir de los ya existentes y que son específicos a
nuestro problema. Se distinguen claramente ya que van encerrados
entre los siguientes delimitadores: « ».
 • Valores añadidos (tagged values)
 Un valor añadido, en el sentido de una “coletilla”, extiende las
propiedades de un bloque de construcción del UML, permitiendo que
podamos crear nueva información en la especificación de dicho
elemento. En la práctica se utilizan muy poco.
 • Restricciones
 Una restricción extiende las semánticas de un bloque de
construcción del UML, permitiendo que podamos añadir nuevas
reglas o modificar las ya existentes. Se distinguen claramente ya
que van encerrados entre los siguientes delimitadores: { }.
