Está en la página 1de 218

Desarrollo de Software

Orientado a Objeto usando


UML
Patricio Letelier Torres
letelier@dsic.upv.es

Departamento Sistemas Informáticos y Computación (DSIC)


Universidad Politécnica de Valencia (UPV) - España

1
 www.dsic.upv.es/~uml
Contenido
Introducción
Modelado de Software
UML
Breve Tour por UML
El Paradigma Orientado a Objeto usando UML
Fundamentos del Modelado OO
Requisitos del software
Interacción entre objetos
Clases y relaciones entre clases
Comportamiento de objetos
Componentes
Distribución y despliegue de componentes
Object Constraint Language (OCL)
Proceso de Desarrollo de SW basado en UML
Conclusiones
2
 www.dsic.upv.es/~uml
I
Introducción

3
 www.dsic.upv.es/~uml
Introducción: Modelado de
SW

4
 www.dsic.upv.es/~uml
I. Introducción: Modelado de

Construcción de una casa para SW

“fido”

Puede hacerlo una sola


persona
Requiere:
Modelado mínimo
Proceso simple
Herramientas simples

5
 www.dsic.upv.es/~uml
I. Introducción: Modelado de
SW

Construcción de una casa

Construida eficientemente y en un
tiempo
razonable por un equipo
Requiere:
Modelado
Proceso bien definido
Herramientas más sofisticadas 6
 www.dsic.upv.es/~uml
I. Introducción: Modelado de

Construcción de un SW

rascacielos

7
 www.dsic.upv.es/~uml
I. Introducción: Modelado de
SW

Claves en Desarrollo de SI

Notació
n

Herramient Proces
as o

8
 www.dsic.upv.es/~uml
I. Introducción: Modelado de
SW

Abstracción - Modelado Visual


(MV)
“El modelado captura las
partes esenciales del
sistema”
Orde
n

I
tem

enví
o
Proceso de
Negocios
Sistema
Computacional
9
 www.dsic.upv.es/~uml
I. Introducción: Modelado de
SW

II. Notación (Visual) - Beneficios


Manejar la complejidad

Interface de Usuario
(Visual Basic,
Java, ..)
Lógica del Negocio
(C++, Java, ..)

Múltiples Sistemas

Servidor de BDs
(C++ & SQL, ..)

Modelar el sistema independientemente


el lenguaje de implementación” Componentes
Reutilizados

Promover la Reutilización
10
 www.dsic.upv.es/~uml
Introducción: UML

11
 www.dsic.upv.es/~uml
I. Introducción:
UML

¿Qué es UML?
UML = Unified Modeling Language
Un lenguaje de propósito general para el modelado orientado
a objetos. Impulsado por el Object Management Group (OMG,
www.omg.org)

Documento “OMG Unified Modeling Language Specification”


UML combina notaciones provenientes desde:
Modelado Orientado a Objetos
Modelado de Datos
Modelado de Componentes
Modelado de Flujos de Trabajo (Workflows)

12
 www.dsic.upv.es/~uml
I. Introducción:
UML

Situación de Partida
Diversos métodos y técnicas OO, con muchos
aspectos en común pero utilizando distintas
notaciones
Inconvenientes para el aprendizaje, aplicación,
construcción y uso de herramientas, etc.
Pugna entre distintos enfoques (y correspondientes
gurús)

Establecer una notación estándar

13
 www.dsic.upv.es/~uml
I. Introducción:
UML

Historia de UML
Comenzó como el “Método Unificado”, con
la participación de Grady Booch y Jim
Rumbaugh. Se presentó en el OOPSLA’95
El mismo año se unió Ivar Jacobson. Los
“Tres Amigos” son socios en la compañía
Rational Software. Herramienta CASE
Rational Rose

14
 www.dsic.upv.es/~uml
I. Introducción:
UML

Historia de UML
2 UML
005 2.0
?
20 UML
03 1.5
20 UML
00 1.4
19 UML Revisiones menores
99 1.3
19 UML
98 1.2
Nov UML aprobado
‘97 por el OMG

15
 www.dsic.upv.es/~uml
I. Introducción:
UML

Participantes en UML 1.0


Rational Software MCI Systemhouse
(Grady Booch, Jim Rumbaugh Microsoft
y Ivar Jacobson)
Digital Equipment ObjecTime
Hewlett-Packard Oracle Corp.
i-Logix (David Harel) Platinium Technology
IBM Sterling Software
ICON Computing Taskon
(Desmond D’Souza)
Texas Instruments
Intellicorp and James
Martin & co. (James Odell) Unisys

16
 www.dsic.upv.es/~uml
UML “aglutina” enfoques
I. Introducción:
UML

OO
Rumbaug
Booch h Jacobson

Odell
Meyer
Pre- and Post-conditions

Shlaer-Mellor UM
Object life cycles
L Harel
State Charts
Gamma et.
al. notespatterns,
Frameworks,

Embl Wirfs-
y
Singleton classes
Fusion Brock
Responsabilities

Operation descriptions,
message numbering
17
 www.dsic.upv.es/~uml
I. Introducción:
UML

Aspectos Novedosos
Definición semi-formal del Metamodelo de UML

Mecanismos de Extensión en UML:


Stereotypes
Constraints
Tagged Values

Permiten adaptar los elementos de modelado,


asignándoles una semántica particular

18
 www.dsic.upv.es/~uml
I. Introducción:
UML

Inconvenientes en UML
Definición del proceso de desarrollo usando UML. UML
no es una metodología

No cubre todas las necesidades de especificación de un


proyecto software. Por ejemplo, no define los
documentos textuales

Ejemplos aislados

“Monopolio de conceptos, técnicas y métodos en torno a


UML y el OMG”

19
 www.dsic.upv.es/~uml
I. Introducción:
UML

Perspectivas de UML
UML es el lenguaje de modelado orientado a objetos
estándar predominante ahora y en los próximos años
Razones:
Participación de metodólogos influyentes
Participación de importantes empresas
Estándar del OMG
Evidencias:
Herramientas que proveen la notación UML
“Edición” de libros (más de 300 en www.amazon.com)
Congresos, cursos, “camisetas”, etc.

20
 www.dsic.upv.es/~uml
II
Breve Tour por UML

21
 www.dsic.upv.es/~uml
II. Breve Tour por
UML

Modelos y Diagramas
Un modelo captura una vista de un sistema del
mundo real. Es una abstracción de dicho sistema,
considerando un cierto propósito. Así, el modelo
describe completa-mente aquellos aspectos del
sistema que son relevantes al propósito del modelo,
y a un apropiado nivel de detalle.

Diagrama: una representación gráfica de una


colección de elementos de modelado, a menudo
dibujada como un grafo con vértices conectados por
arcos
22
 OMG UML 1.4 Specification
www.dsic.upv.es/~uml
II. Breve Tour por
UML

... Modelos y Diagramas


Un proceso de desarrollo de software debe ofrecer un
conjunto de modelos que permitan expresar el producto
desde cada una de las perspectivas de interés

El código fuente del sistema es el modelo más detallado


del sistema (y además es ejecutable). Sin embargo, se
requieren otros modelos ...

Cada modelo es completo desde su punto de vista del


sistema, sin embargo, existen relaciones de trazabilidad
entre los diferentes modelos
23
 www.dsic.upv.es/~uml
II. Breve Tour por
UML

Diagramas de UML 1.5

Diagrama de Casos de Uso

Diagrama de Clases

Diagrama de Objetos

Diagramas de Comportamiento
Diagrama de Estados

Diagrama de Actividad

Diagramas de Interacción
Diagrama de Secuencia

Diagrama de Colaboración

Diagramas de implementación
Diagrama de Componentes

Diagrama de Despliegue
24
 www.dsic.upv.es/~uml
II. Breve Tour por
UML

... Diagramas de UML


