Fundamentos de

Modelado OO en UML
Adaptado de Curso de UML,
Patricio Letelier T.,
Universitat Politècnica de València, España

1
Objetos
ƒ Objeto = unidad atómica que encapsula estado
y comportamiento

ƒ La encapsulación en un objeto permite una alta

cohesión y un bajo acoplamiento

ƒ Un objeto puede caracterizar una entidad física

(coche) o abstracta (ecuación matemática)

2
… Objetos
ƒ En UML, un objeto se representa por un
rectángulo con un nombre subrayado

Otro ob jeto

Un objeto

Otro ob jeto más

3
… Objetos
ƒ Ejemplo de varios objetos relacionados:

Cuenta Corriente 101

Juan

Banco de Valencia

Felipe
Cuenta Corriente 114

4
… Objetos
ƒ Objeto = Identidad + Estado + Comportamiento
ƒ El estado está representado por los valores de los
atributos
ƒ Un atributo toma un valor en un dominio concreto

Un coche

Azul
979 Kg
70 CV
...

5
Clases y Objetos

6
Comportamiento
ƒ Ejemplo de interacción:

Un Objeto Operación 1

1: Un mensaje Operación 2

Otro Objeto

7
… Comportamiento
ƒ Los mensajes navegan por los enlaces, a
priori en ambas direcciones

ƒ Estado y comportamiento están relacionados

ƒ Ejemplo: no es posible aterrizar un avión si
no está volando. Está volando como
consecuencia de haber despegado del suelo

8
Persistencia
ƒ La persistencia de los objetos designa la
capacidad de un objeto de trascender en el
espacio/tiempo
ƒ Podremos después reconstruirlo, es decir,
cogerlo de memoria secundaria para utilizarlo
en la ejecución (materialización del objeto)

ƒ Los lenguajes OO no proponen soporte

adecuado para la persistencia, la cual debería
ser transparente, un objeto existe desde su
creación hasta que se destruya
9
Comunicación
ƒ Un sistema informático puede verse como un
conjunto de objetos autónomos y concurrentes
que trabajan de manera coordinada en la
consecución de un fin específico

ƒ El comportamiento global se basa pues en la

comunicación entre los objetos que la
componen

10
… Comunicación
ƒ Categorías de objetos:
• Activos - Pasivos
• Cliente – Servidores, Agentes
ƒ Objeto Activo: posee un hilo de ejecución (thread)
propio y puede iniciar una actividad
ƒ Objeto Pasivo: no puede iniciar una actividad pero
puede enviar estímulos una vez que se le solicita un
servicio
ƒ Cliente es el objeto que solicita un servicio. Servidor
es el objeto que provee el servicio solicitado
11
… Comunicación
ƒ Los agentes reúnen las características de
clientes y servidores

ƒ Son la base del mecanismo de delegación

ƒ Introducen indirección: un cliente puede
comunicarse con un servidor que no conoce
directamente

12
… Comunicación
ƒ Ejemplo con objeto agente:

Servidor 1
2:

Un agente

1: 3:

Un cliente Servidor 2

13
El Concepto de Mensaje
ƒ La unidad de comunicación entre objetos se
llama mensaje

Objeto 1 1: Mensaje A Objeto 2

2: Mensaje C
4: Mensaje E

Objeto 3 Objeto 4

3: Mensaje D

14
Mensaje y Estímulo
ƒ Un estímulo causará la invocación de una operación, la
creación o destrucción de un objeto o la aparición de
una señal
ƒ Un mensaje es la especificación de un estímulo

15
 UML
Diagrama de Casos de Uso

16
Casos de Uso
ƒ Los Casos de Uso (Ivar Jacobson) describen
bajo la forma de acciones y reacciones el
comportamiento de un sistema desde el p.d.v.
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
ƒ Diferente al Diagrama de Flujo de Datos del
Enfoque Estructurado
17
… Casos de Uso
Actores:
• Principales: personas que usan el sistema
• Secundarios: personas que mantienen o administran el
sistema
• Material externo: dispositivos materiales imprescindibles
que forman parte del ámbito de la aplicación y deben ser
utilizados
• Otros sistemas: sistemas con los que el sistema interactúa

ƒ La misma persona física puede interpretar varios

papeles como actores distintos

ƒ El nombre del actor describe el papel desempeñado

