Este documento proporciona una introducción al Lenguaje Unificado de Modelado (UML), incluyendo una panorámica de sus tipos de diagramas principales (diagramas de clases, casos de uso, secuencia, etc.), cómo se usa el proceso de modelado UML, y breves discusiones sobre temas avanzados, herramientas y aplicaciones de UML.

1. UML
Lenguaje Unificado de Modelado

2. Contenido
La importancia de Modelar
Panorámica de UML
Tipos de diagramas
Modo de Empleo: El Proceso.
Temas Avanzados
Herramientas
Aplicaciones

3. Abstracción - Modelado Visual (MV)

4. MV para manejar la complejidad

5. Interfaz de Usuario
(Visual Basic,
Java, ..)
Lógica del Negocio
(C++, Java, ..)
Servidor de BDs
(C++ & SQL, ..)
“Modelar el sistema independientemente
del lenguaje de implementación”
MV para definir la Arquitectura del SW

6. Múltiples Sistemas
MV promueve la reutilización
Componentes
Reutilizados

7. Que es UML
• UML es un lenguaje para
– Visualizar
– Especificar
– Construir
– Documentar
Los artefactos de un sistema con gran cantidad de software

8. Historia de UML
Nov ‘97
1998
1999
2000
UML 1.2
UML 1.3
UML 1.4
2003 UML 2.0
!

9. Fundamentos
UML
Rumbaugh
Jacobson
Meyer
Harel
Wirfs-Brock
Fusion
Embly
Gamma et. al.
Shlaer-Mellor
Odell
Booch
Pre- and Post-conditions
State Charts
Responsabilities
Operation descriptions,
message numbering
Singleton classes
Frameworks, patterns,
notes
Object life cycles

10. 4+1 Vistas de un sistema
Organización
Paquete, subsistema
Dinamica
Interaccion
Máquina de estados
Vista de diseño Vista de Implementación
Vista de
Proceso
Componentes
Clases, interfaces,
colaboraciones
Clases activas
Vista de Despliegue
Nodos
Vista de Casos
de uso
Casos de Uso

11. Modelos y Diagramas
!
" !
#

12. Tipos de Diagramas
• Diagramas Estructurales
– Diagrama de Clases
– Diagrama de Objetos
– Diagrama de Componentes
– Diagrama de Despliegue
• Diagramas de Comportamiento
– Diagrama de Casos de Uso
– Diagrama de Secuencia
– Diagrama de Colaboración
– Diagrama de Estados
– Diagrama de Actividades

13. Modelos, Vistas, y Diagramas
Use Case
DiagramsUse Case
DiagramsDiagramas de
Casos de Uso
Scenario
DiagramsScenario
DiagramsDiagramas de
colaboración
State
DiagramsState
DiagramsDiagramas de
Componentes
Component
DiagramsComponent
DiagramsDiagramas de
Despliegue
State
DiagramsState
DiagramsDiagramas de
objetos
Scenario
DiagramsScenario
DiagramsDiagramas de
Estados
Use Case
DiagramsUse Case
DiagramsDiagrama de
Secuencia
State
DiagramsState
DiagramsDiagramas de
Clases
Diagramas de
Actividad
Un Modelo es una descripción
completa de un sistema
desde una perspectiva particular
Modelos

14. Diagrama de Casos de Uso
Los Casos de Uso (Ivar Jacobson) describen bajo la forma
de acciones y reacciones el comportamiento de un sistema
desde el punto de vista del usuario
Permiten definir los límites del sistema y las relaciones entre
el sistema y el entorno
Los Casos de Uso son descripciones de la funcionalidad del
sistema independientes de la implementación
Los Casos de Uso cubren la carencia existente en métodos
previos (OMT, Booch) en cuanto a la determinación de
requisitos
Los Casos de Uso particionan el conjunto de necesidades
atendiendo a la categoría de usuarios (actores) que
participan en el mismo
Están basado en el lenguaje natural, es decir, es accesible
por los usuarios