Los diagramas expresan
gráficamente
partes de un modelo
State
State
Diagrama
Use Case
Diagrama Diagrams
Use Case Diagrams
s de State
Use Case
Diagrama Diagrams
s de Clases State
Diagrama
Use Case Diagrams Diagrams
Diagrams
s de Casos de Diagrams
s de
Diagrams Uso Objetos
Secuenci
a
Scenario
Diagrama State
Diagrama
Scenario State
Diagrams
s de Diagrams
s de
Diagrams Diagrams
Colaborac Model Compone
ión os ntes
Scenario Diagrama
Component
Scenario
Diagrama Component
s de
Diagrams
Diagrams Diagrams
Diagrams
s de Diagrama Distribuci
Estados s de ón
Actividad 25
 www.dsic.upv.es/~uml
II. Breve Tour por
UML

Organización de Modelos
4+1 vistas de Kruchten (1995)

Vista de
Vista
Lógica Vista de Realizació
los n
Casos de
Uso Vista de
Vista de Distribució
Procesos n

Este enfoque sigue el browser de


Rational Rose
 www.dsic.upv.es/~uml
26
II. Breve Tour por
UML

... Organización de Modelos

Propuesta de Rational Unified Process (RUP)

M. de Casos de Uso del Negocio (Business Use-Case Model)


M. de Objetos del Negocio (Business Object Model)
M. de Casos de Uso (Use-Case Model)
M. de Análisis (Analysis Model)
M. de Diseño (Design Model)
M. de Despliegue (Deployment Model)
M. de Datos (Data Model)
M. de Implementación (Implementation Model)
M. de Pruebas (Test Model)

27
 www.dsic.upv.es/~uml
II. Breve Tour por
UML

Paquetes en UML
Los paquetes ofrecen un mecanismo general
para la organización de los
modelos/subsistemas agrupando elementos
de modelado

Se representan gráficamente como:

Nombre de
paquete

28
 www.dsic.upv.es/~uml
II. Breve Tour por
UML

… Paquetes en UML
Cada paquete corresponde a un submodelo
(subsistema) del modelo (sistema)

Un paquete puede contener otros paquetes, sin


límite de anidamiento pero cada elemento
pertenece a (está definido en) sólo un paquete

Una clase de un paquete puede aparecer en otro


paquete por la importación a través de una relación
de dependencia entre paquetes

29
 www.dsic.upv.es/~uml
II. Breve Tour por
UML

… Paquetes en UML

Todos los elementos no son


necesariamente visibles desde
el exterior del paquete, es
decir, un paquete encapsula a
la vez que agrupa

El operador “::” permite


designar una clase definida en
un contexto distinto del actual

30
 www.dsic.upv.es/~uml
II. Breve Tour por
UML

...Paquetes en Rational Rose


Customers

Otra Cl ase
Customers

CheckingAccount
<<access>> (f rom Banking)

Banking Banking

CheckingAccount

31
 www.dsic.upv.es/~uml
II. Breve Tour por
UML

… Paquetes en UML

Práctica 1

32
 www.dsic.upv.es/~uml
II. Breve Tour por
UML

Diagrama de Casos de Uso

capturar información respecto de los servicios que u

oque orientado a objeto, es una técnica para captura

33
 www.dsic.upv.es/~uml
II. Breve Tour por
UML

… Ejemplos
Ejempl
o:
Retirar dinero

Consult ar E xt ract o
Cliente

Realizar transferencia
Práctica 2

34
 www.dsic.upv.es/~uml
II. Breve Tour por
UML

Diagrama de Secuencia

: WInP réstamos :Socio :Video : Préstamo


: Encargado

prestar(video, socio)
verificar situación socio

verificar situación video

registrar préstamo

entregar recibo

35
 www.dsic.upv.es/~uml
II. Breve Tour por
UML

Diagrama de Colaboración
:Socio

:Video

2: verificar situación socio

1: prestar(video, socio) 3: verificar situación video


:WInPréstamos

5: entregar recibo
: Encargado 4: registrar préstamo

:Préstamo

Práctica 3

36
 www.dsic.upv.es/~uml
II. Breve Tour por
UML

Diagrama de Clases
diagrama principal para el análisis y diseño del sistema
nta las clases del sistema con sus relaciones estructura
e definiciones para atributos y operaciones
ebería aportar información para establecer las clases, ob

37
 www.dsic.upv.es/~uml
II. Breve Tour por
UML

Ejemplos (Clase y Visibilidad)

A lum no
DN I : c har[10]
núm ero_ex p : int
nom bre : c har[50]

alta()
poner_nota(as ignatura : c har *, año : int, nota : float)
m atric ular(c urs os : as ignatura, año : int)
lis tar_ex pediente()

38
 www.dsic.upv.es/~uml
II. Breve Tour por
UML

… Ejemplos (Asociación)

dirige direc tor


Departam ento Profes or

0..1 1

39
 www.dsic.upv.es/~uml
II. Breve Tour por

… Ejemplos (Clase
UML

Asociación)

empleador trabajadores
Empresa Empleado
* 1..*

Cargo
superior
nombre
sueldo 0..1

subordinado 1..*

40
 www.dsic.upv.es/~uml
II. Breve Tour por
UML

… Ejemplos (Generalización)

Trabajador

{ disjunta, completa }

Directivo Administrativo Obrero

41
 www.dsic.upv.es/~uml
II. Breve Tour por
UML

… Ejemplos
Motor Piloto Vendedor de billetes

1..4 1..2 1

1 n
n
1 n 1 n
Avión Vuelo Reserva

n
{ disjunta, completa }

Avión militar Avión comercial Línea aérea

{ disjunta, completa }

Prácticas 4
Avión de carga Avión de pasajeros

42
 www.dsic.upv.es/~uml
II. Breve Tour por
UML

Diagrama de Estados

alta baja

núm er o_prés tam os = 0


sin pr éstam os

Socio
número : int
nombre : char[50]
número_prestamos : int = 0
pres tar devol ver [ núm ero_p rést amo s = 1 ]
alta()
baja()
prestar(código_libro : int, fecha : date)
devolver(código_libro : int, fecha : date) núm ero_prés tam os > 0

c on prés tam os

pres tar

devolver[ núm ero_prés tam os > 1 ]

43
 www.dsic.upv.es/~uml
II. Breve Tour por
UML

Diagrama de Actividad
Buscar Bebida [ no hay café ] [ no zumo ]

[ hay café ]
[ hay zumo ]

Poner café Añadir agua Coger taza


en filtro al depósito Coger
zumo

Poner filtro
en máquina

Encender
máquina

/ cafetera.On

C afé en
preparación

indicador de fin
Servir café Beber

Práctica 5 44
 www.dsic.upv.es/~uml
II. Breve Tour por
UML

Diagrama Componentes
Interfaz de Terminal
Control y Análisis

Gestión de Cuentas Rutinas de conexión Acceso a BD

45
 www.dsic.upv.es/~uml
II. Breve Tour por
UML

Diagrama de Despliegue
Servidor Central Control y Análisis

Acceso a BD Comment

Comment

Rutinas de Coneccion
Comment

Terminal de Consulta
Interfaz de Terminal
Rutinas de Coneccion
Comment Comment

Punto de Venta
Rutinas de Coneccion
Comment

Gestión de Cuentas Interfaz de Terminal

Comment Comment

46
 www.dsic.upv.es/~uml
II. Breve Tour por

Diagrama de Despliegue en
UML

Rational C ontrol y Análisis

Acceso a BD
Servidor Central
Component Diagram:
Components / Servidor Rutinas de conexión

Central
Servidor Central

Rutinas de conexión
Punto de Venta
Punto de Venta Terminal de
Consulta Gestión de Cuentas Interfaz de Terminal

Terminal de Consulta
Rutinas de conexión Interfaz de Terminal
Component Diagram: Component Diagram:
Components / Punto de Components / Terminal
Venta de Consulta

Práctica 6

47
 www.dsic.upv.es/~uml
II. Breve Tour por
UML

Resumen

expresa como diagramas sirven para representar modelos/s

os problemas pueden modelarse usando alrededor del 20

48
 www.dsic.upv.es/~uml
III
El Paradigma
Orientado a Objeto

49
 www.dsic.upv.es/~uml
¿Por qué la Orientación a III. El Paradigma
OO

