UML: Unified Modeling Language
Marvin Zumbado

UML: Lenguaje Unificado de Modelado
• UML se inicia como el "Método de Modelado
Unificado" presentado por Booch y Rumbaugh en el
Workshop sobre Casos de Uso OOPSLA'95 (Object-
Oriented Programming Systems Languages and
Applications) en Octubre de 1995.
• También en 1995 se une Ivar Jacobson a Rational
Software Corporation. A este grupo de
investigadores se le conocería como los "tres
amigos”.

UML: Lenguaje Unificado de Modelado
• Desde la fecha de su creación hasta la actualidad
UML ha tenido una evolución, de las cuales se puede
mencionar:
• Noviembre de 1997, es aprobado por el OMG
• 1998 aparece la versión UML 1.2 (revisiones
menores)
• 1999 aparece la versión UML 1.3
• 2000 aparece la versión UML 1.4 (revisiones
menores)
• 2001 aparece la versión UML 1.5
• Sigue UML 2.0.

UML: Lenguaje Unificado de Modelado
• La técnica central en el UML es el Modelamiento en
Objetos, el cual es un lenguaje que permite la
especificación de clases, sus datos o atributos
(privados) y métodos (públicos), herencia y otras
relaciones entre las clases.
• El UML modela sistema mediante el uso de objetos
que forman parte de él así como, las relaciones
estáticas o dinámicas que existen entre ellos.
• UML puede ser utilizado por cualquier metodología
de análisis y diseño orientada por objetos para
expresar los diseños.

UML: Lenguaje Unificado de Modelado
• UML no es un método de desarrollo.
• No le dice cómo pasar del análisis al diseño, ni de
este al código.
• No son una serie de pasos que llevan al
desarrollador a producir código a partir de unas
especificaciones.
• UML al no ser un método de desarrollo es
independiente del ciclo de desarrollo.

UML: Lenguaje Unificado de Modelado
• Hay dos aspectos de "unificación" que UML
logra:
• El primero es que efectivamente termina con
muchas de las diferencias, entre los lenguajes
modeladores de métodos previos.
•
Segundo, unifica las perspectivas entre muchos
diferentes tipos de sistemas (negocio vs
software), fases de desarrollo (requerimientos,
análisis, diseño e implementación), y conceptos
internos.

CONCEPTOS BASICOS
• PROGRAMACIÓN ORIENTADA A OBJETOS
• La programación orientada a objetos difiere de la
programación por procedimientos tradicional, pues
examina los objetos que son parte de un sistema. Cada
objeto es una representación de alguna cosa o evento real.
•
• OBJETOS
• Los objetos son personas, lugares o cosas que son
relevantes para el sistema bajo análisis. Los objetos
podrían ser clientes, artículos, pedidos, etc. Los objetos
también podrían ser pantallas GUI o áreas de texto en la
pantalla.

CONCEPTOS BÁSICOS
• CLASES
• Los objetos se representan y agrupan en clases que
son óptimas para reutilizarse y darles
mantenimiento. Una clase define el conjunto de
atributos y comportamientos compartidos por cada
objeto de la clase.
• Las clases están representadas por rectángulos, con el
nombre de la clase, y también pueden mostrar
atributos y métodos de la clase en otros dos “campos”
dentro del rectángulo.
•

CONCEPTOS BÁSICOS
• HERENCIA
• Las clases pueden tener hijos; es decir, una clase se puede crear a
partir de otra clase. En el UML, la clase original —o madre— se
conoce como clase base. La clase hija se denomina clase derivada.
Ésta se puede crear de tal manera que herede todos los atributos y
comportamientos de la clase base.
• Metodos:
• Los métodos se muestran al menos con su nombre, y pueden
mostrar sus parámetros y valores de retorno.

Algunas Herramientas
Open Licenciamiento
Nombre Comentario
Source de Software
Microsoft
Visio No Comercial Herramienta de diagramado con soporte UML
MyEclipse No Comercial Un Eclipse basado en IDE
Una Herramienta de Open Source para crear
Nclass Si diagramas de clase UML
Herramienta de verificación de Software para
KeY Si GPL Programas en Java

Bloques básicos de construcción de
UML
• Elementos
▫ Son abstracciones que actúan como unidades
básicas de construcción
• Relaciones
▫ Son abstracciones que actúan como unión entre
los distintos elementos.
• Diagramas
▫ Los diagramas son la disposición de un conjunto
de elementos, que representan el sistema
modelado desde diferentes perspectivas

Elementos
• Estructurales:
▫ son las partes estáticas de los modelos y representan
aspectos conceptuales o materiales.
• Comportamiento:
▫ son las partes dinámicas de los modelos y representan
comportamientos en el tiempo y en el espacio.
• Agrupación (1):
▫ son las partes organizativas de UML, establecen las
divisiones en que se puede fraccionar un modelo
• Notación (1):
▫ son las partes explicativas de UML, comentarios que
pueden describir textualmente cualquier aspecto de un
modelo.