15. Caso de estudio. Requisitos
• La universidad ESU quiere informatizar su sistema de
inscripciones.
– El Secretario mantiene el curriculum para un semestre
• Un curso puede tener varias ediciones
– Los estudiantes eligen 4 cursos principales y 2 cursos
alternativos
– Cuando un estudiante se inscribe en un curso, se informa al
sistema de facturación, para facturar el semestre
– Los estudiantes puedes usar el sistema para añadir y quitar
cursos un periodo de tiempo después de la inscripción
– Los profesores usan el sistema para recibir los listados de
estudiantes inscritos en cada edición del curso
– Los usuarios tienen asignado un password para validarse en
el sistema

16. Diagrama de Casos de uso. Elementos
• Actores. Un actor es alguien que interactúa con el
sistema en desarrollo.
Secre tario
Profesor
Estudiante
Sistema de
Facturación

17. Casos de uso
• Casos de Uso. Un caso de uso es un patrón de
comportamiento del sistema. Es una secuencia de
interacciones entre un actor y el sistema en un diálogo.
• Para establecer los casos de uso se examinan las
necesidades de cada actor
– Secretario – Mantener el curriculum
– Profesor – Solicitar listado de curso
– Estudiante – Mantener Calendario
– Sistema de facturación – Recibir información de facturación del
registro.
Mantener Curriculum Solicitar Curso Mantener Calendario

18. Documentación de Casos de Uso
• Se crea un documento de flujo de eventos para cada caso
de uso
– Escrito desde el punto de vista del actor
• De detalla la respuesta del sistema al actor cuando se
ejecuta el caso de uso
• Contenido típico
– Comienzo y fin del caso de uso
– Flujo normal de eventos
– Flujo alternativo
– Flujo excepcional

19. Flujo de Eventos. Mantener curriculum
• El caso de uso comienza cuando el secretario se identifica en el
sistema y teclea su password. El sistema valida el password y
pregunta al secretario qué semestre desea actualizar. El secretario
teclea el semestre deseado.El sistema pregunta por la actividad a
realizar Añadir, Borrar, Revisar o Salir.
– Si la actividad elegida es Añadir – Se ejecuta el subflujo S-1: Añadir un
curso
– Si la actividad elegida es Borrar – Se ejecuta el subflujo S-2: Borrar un
curso
– Si la actividad elegida es Revisar – Se ejecuta el subflujo S-3: Borrar un
curso
– Si se elige Salir – El caso de uso termina

20. Diagrama de casos de uso
• El diagrama de casos de uso muestra las relaciones entre
actores y casos de uso
Estudiante
Mantener Calendario
Siste ma de
Facturación
Profesor
Solicitar Lista do Curso
Secretario
Mantener Curriculum

21. Relaciones entre casos de Uso
– Include. Comportamiento común entre varios casos de uso
– Extend. Comportamiento opcional
– Generalización.
Incripción en Cursos
Mantener Curriculum
Logon
<<include>>
<<include>>

22. Diagrama de casos de uso. Ejemplo
Diagrama de Casos
de Uso en el Paquete
de Gestión de la
Normativa
Gestión de Materias
Gestión de Voces
Gestión de Organismos Emisores
Gestión de Componentes
de las Normas
Actualizador
Registro
de Normativas
Mantenimiento Asociación de
Referencias
Incorporación de
Texto
Catalogación
Derogación
Registro y Gestión
de Normativa
Gestión de Tipos Gestión de Motivos
de Baja

23. Diagrama de casos de uso. Ejemplo
Crear Tarea
Crear No ta
<<include>>
Re enviar Nota
J.P. Desarrollo
Usuario
Reasignar tareaRealizar Ta rea
<<include>>
J.P. Sistemas
OrdenarTareas
Revisor Desarrollo
A proba r Nota
Devolver Nota
Asignar Tarea
<<include>>
Cancelar
Revisor Sistemas