Objetos?
Proximidad de los conceptos de modelado
respecto de las entidades del mundo real
Mejora captura y validación de requisitos
Acerca el “espacio del problema” y el “espacio de la
solución”

Modelado integrado de propiedades estáticas


y dinámicas del ámbito del problema
Facilita construcción, mantenimiento y reutilización

50
 www.dsic.upv.es/~uml
¿Por qué la Orientación a III. El Paradigma
OO

Objetos?

Conceptos comunes de modelado durante el


análisis, diseño e implementación

Facilita la transición entre distintas fases


Favorece el desarrollo iterativo del sistema
Disipa la barrera entre el “qué” y el “cómo”

Sin embargo, existen problemas ...

51
 www.dsic.upv.es/~uml
III. El Paradigma
OO

Problemas en OO

dos décadas, pero su aceptación todavía no está tan extend

rista, como inicialmente se pretendía. Esta práctica ha sido p

--Wolfgang Strigel

52
 www.dsic.upv.es/~uml
III. El Paradigma
OO

… Problemas en OO
Un objeto contiene datos y operaciones que operan sobre los
datos, pero ...
Podemos distinguir dos tipos de objetos degenerados:
Un objeto sin datos (que sería lo mismo que una biblioteca de
funciones)
Un objeto sin “operaciones”, con sólo operaciones del tipo
crear, recuperar, actualizar y borrar (que se correspondería
con las estructuras de datos tradicionales)
Un sistema construido con objetos degenerados no es un
sistema verdaderamente orientado a objetos

“Las aplicaciones de gestión están


constituidas
 www.dsic.upv.es/~uml
mayoritariamente por objetos 53
Fundamentos de Modelado
OO

54
 www.dsic.upv.es/~uml
III. El Paradigma OO: Fundamentos de
Modelado OO

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)

55
 www.dsic.upv.es/~uml
III. El Paradigma OO: Fundamentos de
Modelado OO

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

Otro objeto

Un objeto

Otro objeto más

56
 www.dsic.upv.es/~uml
III. El Paradigma OO: Fundamentos de
Modelado OO

… Objetos
Ejemplo de varios objetos relacionados:

Cuenta Corriente 101


Juan

Banco de Valencia

Felipe
Cuenta Corriente 114

57
 www.dsic.upv.es/~uml
III. El Paradigma OO: Fundamentos de
Modelado OO

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

58
 www.dsic.upv.es/~uml
III. El Paradigma OO: Fundamentos de
Modelado OO

Clases y Objetos

59
 www.dsic.upv.es/~uml
III. El Paradigma OO: Fundamentos de
Modelado OO

Comportamiento
Ejemplo de interacción:

Un Objeto Operación 1

1: Un mensaje Operación 2

Otro Objeto

60
 www.dsic.upv.es/~uml
III. El Paradigma OO: Fundamentos de
Modelado OO

… 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

61
 www.dsic.upv.es/~uml
III. El Paradigma OO: Fundamentos de
Modelado OO

Persistencia
La persistencia de los objetos designa la
capacidad de un objeto 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

62
 www.dsic.upv.es/~uml
III. El Paradigma OO: Fundamentos de
Modelado OO

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

63
 www.dsic.upv.es/~uml
III. El Paradigma OO: Fundamentos de
Modelado OO

… 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

64
 www.dsic.upv.es/~uml
III. El Paradigma OO: Fundamentos de
Modelado OO

… 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

65
 www.dsic.upv.es/~uml
III. El Paradigma OO: Fundamentos de
Modelado OO

… Comunicación
Ejemplo con objeto agente:

Servidor 1
2:

Un agente

1: 3:

Un cliente Servidor 2

66
 www.dsic.upv.es/~uml
III. El Paradigma OO: Fundamentos de
Modelado OO

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

67
 www.dsic.upv.es/~uml
III. El Paradigma OO: Fundamentos de
Modelado OO

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

Tipos de flujo de control:


Llamada a procedimiento o flujo de control anidado
Flujo de control plano
Retorno de una llamada a procedimiento
Otras variaciones
Esperado (balking)
Cronometrado (time-out)

68
 www.dsic.upv.es/~uml
III. El Paradigma OO:
Requisitos

Requisitos del software

69
 www.dsic.upv.es/~uml
III. El Paradigma OO:
Requisitos

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
Comparación con respecto a los Diagramas de
Flujo de Datos del Enfoque Estructurado

70
 www.dsic.upv.es/~uml
III. El Paradigma OO:
Requisitos

… Casos de Uso
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 que participan en el mismo

El usuario debería poder entenderlos para


realizar su validación

71
 www.dsic.upv.es/~uml
III. El Paradigma OO:
Requisitos

… Casos de Uso
Ejemplo:

Caso de Uso A
Actor A

Caso de Uso B
Actor B

72
 www.dsic.upv.es/~uml
III. El Paradigma OO:
Requisitos

… 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

73
 www.dsic.upv.es/~uml
III. El Paradigma OO:
Requisitos

… 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

74
 www.dsic.upv.es/~uml
III. El Paradigma OO:
Requisitos

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

75
 www.dsic.upv.es/~uml
… Casos de Uso:
III. El Paradigma OO:
Requisitos

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>>
76
 www.dsic.upv.es/~uml
… Casos de Uso:
III. El Paradigma OO:
Requisitos

Relaciones
Ejemplo <<include>>:

<<include>>
Reintegro Cuenta Corriente

Cliente Verificar Operación

<<include>>

Reintegro Cuenta de Crédito

77
 www.dsic.upv.es/~uml
… Casos de Uso:
III. El Paradigma OO:
Requisitos

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

78
 www.dsic.upv.es/~uml
… Casos de Uso:
III. El Paradigma OO:
Requisitos

Relaciones
Ejemplo <<extend>>:

Solicitar Préstamo
Cliente

[Tarjeta Caducada]

<<extend> >

Solic itar N ueva Tarjeta

79
 www.dsic.upv.es/~uml
… Casos de Uso:
III. El Paradigma OO:
Requisitos

Relaciones
Ejemplo <<include>> y <<extend>>:

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

Transferencia
Cliente

<< exten d>>

Transferencia en Internet
80
 www.dsic.upv.es/~uml
… Casos de Uso:
III. El Paradigma OO:
Requisitos

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

81
 www.dsic.upv.es/~uml
… Casos de Uso:
III. El Paradigma OO:
Requisitos

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

82
 www.dsic.upv.es/~uml
Casos de Uso:
III. El Paradigma OO:
Requisitos

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?

83
 www.dsic.upv.es/~uml
… Casos de Uso:
III. El Paradigma OO:
Requisitos

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é ejecuciones alternativas
se presentan en el caso de uso?

Práctica 7

84
 www.dsic.upv.es/~uml
III. El Paradigma OO:
Identificador CU-<id-requisito> Requisitos
Nombre <nombre del requisito funcional>
á comportarse
Descripción
tal como se describe en el siguiente caso de uso { concreto cuando <evento de activación> , abstracto durante la realiza

Precondición <precondició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 CU-x>

2 <actor> , el sistema} <acción realizada por el actor o sistema>>, se realiza el caso de uso < caso
Si <condición>, {el

… …

Postcondición <postcondición del caso de uso>


Excepciones Paso Acción
Si <condición 1de excepción>,{el <actor> , el sistema} }<acción realizada por el actor o sistema>>, se realiza el c
< caso de uso CU-x>, a continuación este caso de uso {continua, aborta}

… …

Rendimiento Paso Cota de tiempo

1 n segundos

… …

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


Importancia {sin importancia, importante, vital}
Urgencia {puede esperar, hay presión, inmediatamente}
Comentarios <comentarios adicionales>
85
 www.dsic.upv.es/~uml
III. El Paradigma OO:
Requisitos

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.
86
 www.dsic.upv.es/~uml
Interacción entre objetos

87
 www.dsic.upv.es/~uml
III. El Paradigma OO: Interacción entre
objetos

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

88
 www.dsic.upv.es/~uml
III. El Paradigma OO: Interacción entre
objetos

Mensajes

Sintaxis para mensajes:


predecesor / guarda secuencia: retorno
:= msg(args)