Relaciones
Es una relación entre dos elementos,
tal que un cambio en uno puede
Dependencia
afectar al otro.
Es una relación estructural que
resume un conjunto de enlaces que
Asociación
son conexiones entre objetos.
Es una relación en la que el elemento
generalizado puede ser substituido
Generalización
por cualquiera de los elementos hijos,
ya que comparten su estructura y
comportamiento.
Es una relación que implica que la
parte realizante cumple con una serie
Realización
de especificaciones propuestas por la
clase realizada (interfaces).

Diagramas
• Los diagramas estáticos son:
▫ Clases
▫ Objetos
▫ Componentes
▫ Despliegue.
• Los diagramas de comportamiento son:
▫ Casos de Uso
▫ Secuencia
▫ Colaboración
▫ Estados
▫ Actividades.

Diagrama de Caso de Uso
• Describen lo que hace un sistema desde el punto
de vista de un observador externo
• El ¿Qué? más que el ¿Cómo?
• Los actores son papeles que determinadas
personas u objetos desempeñan.
• Los Casos de Uso se representan por medio de
óvalos y las líneas representan una asociación de
comunicación.
• El estereotipo “<<” y “>>” concreta un paso más
allá el tipo de relación existente entre 2 casos

Diagrama de Secuencia y Diagrama de
Colaboración
• Describen como los objetos del sistema colaboran
• Es la interacción que detalla como las operaciones se
llevan a cabo, qué mensajes son enviados y cuando,
organizado todo en torno al tiempo.
• El tiempo avanza “hacia abajo” en el diagrama.
• Los objetos involucrados en la operación se listan de
izquierda a derecha de acuerdo a su orden de
participación dentro de la secuencia de mensajes.

• Los diagramas de colaboración son otro
tipo de diagramas de interacción, que contiene la
misma información que los de secuencia, sólo
que se centran en las responsabilidades de cada
objeto, en lugar de en el tiempo en que los
mensajes son enviados.

Diagrama de Estados y Diagrama de
Actividades
• Los diagramas de estados muestran los posibles
estados en que puede encontrarse un objeto y las
transiciones que pueden causar un cambio de
estado. El estado de un objeto depende de la
actividad que esté llevando a cabo o de alguna
condición.
• Las transiciones son las líneas que unen los
diferentes estados

• Los diagramas de actividades son
básicamente diagramas de flujo adornados, que
guardan mucha similitud con los diagramas de
estados.
• Mientras que los diagramas de estados centran
su atención en el proceso que está llevando a
cabo un objeto, los diagramas de actividades
muestran como las actividades fluyen y las
dependencias entre ellas.

Vistas
• Vista de Casos de Uso: describen el comportamiento
del sistema como lo verían los usuarios finales, los
analistas y demás componentes del equipo de
desarrollo.
• Vista de Diseño: clases e interfaces que conforman
el vocabulario del problema y su solución. Da
soporte a los requisitos funcionales del sistema, es
decir los servicios que proporciona a los usuarios
finales.
• Vista de Procesos: hilos y procesos que forman los
mecanismos de sincronización y concurrencia del
sistema. Da soporte al funcionamiento, capacidad de
crecimiento y rendimiento del sistema.

Vistas (cont.)
• Vista de Despliegue: la topología hardware sobre
el que se ejecuta el sistema. Da soporte a la
distribución, entrega e instalación de las partes
que conforman el sistema físico.
• Vista de Implementación: componentes y
archivos empleados para hacer posible el
sistema físico. Da soporte a la gestión de
configuraciones de las distintas versiones del
sistema, a partir de componentes y archivos.

Críticas a UML
• Su carencia de una semántica precisa, lo que ha
dado lugar a que la interpretación de un modelo
UML no pueda ser objetiva
• No se presta con facilidad al diseño de sistemas
distribuidos (transmisión, serialización,
persistencia)
• UML sí acepta la creación de nuestros propios
elementos para este tipo de modelado, incluso
cuenta con la posibilidad de agregar comentarios en
forma de notas en las cuales se puede detallar todo
aquello que no pueda ser expresado

Resumen del proceso
• Iniciar y mantener reuniones con los usuarios
finales del programa
• Construir la vista de Casos de Uso definiendo
exactamente la funcionalidad que se va a
incorporar en el programa
• Se definen clases y relaciones entre ellas. Se
construye aquí la vista de diseño y la vista de
procesos.

Resumen del proceso (Cont.)
• Se define la vista de despliegue, que define la
arquitectura física del sistema, y la vista de
implementación.
• Construir el sistema, repartiendo las tareas entre
el equipo de programación.
• Buscar errores de programación, o incluso de
diseño, corregirlos e ir sacando sucesivas
versiones del programa
• Documentar y entregar el programa a los
usuarios finales.

CONCLUSIONES
• UML Es un lenguaje de modelado y no de programación.
•
• El vocabulario y las reglas de un lenguaje como UML indican cómo
crear y leer modelos bien formados, pero no dice que modelos se deben
crear ni cuando se deberían crear. Esta tarea corresponde al proceso de
desarrollo del software.
•
•
• Detrás de cada símbolo en la notación de UML hay una semántica bien
definida, de esta manera un desarrollador puede escribir un modelo en
UML, y otro desarrollador o incluso otra herramienta, puede interpretar
ese modelo sin ambigüedad.
•
• UML esta pensado principalmente para sistemas con gran cantidad de
software.

MUCHAS GRACIAS