24. Interacción
Los objetos interactúan para realizar colectivamente los
servicios ofrecidos por las aplicaciones. Los diagramas de
interacción muestran cómo se comunican los objetos en una
interacción
Existen dos tipos de diagramas de interacción: el Diagrama de
Colaboración y el Diagrama de Secuencia
El Diagrama de Secuencia es más adecuado para observar la
perspectiva cronológica de las interacciones
El Diagrama de Colaboración ofrece una mejor visión espacial
mostrando los enlaces de comunicación entre objetos
El D. de Colaboración puede obtenerse automáticamente a
partir del correspondiente D. de Secuencia (o viceversa)

25. Diagrama de Secuencia
Muestra la secuencia de mensajes entre objetos
durante un escenario concreto
Cada objeto viene dado por una barra vertical
El tiempo transcurre de arriba abajo
Cuando existe demora entre el envío y la atención se
puede indicar usando una línea oblicua

26. Diagrama de secuencia
• El diagrama de secuencia muestra las interacciones entre los
objetos desde el punto de vista de la secuencia temporal
: Estudiante
:form ulario de
Inscripcion
:gestor de
registro
math101Seccio
n1
math101
rellenar
enviar a dd course (Joe ,
m ath 101)
are you open?
add(joe)
are you open?
add(joe)

27. Diagrama de Secuencia. Ejemplo
: J.P . D es arrollo
: A re a d e
tra bajo
: B D N o tas e ntre
s e rvic io s
: P ropia s P
: N ota
O P E N D A TA B A S E ()
C r earN ota ( )
N E W ()
O P E N VIE W ( )
O P E N ()
O pe n ( )

28. Diagrama de Colaboración
Son útiles en la fase exploratoria para identificar
objetos
La distribución de los objetos en el diagrama permite
observar adecuadamente la interacción de un objeto
con respecto de los demás
La estructura estática viene dada por los enlaces; la
dinámica por el envío de mensajes por los enlaces

29. Diagrama de colaboración
• El diagrama de colaboración muestra las interacciones de los
objetos desde el punto de vista de su estructura y los enlaces
entre ellos.
: Estudiante
:formulario de
Inscripcion
:gestor de
registro
math101Secc
ion1
math101
1: rellenar
2: enviar
3: a dd cours e(Jo e, math 101)
4: are you open?
5: are you open?
6: add(joe)
7: add(joe)

30. Diagrama de colaboración . Ejemplo
: J.P. Desarrollo
: Area de
trabajo
: BDNotas entre
servicios
: PropiasP
: Nota
6: NEW ()
2: OPEN()
4: Open( )
1: OPENDATABASE()
3: OPENVIEW()
5: CrearNota( )

31. Diagrama de Clases
$
%
& ! !
!
"

32. Clasificación
El mundo real puede ser visto desde abstracciones diferentes
(subjetividad)
Mecanismos de abstracción:
Clasificación / Instanciación
Composición / Descomposición
Agrupación / Individualización
Especialización / Generalización
La clasificación es uno de los mecanismos de abstracción más
utilizados

33. Clases
La clase define el ámbito de definición de un conjunto de
objetos
Cada objeto pertenece a una clase
Los objetos se crean por instanciación de las clases

34. Clases: Notación Gráfica
Cada clase se representa en un rectángulo con tres
compartimientos:
nombre de la clase
atributos de la clase
operaciones de la clase
Se identifican examinando los objetos en los diagramas
de interacción.
Curso
nom bre
num eroCreditos
abrir()
añadirEstudiante()

35. Clases
FormularioInscripcion
GestorInscripcion
AlgoritmoCalendario
Curso
Estudiante
Profesor
EdiciónCurso

36. Operaciones
• El comportamiento de las clases se representa por las
operaciones
• Se obtienen examinando los diagramas de interacción
:f o rm u l a ri o d e
In s c r i p c i o n
: g e s to r d e
r e g i s tr o
a d d c o u rs e ( J o e ,
m a t h 1 0 1 )
GestorInscripcion
addCourse(estudiante, curso)