18
… Casos de Uso
ƒ Los Casos de Uso se determinan observando y
precisando, actor por actor, las secuencias de
interacción, los escenarios, desde el punto de vista del
usuario

ƒ Un escenario es una instancia de un caso de uso

ƒ Los casos de uso intervienen durante todo el ciclo de

vida. El proceso de desarrollo estará dirigido por los
casos de uso

19
Casos de Uso: Relaciones
ƒ UML define cuatro tipos de relación en los
Diagramas de Casos de Uso:

• Comunicación

C aso de U so
Actor

20
… Casos de Uso: Relaciones
• Inclusión : una instancia del Caso de Uso origen
incluye también el comportamiento descrito por el
Caso de Uso destino

<<include>>

Caso de Uso Origen C aso de U so Desti no

<<include>> reemplazó al denominado <<uses>>

21
… Casos de Uso: Relaciones
ƒ Ejemplo <<include>>:

<<include>>
Reintegro Cuenta Corriente

Cliente Verificar Operación

<<include>>

Reintegro Cuenta de Crédito

22
… Casos de Uso: Relaciones
• Extensión : el Caso de Uso origen extiende el
comportamiento del Caso de Uso destino

<<extend>>

Caso de Uso Origen C aso de U so Desti no

23
… Casos de Uso: Relaciones
ƒ Ejemplo <<extend>>:

Solicitar Préstamo
Cliente

[Tarjeta Caducada]

<<extend> >

Solic itar N ueva Tarjeta

24
… Casos de Uso: Relaciones
ƒ Ejemplo <<include>> y <<extend>>:

Ide nt fi i caci ón
<<include>>

Transferencia
Cliente

<< exten d>>

Transferencia en Internet
25
… Casos de Uso: Relaciones
ƒ Otro ejemplo <<include>> y <<extend>>:

Supply Customer Data Order Product

Arrange Payment

<<include>> <<include>>
<<include>>

the salesperson asks

for the catal og
1 * <<extend>>

Salesperson Request Catalog

Place Order

26
… Casos de Uso: Relaciones
• Herencia : el Caso de Uso origen hereda la
especificación del Caso de Uso destino y
posiblemente la modifica y/o amplía

Caso de Uso Hij o Caso de Uso Padre

27
… Casos de Uso: Relaciones
• Ejemplo de herencia

Reserva por
Agencia

* *
Reserva de
Cliente Billete Aéreo

Reserva en
Aerolínea

28
Casos de Uso: Construcción
ƒ Un caso de uso debe ser simple, inteligible, claro y
conciso
ƒ Generalmente hay pocos actores asociados a cada
Caso de Uso
ƒ Preguntas clave:
• ¿cuáles son las tareas del actor?
• ¿qué información crea, guarda, modifica,
destruye o lee el actor?
• ¿debe el actor notificar al sistema los cambios
externos?
• ¿debe el sistema informar al actor de los
cambios internos?
29
… Casos de Uso: Construcción
ƒ La descripción del Caso de Uso comprende:
• el inicio: cuándo y qué actor lo produce?
• el fin: cuándo se produce y qué valor devuelve?
• la interacción actor-caso de uso: qué mensajes
intercambian ambos?
• objetivo del caso de uso: ¿qué lleva a cabo o
intenta?
• cronología y origen de las interacciones
• repeticiones de comportamiento: ¿qué
operaciones son iteradas?
• situaciones opcionales: ¿qué escenarios
alternativos se presentan en el caso de uso?

30
Ejemplo
Cajero Automático

Sacar Dinero

Realizar
Cliente Transferencias Sistema Bancario

Depositar Dinero

Administrar Cajero

Operador

