Lenguaje Unificado

de Modelado (UML)
Metodologías de Desarrollo
Software

Javier Sánchez Pérez

Diagramas
 Modelo: abstracción semánticamente
cerrada de un sistema.
 Vista: proyección de la organización y
estructura de un modelo del sistema,
centrada en un aspecto del sistema.
 Diagrama: representación gráfica de un
conjunto de elementos, normalmente
mostrado como un grafo conexo de nodos
y arcos.
Diagramas
 Diagramas estructurales: representan
partes estáticas de un sistema, tales como
clases, objetos, componentes, etc.
 Diagramas de comportamiento:
especifican las partes dinámicas de un
sistema tales como estados del sistema,
flujo de control de actividades, secuencia
de mensajes, etc.
Diagramas estructurales
 Diagramas de clases: conjunto de
clases, interfaces y colaboraciones, y las
relaciones entre ellas.
 Diagramas de objetos: instantáneas de
las instancias de los elementos
encontrados en los diagramas de clases.
 Diagramas de componentes: conjunto
de componentes y sus relaciones.
 Diagramas de despliegue: conjunto de
nodos y sus relaciones.
Diagramas de
comportamiento
 Diagramas de casos de uso: conjunto de casos
de uso y actores y sus relaciones. Son
importantes para organizar y modelar el sistema.
 Diagramas de interacción:
 Diagramas de secuencia: conjunto de objetos y los
mensajes enviados y recibidos por ellos. Resalta
ordenación temporal de los mensajes.
 Diagramas de colaboración: Resalta organización
estructural de objetos que envían y reciben mensajes.
Diagramas de
comportamiento
 Diagramas de estados: representan
máquinas de estados, construida por estados,
transiciones, eventos y actividades.Útiles para
modelar sistemas reactivos.
 Diagramas de actividades: muestran el flujo
de actividades de un sistema. Importantes
para modelar la función de un sistema, así
como para resaltar el flujo de control entre
objetos.
Vistas

Vista de Vista d
diseño implementa

Vista de
casos de uso

Vista de Vista d
procesos desplieg
Vistas
 Vista de casos de uso: comportamiento
del sistema tal y como es percibido por
usuarios, analistas y encargados de
pruebas.
 Vista de diseño: comprende el
vocabulario del problema y su solución, y
soporta los requisitos funcionales del
sistema (servicios que el sistema debería
proporcionar a los usuarios finales).
Vistas
 Vista de procesos: hilos y procesos que forman
mecanismos de sincronización y concurrencia del
sistema. Se hace mayor énfasis en las clases
activas.
 Vista de implementación: componentes y
archivos que se utilizan para ensamblar y hacer
disponible el sistema físico.
 Vista de despliegue: nodos que forman la
topología hardware sobre la que se ejecuta el
sistema. Distribución, entrega e instalación de las
partes.
Relación Vistas - Diagramas
Vista de casos de uso Diagramas de casos de uso
Diagramas de actividades
Vista de diseño Diagramas de clases
Diagramas de interacción
Diagramas de estados

Vista de procesos Diagramas de clase

Diagramas de interacción

Vista de implementación Diagramas de componentes

Vista de despliegue Diagrama de despliegue

Ejemplo - Hola Mundo

import java.awt.Graphics;
class HolaMundo extends java.applet.Applet {
public void paint (Graphics g) {
g.drawString(“¡Hola Mundo!”, 10, 10);
}
}
Ejemplo - Hola Mundo

Applet Panel Object

HolaMundo
g.drawString
(“Hola Mundo”, 10, 10)
paint()

Graphics
Ejemplo - Hola Mundo

java

HolaMundo
applet
awt
Ejemplo - Hola Mundo
HolaMundo.class
HolaMundo.java

HolaMundo.html

HolaMundo.jpg
Diagrama de clases - Clase

NombreClase
Visibilidad
[visibilidad] atributo1: tipo [=valordefecto]
+ público
[visibilidad] atributo2: tipo [=valordefecto]
- privado …
# protegido [visibilidad] operación1(args): retorno
[visibilidad] operación2(args): retorno
Responsabilidad …

es Responsabilidades
-- responsabilidad1
Descripción de lo -- responsabilidad2
que tiene que
realizar la clase
Diagrama de clases -
Relaciones
 Notación general

Clase
Clase1 Plantilla
… Rol 1 Relación 1-2  Rol 2 …
… [0..*] {Restricción} [0..*] …
Diagrama de clases -
Relaciones
 Relación de  Relación de
dependencia agregación

Clase1 Clase2 Clase1 Clase2

 Relación de asociación  Relación de

composición

Clase1 Clase2 Clase1 Clase2

Diagrama de clases -
Relaciones
 Relación de  Relación de
generalización navegabilidad

Clase1 Clase1 Clase2

 Clases asociación

Clase2 Clase3 Clase2

Clase1

Clase3
Diagrama de clases -
Ejemplo
Empresa
1

1 ..* 1 ..*

Departamento Oficina

nombre: String Ubicación  dirección: String

* * teléfono: Number

* *
{subconjunto}
miembro 1 ..* 1 director OficinaPrincipal
Persona

nombre: String Foto

foto: Imagen
obtenerFoto(p:Foto)
Mecanismos comunes
 Nota: comentarios Nota
clase
…
asociados a uno o
varios elementos

 Estereotipo:
extensión del
«interfaz»
vocabulario que Ipedidos
«create»
permite crear nuevos
tipos de elementos
Mecanismos comunes
 Valor etiquetado:
extensión de las Clase
propiedades de un {Versión = 1.1}

elemento. Permite añadir

nueva información.
 Restricción: extensión de
la semántica de un {atrib1 != NULL}

Clase1
elemento que permite
añadir nuevas reglas. {xor}
Clase2 Clase3
Interfaces y Tipos primitivos
 Interfaz: colección de operaciones que se
usa para especificar un servicio de una
clase o componente.
 Tipo: estereotipo de una clase utilizado
para especificar un dominio de objetos,
junto a las operaciones aplicables al
objeto.
Interfaces

Objetivo RastreadorDeObjetivo
Observador

Objetivo «interfaz»
id Observador
posiciónActual RastreadorDeObjetivo
establecerPos()
actualizar()
establecerVel()
Tipos primitivos

«enumeration»
Boolean
false
«type» true
Int
{valores entre
-2**31-1 y 2**31}

«enumeration»
Estado
desocupado
activado
Paquetes y subsistemas
 Mecanismo de
propósito general Paquete1
para organizar
+ Clase1
elementos en grupos
 Contiene elementos - Clase2
por composición

«import»
Paquete2

+ Clase3

- Clase4
Diagrama de casos de uso
 Cubre principalmente el comportamiento
del sistema(servicios visibles
externamente)
 Se utiliza para:
 Modelar el contexto de un sistema. Se
especifican los actores y se delimita el sistema.
 Modelar los requisitos de un sistema. Qué
debería hacer el sistema desde un punto de
vista externo, independientemente de cómo lo
haga.
Diagrama de casos de uso

Realizar llamada «extend»

Realizar llamada
telefónica de conferencia

Red
telefónica Recibir llamada
«extend»
telefónica
Recibir llamada
adicional

Usar
Usuario Agenda
Teléfono móvil
Diagramas de interacción
 Diagrama de secuencia: destaca la
ordenación temporal de los mensajes.
 Diagrama de colaboración: destaca la
organización estructural de los objetos que
envían y reciben mensajes.
Diagrama de secuencia

p:ProxyODBC
c:Cliente
«create»
:Transacción
establecerAcciones(a,d,o)
establecerValores(d,3,4)

establecerValores(a,”c”)
resultado

«destroy»
Diagrama de colaboración

c:Cliente

1 : «create»
2 : establecerAcciones(a,d,o)
3 : «destroy»

«local»
«global»
:Transacción p:ProxyODBC
2.1 : establecerValores(d,3,4)
2.2 : establecerValores(a,”c”)
Diagrama de actividades

 Se suelen utilizar para:

 Modelar un flujo de trabajo
 Modelar una operación
Diagrama de actividades
Cliente Ventas Almacén

Solicitar producto

Procesar pedido
Extraer artículos

Enviar pedido

Recibir pedido Facturar al cliente

Pagar factura
Cerrar pedido
Diagrama de actividades
Cliente Ventas Almacén

Solicitar devoluc

Obtener nº devoluc

Enviar artículo

Recibir artículo

i:Artículo
[devuelto]
Recolocar artículo

Actualizar factura i:Artículo

[disponib]
Diagrama de estados
 Los diagramas de estados pueden
asociarse a las clases, los casos de uso o
sistemas completos.
 Objeto reactivo es aquél para el que la
mejor forma de caracterizar su
comportamiento es señalar cuál es su
respuesta a los eventos lanzados desde
fuera de su contexto. Tiene un ciclo de
vida bien definido.
Diagrama de estados

Recibiendo
sonando
Inactivo
Conectado

cabeceraOk
enviarFax
colgar
Limpiando
error /
imprimirError verificaciónOk
Transmisión Procesando
Diagrama de componentes
 Se utiliza para modelar aspectos físicos.
 Vista de implementación estática.
 Cosas físicas: ejecutables, bibliotecas,
tablas, archivos y documentos.
 Sirve para:
 Modelar código fuente.
 Modelar versiones ejecutables.
 Modelar bases de datos físicas.
 Modelar sistemas adaptables.
Diagrama de componentes
Modelado de código fuente

signal.h signal.h signal.h

{version = 4.5} {version = 4.0} {version = 3.5}

<<parent>> <<parent>>

signal.cpp

irq.h interp.cpp
Diagrama de componentes
Modelado de una versión ejecutable

trayectoria.dll colision.dll

motor.dll

IMotor

IAutoTest
Diagrama de componentes
Modelado de una base de datos física

Universidad.db

curso departamento profesor clase estudiante

Diagrama de componentes
Modelado de sistemas adaptables

:Universidad.db :Universidad.db
{location = Server A} {location = Server B}

<<copy>>
Diagrama de componentes
find.html

Index.html Find.exe

<<hyperlink>>

dbacs.dll nateng.dll
Diagrama de despliegue
 Muestra la configuración de nodos que
participan en la ejecución y de los
componentes que residen en ellos.
 Vista de despliegue estática (topología del
hardware).
 Se utilizan para:
 Modelar sistemas empotrados.
 Modelar sistemas cliente/servidor.
 Modelar sistemas completamente distribuidos.
Diagrama de despliegue
Internet

clientes

servidores

Consola A 2..* 4..*

<<procesador>> <<procesador>>
servidor cache servidor
Despliega Despliega
http.exe admin.exe
rting.exe logexc.exe
Consola B
Referencias
 Grady Booch, James Rumbaugh, Ivar
Jacobson, “El Lenguaje Unificado de
Modelado”, Addison-Wesley 1999