37. Atributos
• La estructura de la clase se representa por sus
atributos
• Se pueden obtener a partir de la definición de la clase,
los requisitos y el conocimiento sobre el dominio
Edición Curso
num ero
lugar
fecha
Cada Edición de un curso
Tiene número, un lugar
y una fecha

38. Clases y Objetos
El Diagrama de Clases y el Diagrama de Objetos
pertenecen a dos vistas complementarias del modelo
Un Diagrama de Clases muestra la abstracción de
una parte del dominio
Un Diagrama de Objetos representa una situación
concreta del dominio
Las clases abstractas no son instanciables

39. Relaciones entre clases
Las relaciones proporcionan una vía para la comunicación
de los objetos
Se examinan los diagramas de interacción para ver los
mensajes entre las clases. Si hay interacción debe haber
algún tipo de enlace entre las clases
Dependencia. Relación semántica entre dos elementos
Asociación. Relación estructural
Agregación. Relación de tipo Es Parte de

40. Encontrar relaciones
• Las relaciones se descubren examinando los diagramas de
interacción .
– Si dos objetos se “hablan” debe haber un camino para la
comunicación
GestorInscripcion
Curso
:f o rm ul a ri o d e
In s crip cio n
:g e s to r d e
r eg is tro
a d d co u rs e (Jo e ,
m a th 1 0 1 )

41. Clases con relaciones
Algoritm oCalen dario
Form ularioIns cripcion
GestorInscripcion
addCourse(estudian te, curs o)
Curso
nombre
numeroCreditos
abrir()
añadirEstudiante()
Estudiante
nombre
especialidad
Profesor
nombre
estado
EdiciónCurso
numero
lugar
fecha
abrir()
añadirEstudiante()

42. Multiplicidad y Navegación
• La multiplicidad define cuántos objetos participan en
las relaciones
– Define el número de instancias de una clase relacionadas con
una instancia de la otra
– Hay que definirla a ambos lados de la relación
• Aunque las asociaciones y agregaciones son
bidireccionales por defecto, se puede restringir la
navegación a una dirección
• Si se restringe la navegación se indica con una
cabeza de flecha que indica la dirección de la
navegación

43. Multiplicidad y Navegación
Alg oritm oCalendario
FormularioInscripcion
GestorInscripcion
addCourse(estudiante, curso)
1
0..*
Cu rso
nombre
numeroCreditos
abrir()
añadirEstudiante()
0..*
1
Estudiante
nomb re
especialidad
Profesor
nombre
estado
EdiciónCurso
numero
lugar
fecha
abrir()
añadirEstudiante()
4
3..10
0..4
11
0..4
3..10
4
0..*
1
1
0..*

44. Herencia y Generalización
• Es una relación entre una superclase y sus subclases
• Se encuentra de dos maneras
– Generalización
– Especialización
• Los atributos y operaciones comunes se muestran en
nivel más alto de la jerarquía

45. Herencia
Algoritm oCalendario
FormularioInscripcion
GestorInscripcion
addCourse(estudiante, curso)
1
0..*
Curso
n ombre
n umeroCreditos
a brir()
a ñadirEstudiante()
0..*
1
Estudiante
especia lidad
Profesor
estado
EdiciónCurso
numero
lugar
fecha
abrir()
añadirEstudiante()
4
3..10
0..4
11
0..4
3..10
4
0..*
1
1
0..*
Usuario
nombre

46. Ejemplo
CIRCULA RES
OFICIOS-CIRCULARES
RESOLUCIONES
ESCRITOS
CRITERIOS LEYES DECRETOS ORDENES
NORMATIVA EXTERNANO RMA TIVA I NTERNA
0..n0..n 0..n0..n
Referencia a
Deroga a
VOZ
Palabra_Voz
Texto_Voz
ORGANISMO EMISOR
Cod_Un idad
Nombre_Unidad
Localizar()
M odificar()
Insertar()
Eliminar()
MATERIA
Cod_Materia
Nombre_Materia
Localizar()
Modificar()
Insertar()
Eliminar()
NORMA/DISPOSICION
Cod_Norma
Año_Publicación
Fecha_Publicación
Fecha_Baja
Asunto
Observación
0..n
1..n
0..n
1..n
0..n1..1 0..n1..1
1..n
0..n
1..n
0..n
TIPOS
0..n
1. .1
0..n
1. .1