89
 www.dsic.upv.es/~uml
III. El Paradigma OO: Interacción entre
objetos

Diagramas de interacción
El Diagrama de Secuencia es más
adecuados 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)
90
 www.dsic.upv.es/~uml
III. El Paradigma OO: Interacción entre
objetos

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

91
 www.dsic.upv.es/~uml
III. El Paradigma OO: Interacción entre
objetos

… Diagrama de Secuencia

92
 www.dsic.upv.es/~uml
III. El Paradigma OO: Interacción entre
objetos

… Diagrama de Secuencia
Caller Exchange Receiver

a: lift receiver

{b.receiveTime b: dial tone


- a.sendTime < 1 sec.}

{c.receiveTime c: dial digit


-b.sendTime < 10 sec.}

...
The call is routed d: route
through the network

{d.receiveTime ringing tone phone rings


-d.sendTime < 5 sec.}

answer phone -----


< 1 sec
At this point the stop tone stop ringing -----
parties can talk

93
 www.dsic.upv.es/~uml
III. El Paradigma OO: Interacción entre
objetos

Diagrama de Secuencia
mostrando foco de control,
condiciones, recursividad
creación y destrucción
de objetos

94
 www.dsic.upv.es/~uml
III. El Paradigma OO: Interacción entre
objetos

ob3 : C3 ob4 : C4

op( ) ob1 : C1

[x>0] fool(x) ob2 : C2


[x<0] bar(x)
doit(z)
doit(w)

more( )

95
 www.dsic.upv.es/~uml
III. El Paradigma OO: Interacción entre
objetos

… Diagrama de Secuencia
Diagram 1 Diagram 2
ob1 : C1 ob3 : C3 ob4 : C4
[x<0] bar(x)

bar(x)
doit(w)
Sequence Diagram:
Diagrams / Diagram 2
Sequence Diagram:
Diagrams / Diagram 1

96
 www.dsic.upv.es/~uml
III. El Paradigma OO: Interacción entre
objetos

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

97
 www.dsic.upv.es/~uml
III. El Paradigma OO: Interacción entre
objetos

Mensajes
Un mensaje desencadena una acción en el
objeto destinatario

Un mensaje se envía si han sido enviados los


mensajes de una lista (sincronización):

A.1, B.3 / 1:Mensaje B

98
 www.dsic.upv.es/~uml
III. El Paradigma OO: Interacción entre
objetos

… Mensajes
Un mensaje se envía de manera
condicionada:

[x>y] 1: Mensaje
B

99
 www.dsic.upv.es/~uml
III. El Paradigma OO: Interacción entre
objetos

… Mensajes
Un mensaje que devuelve un resultado:

1: distancia:=
mover(x,y) B

Práctica 8

100
 www.dsic.upv.es/~uml
Clases y relaciones
entre clases

101
 www.dsic.upv.es/~uml
III. El Paradigma OO: Clases y relaciones entre
clases

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

102
 www.dsic.upv.es/~uml
III. El Paradigma OO: Clases y relaciones entre
clases

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

103
 www.dsic.upv.es/~uml
III. El Paradigma OO: Clases y relaciones entre
clases

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

Motocicleta
color
cilindrada
velocidad máxima

arrancar()
acelerar()
frenar()
104
 www.dsic.upv.es/~uml
III. El Paradigma OO: Clases y relaciones entre
clases

Clases: Notación Gráfica


Otros ejemplos:

lista
pila
primero()
apilar()
ultimo()
desapilar()
añadir() cardinalidad()
quitar()
cardinalidad()

105
 www.dsic.upv.es/~uml
III. El Paradigma OO: Clases y relaciones entre
clases

Clases: Encapsulación
La encapsulación presenta dos ventajas básicas:
Se protegen los datos de accesos indebidos
El acoplamiento entre las clases se disminuye
Favorece la modularidad y el mantenimiento

Los atributos de una clase no deberían ser


manipulables directamente por el resto de objetos

106
 www.dsic.upv.es/~uml
III. El Paradigma OO: Clases y relaciones entre
clases

… Clases: Encapsulación
Los niveles de encapsulación están heredados de los
niveles de C++:

(-) Privado : es el más fuerte. Esta parte es totalmente


invisible (excepto para clases friends en terminología
C++)

