Este documento presenta los fundamentos del modelado orientado a objetos en UML. Explica conceptos clave como objetos, clases, atributos, comportamiento, comunicación entre objetos, mensajes y casos de uso. También incluye ejemplos y plantillas para documentar requisitos funcionales usando casos de uso.

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

2. 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

3. … 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

4. … Objetos
Ejemplo de varios objetos relacionados:
Cuenta Corriente 101
Juan
Banco de Valencia
Felipe
Cuenta Corriente 114
4

5. … 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

6. Clases y Objetos
6

7. Comportamiento
Ejemplo de interacción:
Operación 1
Un Objeto
Operación 2
1: Un mensaje
Otro Objeto
7

8. … 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

9. 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

10. 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

11. … 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

12. … 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

13. … Comunicación
Ejemplo con objeto agente:
Servidor 1
2:
Un agente
3:
1:
Servidor 2
Un cliente
13

14. El Concepto de Mensaje
La unidad de comunicación entre objetos se
llama mensaje
1: Mensaje A Objeto 2
Objeto 1
2: Mensaje C
4: Mensaje E
Objeto 4
Objeto 3
3: Mensaje D
14

15. 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

16. UML
Diagrama de Casos de Uso
16

17. 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

18. … 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

19. … 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

20. 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

21. … 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

22. … Casos de Uso: Relaciones
Ejemplo <<include>>:
<<include>>
Reintegro Cuenta Corriente
Verificar Operación
Cliente
<<include>>
Reintegro Cuenta de Crédito
22

23. … 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

24. … Casos de Uso: Relaciones
Ejemplo <<extend>>:
Solicitar Préstamo
Cliente
[Tarjeta Caducada]
<<extend> >
Solic itar N ueva Tarjeta
24

25. … Casos de Uso: Relaciones
Ejemplo <<include>> y <<extend>>:
Ide n f i caci ó
ti n
<<include>>
Transferencia
Cliente
<< exten d>>
Transferencia en Internet
25

26. … Casos de Uso: Relaciones
Otro ejemplo <<include>> y <<extend>>:
Order Product
Supply Customer Data
Arrange Payment
<<include>> <<include>>
<<include>>
the salesperson asks
for the catal og
1 <<extend>>
*
Request Catalog
Salesperson
Place Order
26

27. … 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

28. … Casos de Uso: Relaciones
• Ejemplo de herencia
Reserva por
Agencia
*
*
Reserva de
Billete Aéreo
Cliente
Reserva en
Aerolínea
28

29. 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

30. … 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

31. Ejemplo
Cajero Automático
Sacar Dinero
Realizar
Transferencias
Cliente Sistema Bancario
Depositar Dinero
Administrar Cajero
Operador
31

32. 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

33. 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

34. Ejemplo 2…
Venta por Catálogo
Comprobar Estado
del Pedido
Realizar Pedido Vendedor
Completar Pedido
Empleado
Cliente
Establecer Crédito
Supervisor
34

35. …Ejemplo 2
<<extend>>
Realizar Pedido
Solicitar Catálogo
<<i
nclu
>> de>
ude >
l
nc
<<i
<<in
cl
ude>
Suministrar Datos Realizar Pedido de
Cliente Productos
>
Realizar Pago
Cliente
Vendedor
35

36. 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

37. 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

38. 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

39. …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

40. 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

41. Recomendación Bibliográfica
UML y Patrones, Craig Larman, Sección 6.6
41