47. Diagrama de Estados
Cada objeto está en un estado en cierto instante
El estado está caracterizado parcialmente por los valores algunos de
los atributos del objeto
Son útiles sólo para los objetos con un comportamiento significativo
El estado en el que se encuentra un objeto determina su
comportamiento
Cada objeto sigue el comportamiento descrito en el D. de Estados
asociado a su clase
Los D. de Estados permiten expresar concurrencia, sincronización y
jerarquías de objetos
Los D. de Estados son grafos dirigidos deterministas
Los estados inicial y final están diferenciados del resto
La transición entre estados es instantánea y se debe a la ocurrencia
de un evento

48. Estado de un objeto
Inicia lización
do/ InicializarCurso
Abierto
entry/ RegistrarEstudian te
exit/ IncrementarContador
Cerrado
do/ FinalizarCurso
Cancelado
do/ NotificarEstudiantesRegis trados
AñadirEstudiante[ contador<10 ]
[ contador =10 ]
Cancelar
Cancelar
AñadirEstudiante / contador = 0
Cancelar

49. Diagrama de Estados. Ejemplo
En curso, de desarrollo a sistemas
Devuelta
Aprobada en
Desarrollo
Aprobada en
sistemas
ReenviadaDevuelta
Aprobada en
Desarrollo
Aprobada en
sistemas
Realizada
Reenviada
Nueva, de Desarrollo a
sistemas

50. Diagrama de Actividad
El Diagrama de Actividad es una especialización del Diagrama de
Estado, organizado respecto de las acciones y usado para
especificar:
• Un método
• Un caso de uso
• Un proceso de negocio (Workflow)
Las actividades se enlazan por transiciones automáticas. Cuando
una actividad termina se desencadena el paso a la siguiente
actividad

51. Diagrama de Actividad. Ejemplo

52. Diagrama de Componentes
Los diagramas de componentes describen los
elementos físicos del sistema y sus relaciones
Muestran las opciones de realización incluyendo
código fuente, binario y ejecutable
Los componentes representan todos los tipos de
elementos software que entran en la fabricación de
aplicaciones informáticas. Pueden ser simples
archivos, paquetes de Java, DLL’s, etc.
Las relaciones de dependencia se utilizan en los
diagramas de componentes para indicar que un
componente utiliza los servicios ofrecidos por otro
componente

53. Componentes
Facturación.exe Registro.e xe
Curso.dll Personas.dll

54. Diagrama de Despliegue
Los Diagramas de Despliegue muestran la disposición
física de los distintos nodos que componen un sistema y
el reparto de los componentes sobre dichos nodos
Los estereotipos permiten precisar la naturaleza del
equipo:
– Dispositivos
– Procesadores
– Memoria
Los nodos se interconectan mediante líneas de
comunicación bidireccionales. Estereotipadas con el
protocolo que soportan

55. Diagrama de Despliegue. Ejemplo
Terminal Punto
de Venta
<<Cliente>>
Base de
Datos
<<Servidor>>
$
<<TCP/IP>>
<<RDSI>>
'
(
<<RDSI>>

56. Modo de Empleo. El Proceso
Como ya hemos comentado UML es sólo una notación , no
está ligado a ningún proceso en concreto. No obstante, se
recomienda que las características del proceso empleado
deben ser:
• Iterativo e Incremental
• Centrado en la Arquitectura
• Dirigido por los casos de Uso

57. ¿Qué es un Proceso de Desarrollo de SW?
Requisitos nuevos
o modificados
Sistema nuevo
o modificado
Proceso de Desarrollo
de Software
• Define Quién debe hacer Qué, Cuándo y Cómo debe hacerlo
• No existe un proceso de software universal. Las
características de cada proyecto (equipo de desarrollo,
recursos, etc.) exigen que el proceso sea configurable
)* ' +, -&