(#) Los atributos/operaciones protegidos están visibles


para las clases friends y para las clases derivadas de la
original

(+) Los atributos/operaciones públicos son visibles a


otras clases (cuando se trata de atributos se está
transgrediendo el principio de encapsulación)

107
 www.dsic.upv.es/~uml
III. El Paradigma OO: Clases y relaciones entre
clases

… Clases: Encapsulación
Ejemplo:

Reglas de visibilidad
Atributo público : Integer
Atributo protegido : Integer
Atributo privado : Integer

"Operación pública"()
"Operación protegida"()
"Operación privada"()

108
 www.dsic.upv.es/~uml
III. El Paradigma OO: Clases y relaciones entre
clases

Relaciones entre Clases


Los enlaces entre de objetos pueden
representarse entre las respectivas clases

Formas de relación entre clases:

Asociación y Agregación (vista como un caso


particular de asociación)
Generalización/Especialización

Las relaciones de Agregación y Generalización


forman jerarquías de clases

109
 www.dsic.upv.es/~uml
III. El Paradigma OO: Clases y relaciones entre
clases

Asociación
La asociación expresa una conexión bidireccional
entre objetos
Una asociación es una abstracción de la relación
existente en los enlaces entre los objetos

Univ. de Murcia : Universidad Un enlace Antonio : Estudiante

Universidad Estudiante
Una asociación

110
 www.dsic.upv.es/~uml
III. El Paradigma OO: Clases y relaciones entre
clases

… Asociación
Ejemplo:
marido

casado-con

0..1
mujer
0..1 Persona Compañía
nombre * trabaja-para nombre
s.s. dirección
emplea-a *
0.. 1
jefe

*
Administra

empleado

111
 www.dsic.upv.es/~uml
III. El Paradigma OO: Clases y relaciones entre
clases

… Asociación
Especificación de multiplicidad
(mínima...máxima)
1 Uno y sólo uno
0..1 Cero o uno
M..N Desde M hasta N (enteros
naturales)
* Cero o muchos
0..* Cero o muchos
1..* Uno o muchos (al menos
uno)

 La multiplicidad mínima >= 1 establece


www.dsic.upv.es/~uml
112
III. El Paradigma OO: Clases y relaciones entre
clases

Asociación Cualificada
Aerolínea Viajero
* 0..1
nro_billete

Tablero Cuadro
fila 1 1
Ajedrez
columna

Reduce la multiplicidad del rol opuesto al considerar el valor


del cualificador

113
 www.dsic.upv.es/~uml
III. El Paradigma OO: Clases y relaciones entre
clases

Agregación
La agregación representa una relación
parte_de entre objetos
En UML se proporciona una escasa
caracterización de la agregación
Puede ser caracterizada con precisión
determinando las relaciones de
comportamiento y estructura que existen
entre el objeto agregado y cada uno de sus
objetos componentes

114
 www.dsic.upv.es/~uml
III. El Paradigma OO: Clases y relaciones entre
clases

Ejemplos
Window
scrollbar[2] : Slider
title : Header
body : Panel

Window

1 1
1

scrollbar
2 title 1 body 1
Slider Header Panel

115
 www.dsic.upv.es/~uml
III. El Paradigma OO: Clases y relaciones entre
clases

... Ejemplos
Member-of * Committee
Person *

{ subset }
1 Chair-of *
Represents an
incorporated entity.

worker Person employee employer Company


0..1
* *
0..1

boss
{Person.employer =
Person.boss.employer}

116
 www.dsic.upv.es/~uml
III. El Paradigma OO: Clases y relaciones entre
clases

… Ejemplos
Polígono Punto
Agregaci 1 contiene
3..*
{ordenado}
ón
Persona
*
Cuenta *
or Asociación
* Empresa excluyente
1

Usuario está-autorizado-en Estación


* *

Autorización
Clase de prioridad
privilegios
asociación
camb_privil()
117
 www.dsic.upv.es/~uml
III. El Paradigma OO: Clases y relaciones entre
clases

Clases y Objetos
Diagrama de Clases y Diagramas 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 instanciadas

118
 www.dsic.upv.es/~uml
III. El Paradigma OO: Clases y relaciones entre
clases

Generalización
Permite gestionar la complejidad mediante
un ordenamiento taxonómico de clases
Se obtiene usando los mecanismos de
abstracción de Generalización y/o
Especialización
La Generalización consiste en factorizar las
propiedades comunes de un conjunto de
clases en una clase más general

119
 www.dsic.upv.es/~uml
III. El Paradigma OO: Clases y relaciones entre
clases

... Generalización
Nombres usados: clase padre - clase hija.
Otros nombres: superclase - subclase,
clase base - clase derivada

Las subclases heredan propiedades de


sus clases padre, es decir, atributos y
operaciones (y asociaciones) de la clase
padre están disponibles en sus clases
hijas

120
 www.dsic.upv.es/~uml
III. El Paradigma OO: Clases y relaciones entre
clases

... Generalización
Vehículo

Veihículo Terrestre Vehículo Aéreo

Coche Camión Avión Helicóptero

121
 www.dsic.upv.es/~uml
III. El Paradigma OO: Clases y relaciones entre
clases

... Generalización
La especialización es una técnica muy eficaz
para la extensión y reutilización

Coche

Funcionando Est ropeado

Restricciones predefinidas en UML:


disjunta - no disjunta
total (completa) - parcial (incompleta)
122
 www.dsic.upv.es/~uml
III. El Paradigma OO: Clases y relaciones entre
clases

... Generalización
La noción de clase está próxima a la de
conjunto

Dada una clase, podemos ver el conjunto


relativo a las instancias que posee o bien
relativo a las propiedades de la clase

Generalización y especialización expresan


relaciones de inclusión entre conjuntos

123
 www.dsic.upv.es/~uml
III. El Paradigma OO: Clases y relaciones entre
clases

... Generalización
Particionamiento del espacio de objetos
=> Clasificación Estática

Particionamiento del espacio de estados


de los objetos => Clasificación Dinámica

En ambos casos se recomienda


considerar
generalizaciones/especializaciones
disjuntas

124
 www.dsic.upv.es/~uml
III. El Paradigma OO: Clases y relaciones entre
clases

... Generalización
Un ejemplo de Clasificación Estática:

Ve hícu lo Aéreo

{ estática
}

Avión Helicóptero

125
 www.dsic.upv.es/~uml
III. El Paradigma OO: Clases y relaciones entre
clases

... Generalización
Un ejemplo de Clasificación Dinámica:

Coche

{
dinámica
}
Funcionando Est ropeado

126
 www.dsic.upv.es/~uml
III. El Paradigma OO: Clases y relaciones entre
clases

... Generalización
Extensión: Posibles instancias de una
clase

Intensión: Propiedades definidas en una


clase
A

int(A) ⊆ int(B)

ext(B) ⊆
B ext(A)

127
 www.dsic.upv.es/~uml
III. El Paradigma OO: Clases y relaciones entre
clases

... Generalización
Clasificación Estática

C0
ext(C0) = ∪ ext(Ci) ⇒ completa
{ static
}
ext(Ci) ∩ ext(Cj) = ∅ ⇒ disjunta

C1 Cn

128
 www.dsic.upv.es/~uml
III. El Paradigma OO: Clases y relaciones entre
clases

... Generalización
Clasificación Dinámica

C0
ext(C0) = ∪ ext(Ci) ⇒ completa

{ extt(Ci) ∩ extt(Cj) = ∅ ⇒ disjunta en t


dinámica
} extt1(Ci) ∩ extt2(Cj) ≠ ∅ ⇒ posiblemente
no disjunta en
C1 Cn diferentes
instantes

129
 www.dsic.upv.es/~uml
III. El Paradigma OO: Clases y relaciones entre
clases

... Generalización
Ejemplo: varias especializaciones a partir de
la misma clase padre, usando
discriminadores:
Comercia Militar
l

uso

Vehículo Aéreo

estructura

Avión Helicóptero
130
 www.dsic.upv.es/~uml
III. El Paradigma OO: Clases y relaciones entre
clases
Clasificación Múltiple (herencia
múltiple)
Se presenta cuando una subclase tiene más de
una superclase

La herencia múltiple debe manejarse con


precaución. Algunos problemas son el conflicto
de nombre y el conflicto de precedencia

Se recomienda un uso restringido y disciplinado


de la herencia. Java y Ada 95 simplemente no
ofrecen herencia múltiple

131
 www.dsic.upv.es/~uml
III. El Paradigma OO: Clases y relaciones entre
clases

… Herencia Múltiple
Uso disciplinado de la herencia múltiple:
clasificaciones disjuntas con clases padre en
hojas de jerarquías alternativas
Bípedo Cuadrúpedo

nro patas nro patas

Con Pelos Herbívoro

cubertura comida

Animal
Con Plumas cobertura
comida
cobertura Carnívoro

Con Escamas

Conejo

132
 www.dsic.upv.es/~uml
III. El Paradigma OO: Clases y relaciones entre
clases

Principio de Sustitución
El Principio de Sustitución de Liskow
afirma que:

“Debe ser posible utilizar cualquier


objeto instancia de una subclase en el
lugar de cualquier objeto instancia de
su superclase sin que la semántica del
programa escrito en los términos de la
superclase se vea afectado.”

133
 www.dsic.upv.es/~uml
III. El Paradigma OO: Clases y relaciones entre
clases

… Principio de Sustitución
Dado que los programadores pueden
introducir código en las subclases
redefiniendo las operaciones, es posible
introducir involuntaria-mente incoherencias
que violen el principio de sustitución

El polimorfismo que veremos a continuación


no debería implementarse sin este principio

134
 www.dsic.upv.es/~uml
III. El Paradigma OO: Clases y relaciones entre
clases

Polimorfismo
El término polimorfismo se refiere a que
una característica de una clase puede
tomar varias formas
El polimorfismo representa en nuestro caso
la posibilidad de desencadenar operaciones
distintas en respuesta a un mismo mensaje
Cada subclase hereda las operaciones pero
tiene la posibilidad de modificar localmente
el comportamiento de estas operaciones

135
 www.dsic.upv.es/~uml
III. El Paradigma OO: Clases y relaciones entre
clases

… Polimorfismo
Ejemplo: todo animal duerme, pero cada
clase lo hace de forma distinta

Animal
dormir()
?
dorm
ir
?

León Oso Tigre

136
 www.dsic.upv.es/~uml
III. El Paradigma OO: Clases y relaciones entre
clases

… Polimorfismo
Animal Dormir(
){
dormir()
}

León Oso Tigre


dormir() dormir() dormir()

Dormir( Dormir( Dormir(


){ ){ ){
sobre el vientre sobrela espalda en un árbol
} } }

137
 www.dsic.upv.es/~uml
III. El Paradigma OO: Clases y relaciones entre
clases

… Polimorfismo
La búsqueda automática del código que
en cada momento se va a ejecutar es
fruto del enlace dinámico

El cumplimiento del Principio de


Sustitución permite obtener un
comportamiento y diseño coherente

Práctica 9-12

138
 www.dsic.upv.es/~uml
Comportamiento de
objetos

139
 www.dsic.upv.es/~uml
III. El Paradigma OO: Comportamiento de
objetos

Diagrama de Estados
Los Diagramas de Estados representan
autómatas de estados finitos, desde el
p.d.v. de los estados y las transiciones

Son útiles sólo para los objetos con un


comportamiento significativo

El formalismo utilizado proviene de los


Statecharts (Harel)

140
 www.dsic.upv.es/~uml
III. El Paradigma OO: Comportamiento de
objetos

… 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
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 y escenarios son
complementarios

141
 www.dsic.upv.es/~uml
III. El Paradigma OO: Comportamiento de
objetos

… Diagrama de Estados
Los D. de Estados son autómatas jerárquicos
que permiten expresar concurrencia,
sincronización y jerarquías de objetos
Los D. de Estados son grafos dirigidos
Los D. De Estados de UML son 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

142
 www.dsic.upv.es/~uml
III. El Paradigma OO: Comportamiento de
objetos

… Diagrama de Estados
Estados y Transiciones

Evento [condición] / Acción

A B

Tanto el evento como la acción se consideran instantáneos

143
 www.dsic.upv.es/~uml
III. El Paradigma OO: Comportamiento de
objetos

… Diagrama de Estados
Ejemplo de un Diagrama de Estados para
la clase persona:
c ontratar
en el paro en ac tivo

perder em pleo

jubilars e
jubil ars e

jub ilado

144
 www.dsic.upv.es/~uml
III. El Paradigma OO: Comportamiento de
objetos

Acciones
Podemos especificar la solicitud de un
servicio a otro objeto como consecuencia
de la transición:

Evento [condición] / OtroObjeto.Operación

145
 www.dsic.upv.es/~uml
III. El Paradigma OO: Comportamiento de
objetos

… Acciones
Se puede especificar el ejecutar una
acción como consecuencia de entrar,
salir, estar en un estado, o por la
ocurrencia de un evento:

estado A
entry: acción por entrar
exit: acción por salir
do: acción mientras en
estado
on evento: acción

146
 www.dsic.upv.es/~uml
III. El Paradigma OO: Comportamiento de
objetos

Generalización de Estados
Podemos reducir la complejidad de estos
diagramas usando la generalización de
estados
Distinguimos así entre superestado y
subestados
Un estado puede contener varios
subestados disjuntos
Los subestados heredan las variables de
estado y las transiciones externas

147
 www.dsic.upv.es/~uml
III. El Paradigma OO: Comportamiento de
objetos

Generalización de Estados
Ejemplo:

e1
A B

e2
e2

148
 www.dsic.upv.es/~uml
III. El Paradigma OO: Comportamiento de
objetos

Generalización de Estados
Quedaría como:

e1
Aa b
B

e2

149
 www.dsic.upv.es/~uml
… Generalización de
III. El Paradigma OO: Comportamiento de
objetos

Estados
Las transiciones de entrada deben ir hacia
subestados específicos:

e1
Aa Bb

e2

e0

150
 www.dsic.upv.es/~uml
… Generalización de
III. El Paradigma OO: Comportamiento de
objetos

Estados
Es preferible tener estados iniciales de
entrada a un nivel de manera que desde
los niveles superiores no se sepa a qué
subestado se entra:

e1
Aa b
B

e2 C
e0

151
 www.dsic.upv.es/~uml
… Generalización de
III. El Paradigma OO: Comportamiento de
objetos

Estados
La agregación de estados es la
composición de un estado a partir de
varios estados independientes

La composición es concurrente por lo que


el objeto estará en alguno de los estados
de cada uno de los subestados
concurrentes

152
 www.dsic.upv.es/~uml
III. El Paradigma OO: Comportamiento de
objetos

… Generalización de Estados

Ejemplo:

e1
e1

153
 www.dsic.upv.es/~uml
III. El Paradigma OO: Comportamiento de
objetos

… Generalización de Estados
lift receiver
/ get dial
tone

Active

Timeout

do/ play message

after (15 sec.) dial digit( n )[ incomplete ]


after (15 sec.)

DialTone dial digit(n) Dialing


do/ play dial tone
Idle
dial digit (n)[ invalid ]
dial digit( n )[ valid ]
caller hangs up Pinned Invalid / connect
/ disconnect
do/ play message
Connecting
calle e callee
hang hangs
s up up
busy
Busy connected
do/ play busy t one
Talking Ringing
callee answers do/ play ringing tone
/ enable
speech

154
 www.dsic.upv.es/~uml
III. El Paradigma OO: Comportamiento de
objetos

Historia
Por defecto, los autómatas no tienen
memoria
Es posible memorizar el último subestado
visitado para recuperarlo en una
transición entrante en el superestado que
lo engloba

También es posible la memorización para


cualquiera de los subestados anidados
(aparece un * junto a la H)

155
 www.dsic.upv.es/~uml
III. El Paradigma OO: Comportamiento de
objetos

… Historia
Ejemplo:
A

d2
B

in
D x y
out
d1
C

H
*
156
 www.dsic.upv.es/~uml
III. El Paradigma OO: Comportamiento de
objetos

… Historia
Ejemplo:

Enjuague Lavado Secado

cerrar puerta abir puerta

Espera

157
 www.dsic.upv.es/~uml
III. El Paradigma OO: Comportamiento de
objetos

Destrucción del Objeto


La destrucción de un objeto es efectiva
cuando el flujo de control del autómata
alcanza un estado final no anidado

La llegada a un estado final anidado


implica la “subida” al superestado
asociado, no el fin del objeto

158
 www.dsic.upv.es/~uml
III. El Paradigma OO: Comportamiento de
objetos

… Destrucción de Objeto
Ejemplo:

c ras h
E n vuelo

des pegar aterriz ar

Crear(m atric ula)


E n t ier ra

159
 www.dsic.upv.es/~uml
III. El Paradigma OO: Comportamiento de
objetos

Transiciones temporizadas
Las esperas son actividades que tienen
asociada cierta duración

La actividad de espera se interrumpe


cuando el evento esperado tiene lugar
Este evento desencadena una transición
que permite salir del estado que alberga
la actividad de espera. El flujo de control
se transmite entonces a otro estado

160
 www.dsic.upv.es/~uml
III. El Paradigma OO: Comportamiento de
objetos

… Transiciones temporizadas
Ejemplo: A

/ Abrir ranura

esperar dinero después de


30 segundos
entry: Mostrar anular
mensaje
exit: cerrar ranura transacción

Depósito efectuado

161
 www.dsic.upv.es/~uml
III. El Paradigma OO: Comportamiento de
objetos

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

162
 www.dsic.upv.es/~uml
III. El Paradigma OO: Comportamiento de
objetos

Ejemplo (con swim lines)


Pasaj ero Vendedo r Airline

Solicitar
pasaje
Verificar
existencia vuelo
Dar detalles
vue lo
Informar alternativas y
precios
Seleccionar
vuelo

So licitar Reservar
pago plazas
C onfirmar p laza
Pagar reservada
pasaje

Emitir
billete

163
 www.dsic.upv.es/~uml
III. El Paradigma OO: Comportamiento de
objetos

... Ejemplos
Customer Sales Stockroom

Re que st se rvi ce Order


[placed]

Take order Order


[entered]

Play

Fill order

Order Deliver order Order


[deliver ed] [filled]

Collect order

164
 www.dsic.upv.es/~uml
III. El Paradigma OO: Comportamiento de
objetos

... Ejemplos

Calculate [cost < $50] Change customer's


total cost account

[cost >= $50] Get


authorization

165
 www.dsic.upv.es/~uml
Componentes

166
 www.dsic.upv.es/~uml
Diagrama de
III. El Paradigma OO:
Componentes

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

167
 www.dsic.upv.es/~uml
...Diagrama de
III. El Paradigma OO:
Componentes

Componentes
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 Ada, bibliotecas
cargadas dinámicamente, etc.

Las relaciones de dependencia se utilizan


en los diagramas de componentes para
indicar que un componente utiliza los
servicios ofrecidos por otro componente

168
 www.dsic.upv.es/~uml
...Diagrama de
III. El Paradigma OO:
Componentes

Componentes

169
 www.dsic.upv.es/~uml
Distribución y despliegue
de Componentes

170
 www.dsic.upv.es/~uml
III. El Paradigma OO: Distribución y despliegue de
componentes

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

Nodo

171
 www.dsic.upv.es/~uml
III. El Paradigma OO: Distribución y despliegue de
componentes

… Diagrama de Despliegue

Los estereotipos permiten precisar la


naturaleza del equipo:
Dispositivos
Procesadores
Memoria

Los nodos se interconectan mediante


soportes bidireccionales que pueden a su
vez estereotiparse

172
 www.dsic.upv.es/~uml
III. El Paradigma OO: Distribución y despliegue de
componentes

… Diagrama de Despliegue
Ejemplo de conexión entre nodos:

<<Cliente>> <<Servidor>>
Terminal <<TCP/IP>>
Base de
Punto Datos
de Venta

<<RDSI>>
<<RDSI>>
r tipos de nodos y connexiones porContr
estereotipado
ol

173
 www.dsic.upv.es/~uml
III. El Paradigma OO: Distribución y despliegue de
componentes

… Diagrama de Despliegue
Ejemplo:

174
 www.dsic.upv.es/~uml
III. El Paradigma OO: Distribución y despliegue de
componentes

… Diagrama de Despliegue
Ejemplo: Component Diagram:
videoStoreServer
<<Container>>
Component Diagram:
Component Diagram: videoStoreApplication /
Client / Client VideoStoreApplication
VideoStoreApplication
Diagram
Component Diagram:
videoStoreServer /
<<brow ser>>
Client videoStoreServer
OpenSourceBrowser Clien
t

<<AppServer>>
videoStoreServer
<<Session>> <<Entity>>
ShoppingSession Catalog

DBServer

<<Entity>>
ShoppingCart

videoStoreApplicatio
Component Diagram: n
DBServer / DBServer

DBServe
r
VideoStoreDB
175
 www.dsic.upv.es/~uml
III. El Paradigma
OO

Object Constraint
Language
OCL

176
 www.dsic.upv.es/~uml
III. El Paradigma OO:
OCL

¿Qué es OCL?
OCL es un lenguaje formal usado para
describir expresiones acerca de modelos
UML

OCL es parte del estandar UML y fue


desarrollado en IBM
Las evaluación de expresiones OCL no
afecta el estado del sistema en ejecución

177
 www.dsic.upv.es/~uml
III. El Paradigma OO:
OCL

Usos de OCL
Lenguaje de consulta
Especificación de invariantes en clases y tipos
Especificación de invariantes de tipo para
Estereotipos
Describir pre- y post condiciones en Operaciones
y Métodos
Describir Guardas
Especificar destinatarios para mensages y
acciones
Especificar restricciones en Operaciones
Especificar reglas de derivación para atributos

178
 www.dsic.upv.es/~uml
III. El Paradigma OO:
OCL

Ejemplo

179
 www.dsic.upv.es/~uml
III. El Paradigma OO:
OCL

Invariantes
“El número de empleados debe ser mayor que
50”

self.númeroDeEmpleados > 50 (siendo el contexto Company)

context Compañía
inv: self. númeroDeEmpleados > 50

context c:Compañía
inv: c.númeroDeEmpleados > 50

context c:Compañía
inv suficientesEmpleados: c.númeroDeEmpleados > 50

180
 www.dsic.upv.es/~uml
III. El Paradigma OO:
OCL

Pre- Post condiciones


Sintaxis
context NombreTipo::NombreOperación(Param1 : Tipo1, ... ):TipoRetorno
pre parametroOk: param1 > ...
post resultadoOk : result = ...

Ejemplo

context Persona::nómina(fecha : Date) : Integer


post: result = 5000

181
 www.dsic.upv.es/~uml
Valores iniciales y
III. El Paradigma OO:
OCL

derivados
Sintaxis
context NombreTipo::NombreAtributo: Tipo
init: –- alguna expresión representando el valor inicial

context NombreTipo::NombreRolAsociación: Tipo


init: –- alguna expresión representando la regla de derivación

Ejemplo
context Persona::nómina : Integer
init: padres.nómina->sum() * 1%
derive: if menorDeEdad then
padres.nómina->sum() * 1%
else
puesto.sueldo
endif
182
 www.dsic.upv.es/~uml
III. El Paradigma OO:
OCL

Expresiones Let
Ejemplo

context Persona inv:


let ingresos : Integer = self.puesto.sueldo->sum() in
if estáEnParo then
ingresos < 100
else
ingresos >= 100
endif

183
 www.dsic.upv.es/~uml
III. El Paradigma OO:
OCL

Definiciones
Ejemplo

context Persona
def: ingresos : Integer = self.puesto.sueldo->sum()
def: apodo : String = ’Gallito rojo’
def: tieneElTítulo(t : String) : Boolean = self.puesto-
>exists(título = t)

184
 www.dsic.upv.es/~uml
III. El Paradigma OO:
OCL

Navegación
Ejemplos
context Compañía
inv: self.director.estáEnparo = false
inv: self.empleado->notEmpty()

context Compañía
inv:self.director.edad > 40

context Persona
inv:self.empleador->size() < 3

context Persona
inv:self.empleador->isEmpty()

context Persona
inv:self.esposa->notEmpty() implies self.esposa.sexo = Sexo::mujer

185
 www.dsic.upv.es/~uml
III. El Paradigma OO:
OCL

… Navegación
Ejemplo
a) “Los casados tienen al menos 18 años de edad”