31
Caso de Uso UC1: Sacar Dinero
Actor Principal: Cliente
Personal involucrado e intereses:
- Cliente: quiere retirar dinero en efectivo desde su cuenta de
forma rápida y sencilla
- Sistema Bancario: quiere recibir peticiones de transacción en
formato correcto; quiere mantener actualizada la información de
las cuentas de sus clientes a partir de la información de los giros
en el Cajero.
Precondiciones: El Cliente suministra tarjeta bancaria
Garantías de éxito (Postcondiciones): El Cliente obtiene el monto
requerido en dinero en efectivo.
Escenario Principal de Éxito (o Flujo Básico):
1. El Cliente inserta la tarjeta en el Cajero
2. El Cajero lee el código de la banda magnética de la tarjeta,
verifica si es aceptable y pide el código del Cliente
3. El Cliente introduce el código
4. Si el código es correcto, el Cajero pide al Cliente que seleccione
el tipo de transacción deseada
5. El Cliente selecciona la función Sacar Dinero
6. El Cajero le pide al cliente que teclee la cantidad deseada
7. El Cliente teclea la cantidad que quiere sacar
8. El Cajero envía la petición al sistema bancario
9. Si la conexión al Sistema Bancario es exitosa, el Sistema
Bancario deberá comprobar si el monto es permitido.
10. El Cajero expulsa la tarjeta, imprime el recibo y entrega el dinero
32
Extensiones (o Flujos Alternativos):
2’ La tarjeta no es aceptada
- El Cajero expulsa la tarjeta, emitiendo un sonido
4’ Código incorrecto (1,2)
- Se emite un mensaje, dando al Cliente la oportunidad de
volver a introducir el código
4’’ Código incorrecto (3)
- Se emite un mensaje y se retiene la tarjeta
9’a Fallo en la conexión con Sistema Bancario
- Se emite un mensaje y se expulsa la tarjeta
9’b El Sistema Bancario no permite girar ese monto
- Se emite un mensaje y se expulsa la tarjeta
10’ El Cajero no dispone de la cantidad pedida
- Se emite un mensaje y se vuelve al paso 7
1-9’ Cancelar
- En cualquier momento, el usuario puede cancelar la
transacción, con lo que se expulsa la tarjeta

33
Ejemplo 2…
Venta por Catálogo
Comprobar Estado
del Pedido

Realizar Pedido Vendedor

Completar Pedido

Cliente Empleado

Establecer Crédito

Supervisor

34
…Ejemplo 2

<<extend>>
Solicitar Catálogo Realizar Pedido
<<i
nclu
>> de>
l ude >
nc
<<i

<<in
cl
ude>
Suministrar Datos Realizar Pedido de
Cliente Productos

>
Realizar Pago

Cliente

Vendedor

35
Plantilla de documentación
propuesta…
RF- <id del requisito> <nombre del requisito funcional>

Versión <numero de versión y fecha>

Autores <autor>

Fuentes <fuente de la versión actual>

Objetivos asociados <nombre del objetivo>

Descripción El sistema deberá comportarse tal como se describe en

el siguiente caso de uso { concreto cuando <evento de
activación> , abstracto durante la realización de los
casos de uso <lista de casos de uso>}

36
Plantilla de documentación
propuesta…
Precondición <precondición del caso de uso>
Postcondición <postcondición del caso de uso>
Secuencia Paso Acción
Normal 1 {El <actor> , El sistema} <acción realizada por el
actor o sistema>, se realiza el caso de uso
< caso de uso RF-x>
2 Si <condición>, {el <actor> , el sistema} <acción
realizada por el actor o sistema>>, se realiza el
caso de uso < caso de uso RF-x>
3
4
5
6
n

37
Plantilla de documentación
propuesta…
Excepciones Paso Acción
1 Si <condición de excepción>,{el <actor> , el
sistema} }<acción realizada por el actor o
sistema>>, se realiza el caso de uso
< caso de uso RF-x>, a continuación este caso
de uso {continua, aborta}
2
3
Rendimiento Paso Cota de tiempo
1 n segundos
2 n segundos

38
…Plantilla de documentación
propuesta

Frecuencia esperada <nº de veces> veces / <unidad de tiempo>

Importancia {sin importancia, importante, vital}
Urgencia {puede esperar, hay presión, inmediatamente}
Comentarios <comentarios adicionales>

39
Comentarios
ƒ En métodos OO que carecen de una técnica de captura de
requisitos se comienza inmediatamente con la
construcción del modelo de análisis/diseño

ƒ Los Casos de Uso son una idea maravillosa que ha sido

generalmente complicada. El verdadero truco para los
Casos de Uso es mantenerlos simples. Recordad, mañana
van a cambiar. Rober C. Martin

ƒ Los requisitos NO funcionales también son importantes.

Desempeño, cumplimiento de estándares o leyes,
atributos de calidad (confiabilidad, disponibilidad,
seguridad, mantenibilidad, portabilidad), etc.
40
Recomendación Bibliográfica
‡ UML y Patrones, Craig Larman, Sección 6.6

41