58. El ciclo de vida iterativo se basa en la evolución de
prototipos ejecutables que se muestran a los usuarios y
clientes
En el ciclo de vida iterativo a cada iteración se reproduce
el ciclo de vida en cascada a menor escala
Los objetivos de una iteración se establecen en función de
la evaluación de las iteraciones precedentes
Proceso Iterativo e Incremental

59. Las actividades se encadenan en una mini-
cascada con un alcance limitado por los
objetivos de la iteración
" #
$ %
& '
(
... Proceso Iterativo e Incremental

60. Fases e iteraciones
Gestión del Proyecto
Entorno
Modelado de Negocio
Implementación
Pruebas
Analisis & Diseño
Iteración
Preliminar
Iter.
#1
Fases
WorkFlows de Proceso
Iteraciones
Workflows de soporte
Iter.
#2
Iter.
#n
Iter.
#n+1
Iter.
#n+2
Iter.
#m
Iter.
#m+1
Despliegue
Gestión de Configuración
Requerimientos
Elaboracion TransiciónConcepción Construcción

61. Cada iteración comprende:
– Planificar la iteración (estudio de riesgos)
– Análisis de los Casos de Uso y escenarios
– Diseño de opciones arquitectónicas
– Codificación y pruebas. La integración del nuevo
código con el existente de iteraciones anteriores
se hace gradualmente durante la construcción
– Evaluación de la entrega ejecutable (evaluación
del prototipo en función de las pruebas y de los
criterios definidos)
– Preparación de la entrega (documentación e
instalación del prototipo)
Proceso Iterativo e Incremental

62. Requisitos
$ !
. /
* !
!
Análisis & Diseño
Implementación
Pruebas
Casos de Uso
integran el
trabajo
Proceso dirigido por los Casos de Uso

63. ! ) ( " # ! ) ( $ %
*
0 1 0 1
0 1
0 1
' 2
'
34 ! +!5 ' )6 7 8 6. 9, :;;;<
Proceso dirigido por los Casos de Uso

64. Aplicaciones
• Ingeniería directa e Inversa
– Round Trip Engineering
• Modelado de Procesos de Negocio
– Workflow
• Modelado de Aplicaciones Legacy
• Modelado de Aplicaciones Web

65. UML 2 y Model Driven Arquitecture (MDA)
– UML 2.0 Es la última revisión del estándar
– Su objetivo fundamental es dar soporte a la Arquitectura Dirigida
por modelos (MDA)
• El fundamento de MDA es que sistema se obtiene a partir de
transformaciones sucesivas de los modelos
• Primero se obtiene un Modelo Independiente de la Plataforma (PIM)
• Este modelo se transforma para adaptarse a la plataforma particular
obteniendo un Modelo Específico de la Plataforma (PSM)
• A partir de este PSM, se obtendría el sistema final, con una
codificación mínima o ninguna (en teoría)

66. Patrones
– Lo patrones proporcionan una solución común a un problema
común en un contexto dado
• Patrones Arquitectónicos. Estructuras comunes de aplicaciones.
MVC
• Patrones de Diseño. Problemas específicos de diseño de más bajo
nivel
– Creación. Object Factory
– Comportamiento. Controller
- Multiplicidad. Singleton
• Frameworks. Conjuntos de componentes que implementan un patrón
arquitectónico. Struts

67. Herramientas
• Herramientas de Dibujo.
– Microsoft Visio
• Herramientas centradas en el modelo
– Rational Rose
– Argo UML
– Together
• Herramientas centradas en el código. Integradas en el
entorno de desarrollo
– Rational XDE.
– Together Edition for Eclipse. Edition for .Net
– EclipseUML