context Persona inv:


self.esposa->notEmpty() implies self.esposa.edad >= 18 and
self.esposo->notEmpty() implies self.esposo.edad >= 18

“Una compañía tiene a lo más 50 empleados”

context Companía inv:


self.empleado->size() <= 50

186
 www.dsic.upv.es/~uml
IV
Proceso de Desarrollo
de SW basado en UML

187
 www.dsic.upv.es/~uml
¿Qué es un Proceso de Desarrollo de
IV. Proceso de Desarrollo de SW basado
en UML

SW?
Define Quién debe hacer Qué, Cuándo y Cómo
debe hacerlo

Requisitos Sistema
nuevos nuevo
Proceso de
o Desarrollo o
modificados modificad
de Software
o
No existe un proceso de software universal. Las
características de cada proyecto (equipo de
desarrollo, recursos, etc.) exigen que el proceso
sea configurable
188
 www.dsic.upv.es/~uml
IV. Proceso de Desarrollo de SW basado
en UML

Rational Unified Process (RUP)

Rational Unified Pruebas funcionales


Pruebas de
Process 1 desempeño
998
Gestión de requisitos
Gestión de cambios y
configuración
RationaObjectory Ingeniería de Negocio
l Process
1996- Ingeniería de datos
1997 Diseño de interfaces

Objectory UM
1987- L
Process
1995

Enfoque
Ericsson 189
 www.dsic.upv.es/~uml
IV. Proceso de Desarrollo de SW basado
en UML

Dos
Dimensiones

190
 www.dsic.upv.es/~uml
IV. Proceso de Desarrollo de SW basado
en UML

Fases e Hitos (Milestones)

Inceptio Elaborati Constructi Transitio


n on on n

Objetiv Arquitectur Capacida Release


os a d del
(Vision) Operacion Producto
al
Inicial
tiemp
o

191
 www.dsic.upv.es/~uml
IV. Proceso de Desarrollo de SW basado
en UML

Elementos en RUP
Workflows (Disciplinas)
Workflows Primarios
Business Modeling (Modado del Negocio)
Requirements (Requisitos)
Analysis & Design (Análisis y Diseño)
Implementation (Implementación)
Test (Pruebas)
Deployment (Despliegue)
Workflows de Apoyo
Environment (Entorno)
Project Management (Gestión del Proyecto)
Configuration & Change Management (Gestión de Configuración
y Cambios)

192
 www.dsic.upv.es/~uml
IV. Proceso de Desarrollo de SW basado
en UML
... Elementos en RUP
Workflow, Workflow Detail , Workers, Actividades y
Artefactos

Ejemplo
Workflow: Workflow Detail:Analyse the
Requirements Problem

Worker Artefact
s Actividad os 193
 www.dsic.upv.es/~uml
IV. Proceso de Desarrollo de SW basado
en UML

... Elementos en RUP


Workers Testing professional workers
Analyst workers Test Designer
Business-Process Analyst Tester
Business Designer Manager workers
Business-Model Reviewer Change Control Manager
Requirements Reviewer Configuration Manager
System Analyst Deployment Manager
Use-Case Specifier Process Engineer
User-Interface Designer Project Manager
Developer workers Project Reviewer
Architect Other workers
Architecture Reviewer Any Worker
Capsule Designer Course Developer
Code Reviewer Graphic Artist
Database Designer Stakeholder
Design Reviewer System Administrator
Designer Technical Writer
Implementer Tool Specialist
Integrator 194
 www.dsic.upv.es/~uml
IV. Proceso de Desarrollo de SW basado
en UML

... Elementos en RUP


Workers, Actividades, Artefactos
Ejemplo: System Analyst Worker

195
 www.dsic.upv.es/~uml
IV. Proceso de Desarrollo de SW basado
en UML

... Elementos en RUP


Artefactos
Resultado parcial o final que es producido y usado durante
el proyecto. Son las entradas y salidas de las actividades

Un artefacto puede ser un documento, un modelo o un


elemento de modelo
Conjuntos de Artefactos

Business Modeling Set Deployment Set


Requirements Set Project Management Set
Analysis & Design Set Configuration & Change Management Set
Implementation Set Environment Set

Test Set
196
 www.dsic.upv.es/~uml
IV. Proceso de Desarrollo de SW basado
en UML

... Elementos en RUP


Artefactos, Workers, Actividades
Ejemplo:Business Modeling Artifact Set

197
 www.dsic.upv.es/~uml
IV. Proceso de Desarrollo de SW basado
en UML
Características Esenciales de
RUP

Proceso Dirigido por los Casos de Uso


Proceso Iterativo e Incremental
Proceso Centrado en la Arquitectura

198
 www.dsic.upv.es/~uml
IV. Proceso de Desarrollo de SW basado
en UML

Proceso dirigido por los Casos


de Uso
Requisitos Capturar, definir y
validar los casos de uso
Análisis & Diseño
Casos de Uso Realizar los
integran el casos de uso
Implementación trabajo

Verificar que se satisfacen los caso


Pruebas

199
 www.dsic.upv.es/~uml
IV. Proceso de Desarrollo de SW basado
en UML

... Proceso dirigido por los Casos


de Uso
«trace «trace
» »
Caso de Realización de Realización de
Uso Análisis Diseño

«trace
«trace »
» Prueba
s
Unitari
Pruebas X as
Funcionales
Caso de
Prueba

[The Unified Software Development Process. I. Jacobson, G. Booch and J. Rumbaugh. Addison-
Wesley, 1999] 200
 www.dsic.upv.es/~uml
IV. Proceso de Desarrollo de SW basado
en UML

... Proceso dirigido por los Casos


de Uso

201
 www.dsic.upv.es/~uml
IV. Proceso de Desarrollo de SW basado

Proceso Iterativo e en UML

Incremental
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

202
 www.dsic.upv.es/~uml
IV. Proceso de Desarrollo de SW basado

... Proceso Iterativo e en UML

Incremental
Las actividades se encadenan en una mini-
cascada con un alcance limitado por los
objetivos de la iteración

Anális
is
Diseñ
o
Codifi
c. Pruebas
n veces e
Integraci
ón
203
 www.dsic.upv.es/~uml
IV. Proceso de Desarrollo de SW basado

... Proceso Iterativo e en UML

Incremental
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)

204
 www.dsic.upv.es/~uml
IV. Proceso de Desarrollo de SW basado
en UML

Proceso Iterativo e Incremental

Enfoqu
e
Secuen
cial

Enfoque
Iterativo
e
Increme
ntal 205
 www.dsic.upv.es/~uml
IV. Proceso de Desarrollo de SW basado

... Proceso Iterativo e en UML

Incremental
Grado de Finalización de Artefactos

206
 www.dsic.upv.es/~uml
IV. Proceso de Desarrollo de SW basado
en UML
Proceso Centrado en la
Arquitectura
Arquitectura de un sistema es la organización o
estructura de sus partes más relevantes
Un arquitectura ejecutable es una
implementación parcial del sistema, construida
para demostrar algunas funciones y propiedades

RUP establece refinamientos sucesivos de una


arquitectura ejecutable, construida como un
prototipo evolutivo

Inceptio Elaborati Constructi Transitio


n on on n

Architectu
re 207
 www.dsic.upv.es/~uml
IV. Proceso de Desarrollo de SW basado

Fases, Release, Base Line,


en UML

Generación
ciclo de ciclo de
desarrollo evolución

release base line generación


(producto al (release (release final
final de asociada de
una iteración)
 www.dsic.upv.es/~uml
a un hito) un ciclo de 208
IV. Proceso de Desarrollo de SW basado

Esfuerzo y dedicación por Fases en en UML

RUP

Inicio Elaboración Construcción Transición

Esfuerzo 5% 20 % 65 % 10%

Tiempo Dedicado
10 % 30 % 50 % 10%

209
 www.dsic.upv.es/~uml
IV. Proceso de Desarrollo de SW basado
Distribución de Recursos por Fases en en UML

RUP

210
 www.dsic.upv.es/~uml
V
Conclusiones

211
 www.dsic.upv.es/~uml
V.
Conclusiones

Claves en el Desarrollo de SI
Notació
n
UML

Herramientas Proceso
p.e. Rational p.e. Rational Unified
Rose Process
Poseidon Métrica 3.0 o XP 212
 www.dsic.upv.es/~uml
V.

Modelado de SI: Algunas Conclusiones

Reflexiones
¿Cuál es el propósito de nuestros modelos?
“Documentar” (a posteriori)
Comunicar ideas y estudiar alternativas
Tomar decisiones de análisis/diseño que dirijan la implementación
Generar parcial o totalmente una implementación a partir de los
modelos
Pragmatismo, los modelos deben ser útiles. Principio básico: “Sencillez
y Elegancia”
Gestión de modelos
Distintos nivel de abstracción, expresados en diferentes modelos
Seguimiento de transformaciones durante el proceso (Traceability)
Sincronización de modelos
Dificultades para la introducción de notaciones y herramientas de
modelado. La importancia del Proceso de Desarrollo

213
 www.dsic.upv.es/~uml
V.

Adaptabilidad al contexto del


Conclusiones

proyecto

214
 www.dsic.upv.es/~uml
V.
Conclusiones

Tendencias
UML: actualmente la notación más detallada, amplia y consensuada
para modelar software orientado a objetos
Dificultades actuales para derivar de forma directa una
implementación a partir de los modelos UML
Entornos de programación visual y el paradigma OO subyacente
Utilización de bases de datos relacionales
Arquitectura de 3 capas
Frameworks de persistencia para materializar y desmaterializar
objetos

Metodologías de desarrollo de software y el papel que juega UML en


ellas
Modelado Ágil
Modelado opcional y/o desechable (en Metodologías Ágiles)

215
 www.dsic.upv.es/~uml
V.
Conclusiones

... Tendencias
Nuevas versiones de UML, uff!

Extensiones de UML (SysML, www.sysml.org)

Generación automática de código a partir de modelos


Model-Driven Development (MDD), Model-Driven Architecture (MDA),
Compiladores de Modelos
Round-trip engineering. Convergencia entre herramientas CASE e
IDEs

Extendiendo UML mediante Profiles (


www.objecteering.com/products_uml_profile_builder.php)

Modelado y generación de código en dominios específicos (más allá


de UML)
Eclipse Modeling Framework (EMF,
download.eclipse.org/tools/emf/scripts/home.php)
Microsoft Tools for Domain Specific Languagues
Domain-Specific Modeling (DSM, www.dsmforum.org)
Meta CASE Tools (www.metacase.com)
216
 www.dsic.upv.es/~uml
Diagramas en UML 2.0

217
 www.dsic.upv.es/~uml
V.
Conclusiones

Bibliografía Adicional
UML
www.omg.org/uml/
Meta-links www.cetus-links.org/oo_uml.html
Martin Fowler, autor de “UML Destilled” (“UML Gota a Gota”)
http://www.martinfowler.com/

Herramientas CASE
Herramientas basadas en UML www.objectsbydesign.com/tools/
umltools_byPrice.html
International Council in SE (INCOSE) www.incose.org/tools/
Otras
Revista IEEE Software, Conferencias: OOPSLA, ECOOP
Patrones http://www.cmcrossroads.com/bradapp/docs/patterns-
intro.html,
Foro UML en yahoo: http://groups.yahoo.com/group/uml-forum/
 

218
 www.dsic.upv.es/~uml