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

 www.dsic.upv.es/~uml
Contenido
I. Introducción
– Modelado de Software
– UML
II. Breve Tour por UML
III. 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)
IV. Proceso de Desarrollo de SW basado en UML
V. Conclusiones
 www.dsic.upv.es/~uml
I
Introducción

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

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

Construcción de una casa para


“fido”

Puede hacerlo una sola persona


Requiere:
Modelado mínimo
Proceso simple
Herramientas simples

 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
 www.dsic.upv.es/~uml
I. Introducción: Modelado de SW

Construcción de un
rascacielos

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

Claves en Desarrollo de SI

Notación

Herramientas Proceso

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

Abstracción - Modelado Visual


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

Item

envío

Proceso de

Sistema

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

II. Notación (Visual) - Beneficios


Manejar la

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

Múltiples Sistemas

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

“Modelar el sistema
independientemente Componentes
Reutilizados
del lenguaje de
implementación”
Promover la Reutilización
 www.dsic.upv.es/~uml
Introducción: UML

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

 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

 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

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

Historia de UML
2005 UML
? 2.0
2 UML
003 1.5
2000 UML
1.4 Revisiones
1 UML menores
999 1.3
1 UML
998 1.2
Nov UML aprobado
por el OMG
‘97

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

Participantes en UML 1.0


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

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

OO
Rumbaugh
Booch Jacobson

Odell
Meyer
Pre- and Post-conditions

Shlaer-Mellor UML
Object life cycles
Harel
State Charts
Gamma et. al.
Frameworks, patterns,
notes
Embly Wirfs-Brock
Singleton classes Responsabilities
Fusion
Operation descriptions,
message numbering

 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

 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”

 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:
• Part icipación de m et odólogos influyent es
• 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.

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

 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

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

 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

 www.dsic.upv.es/~uml
Diagramas de implementación
II. Breve Tour por UML

... Diagramas de UML


Los diagramas expresan gráficamente
partes de un modelo
State
State
Diagrama
Use Case Diagrams
Use Case
Diagrama Diagrams
s de State
Use Case Diagrams Clases State
Diagrama
Use Case
Diagrama Diagrams
s de Diagrams
Diagrams Diagrams
s de
Diagrams
s de Casos de
Objetos
Secuencia

Scenario State
Scenario
Diagrama State
Diagrama
Diagrams Diagrams
Diagrams
s de Diagrams
s de
Modelos
Colaborac Compone

Scenario Component
Diagrama
Scenario
Diagrama Component
Diagrams
Diagrams Diagrams
s de
Diagrams
s de Diagrama
Estados s de Distribuci
Actividad
 www.dsic.upv.es/~uml
II. Breve Tour por UML

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

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

Este enfoque sigue el browser de Rational Rose


 www.dsic.upv.es/~uml
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)

 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

 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

 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

 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

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

… Paquetes en UML

Práctica 1

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

Diagrama de Casos de Uso

 Casos de Uso es una técnica para


capturar información respecto de los
servicios que un sistema proporciona a su
entorno

 No pertenece estrictamente al enfoque


orientado a objeto, es una técnica para
captura y especificación de requisitos

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

… Ejemplos
Ejemplo
:
Retirar dinero

Consult ar E xt ract o
Cliente

Realizar transferencia
Práctica 2

 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

 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

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

Diagrama de Clases
 El Diagrama de Clases es el diagrama principal
para el análisis y diseño del sistema
 Un diagrama de clases presenta las clases del
sistema con sus relaciones estructurales y de
herencia
 La definición de clase incluye definiciones para
atributos y operaciones
 El modelo de casos de uso debería aportar
información para establecer las clases, objetos,
atributos y operaciones

 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()

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

… Ejemplos (Asociación)

dirige direc tor


Departam ento Profes or

0..1 1

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

… Ejemplos (Clase
Asociación)

empleador trabajadores
Empresa Empleado

* 1..*

Cargo
superior
nombre
sueldo 0..1

subordinado 1..*

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

… Ejemplos (Generalización)

Trabajador

{ disjunta, completa }

Directivo Administrativo Obrero

 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

 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 ]

 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
 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

 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

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

Diagrama de Despliegue en
Rational Control 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

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

Resumen

 UML define una notación que se expresa


como diagramas sirven para representar
modelos/subsistemas o partes de ellos

 El 80 por ciento de la mayoría de los


problemas pueden modelarse usando
alrededor del 20 por ciento de UML-- Grady
Booch

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

 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

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


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

Problemas en OO

“...Los conceptos básicos de la OO se conocen


desde hace dos décadas, pero su aceptación
todavía no está tan extendida como los beneficios
que esta tecnología puede sugerir”

“...La mayoría de los usuarios de la OO no utilizan


los conceptos de la OO de forma purista, como
inicialmente se pretendía. Esta práctica ha sido
promovida por muchas herramientas y lenguajes
que intentan utilizar los conceptos en diversos
grados”
--Wolfgang Strigel

 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
mayoritariamente por objetos degenerados”
 www.dsic.upv.es/~uml
Fundamentos de Modelado
OO

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

 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

 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

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

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

Clases y Objetos

 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

 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

 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

 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

 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

 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

 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

 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

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

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

Requisitos del software

 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

 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

 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

 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
 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

 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

 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>>
 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

 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

 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

 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

 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

 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

 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?

 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

 www.dsic.upv.es/~uml
III. El Paradigma OO: Requisitos
Identificador CU-<id-requisito>
Nombre <nombre del requisito funcional>
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>}
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 Si <condición>, {el <actor> , el sistema} <acción realizada por el actor o


sistema>>, se realiza el caso de uso < caso de uso CU-x>

… …

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


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

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

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
 www.dsic.upv.es/~uml
III. El Paradigma OO: Interacción entre objeto

Mensajes

Sintaxis para mensajes:


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

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

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)
 www.dsic.upv.es/~uml
III. El Paradigma OO: Interacción entre objeto

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

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

… Diagrama de Secuencia

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

… 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

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

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

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

ob3 : C3 ob4 : C4

op( ) ob1 : C1

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


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

more( )

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

… 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

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

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

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

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

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

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

[x>y] 1: Mensaje
B

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

… Mensajes
 Un mensaje que devuelve un resultado:

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

Práctica 8

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

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

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

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

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

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

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

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

Clases: Notación Gráfica


 Otros ejemplos:

lista
pila

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

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

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

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

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

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

… 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"()

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

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

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

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

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

… 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

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

… 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 una restricción de existencia

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

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

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

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

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

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

Window

1 1
1

scrollbar
2 title 1 body 1
Slider Header Panel

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

... Ejemplos
Member-of * Committee
Person *

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

worker Person Company


employee employer
0..1
* *
0..1

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

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

… Ejemplos
Polígono Punto
Agregación 1 contiene
3..*
{ordenado}

Persona
*
Cuenta *
or Asociación excluyente
* Empresa
1

Usuario está-autorizado-en Estación


* *

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

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

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

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

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

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

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

... Generalización
Vehículo

Veihículo Terrestre Vehículo Aéreo

Coche Camión Avión Helicóptero

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

... 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)
 www.dsic.upv.es/~uml
III. El Paradigma OO: Clases y relaciones entre clase

... 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
 www.dsic.upv.es/~uml
III. El Paradigma OO: Clases y relaciones entre clase

... 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
 www.dsic.upv.es/~uml
III. El Paradigma OO: Clases y relaciones entre clase

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

Ve hícu lo Aéreo

{
estática }

Avión Helicóptero

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

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

Coche

{
dinámica }

Funcionando Est ropeado

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

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

 Intensión: Propiedades definidas en


una clase
A

int(A)  int(B)

ext(B)  ext(A)
B

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

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

C
0
ext(C0) =  ext(Ci) 
{ completa
static }

ext(Ci)  ext(Cj) =  
C C
1 n disjunta

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

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

C
0
ext(C0) =  ext(Ci)  completa

{ extt(Ci)  extt(Cj) =   disjunta en


dinámica }
t
extt1(Ci)  extt2(Cj)   
C C
posiblemente
1 n
no disjunta en
diferentes
instantes
 www.dsic.upv.es/~uml
III. El Paradigma OO: Clases y relaciones entre clase

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

uso

Vehículo Aéreo

estructura

Avión Helicóptero

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

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

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

… 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

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

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

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

… 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

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

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
 www.dsic.upv.es/~uml
III. El Paradigma OO: Clases y relaciones entre clase

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

Animal
dormir()
?
dormir

León Oso Tigre

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

… Polimorfismo
Animal Dormir()
{
dormir()
}

León Oso Tigre


dormir() dormir() dormir()

Dormir() Dormir() Dormir()


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

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

… 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

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

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

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)

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

… 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

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

… 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

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

… Diagrama de Estados
 Estados y Transiciones

Evento [condición] / Acción

A B

Tanto el evento como la acción se


consideran instantáneos

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

… 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

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

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

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

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

… 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

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

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

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

Generalización de Estados
 Ejemplo:

e1
A B

e2
e2

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

Generalización de Estados
 Quedaría como:

e1
Aa b
B

e2

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

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

e1
Aa Bb

e2

e0

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

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

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

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

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

… Generalización de Estados

 Ejemplo:

e1
e1

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

… 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 ]
Pinned Invalid / connect
caller hangs up
/ disconnect
do/ play message

calle e Connecting
callee
hang hangs
s up up
busy
Busy connected
do/ play busy t one
Talking Ringing
callee answers do/ play ringing tone
/ enable
speech

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

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)

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

… Historia
 Ejemplo:
A

d2
B

in
D x y
out
d1
C

H*

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

… Historia
 Ejemplo:

Enjuague Lavado Secado

cerrar puerta abir puerta

Espera

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

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

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

… Destrucción de Objeto
 Ejemplo:

c ras h
E n vuelo

des pegar aterriz ar

Crear(m atric ula)


E n t ier ra

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

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

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

… Transiciones temporizadas
 Ejemplo: A

/ Abrir ranura

esperar dinero después de


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

Depósito efectuado

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

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

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

Ejemplo (con swim lines)


Pasaj ero Vendedo r Airline

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

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

Emitir
billete

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

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

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

... Ejemplos

Calculate [cost < $50] Change customer's


total cost account

[cost >= $50] Get


authorization

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

 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

 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
 www.dsic.upv.es/~uml
...Diagrama de
III. El Paradigma OO: Componentes

Componentes

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

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

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

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

… 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

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

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

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

<<RDSI>>
<<RDSI>>
Podemos distinguir Control
tipos de nodos y
connexiones por
estereotipado

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

… Diagrama de Despliegue
 Ejemplo:

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

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

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

DBServer

<<Entity>>
ShoppingCart

videoStoreApplication
Component Diagram:
DBServer / DBServer

DBServer
VideoStoreDB

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

Object Constraint
Language
OCL

 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

 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

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

Ejemplo

 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

 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

 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

 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

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

 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

 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

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

 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 modificados Desarrollo o modificado
de Software

No existe un proceso de software universal. Las


características de cada proyecto (equipo de
desarrollo, recursos, etc.) exigen que el
proceso sea configurable
 www.dsic.upv.es/~uml
IV. Proceso de Desarrollo de SW basado en UML

Rational Unified Process (RUP)

Rational Unified Process • Pruebas funcionales


1998 • Pruebas de
desempeño
• Gestión de requisitos
• Gestión de cambios y
configuración
Rational
Objectory Process • Ingeniería de Negocio
1996-1997 • Ingeniería de datos
• Diseño de interfaces

Objectory Process UM
1987-1995

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

Dos
Dimensiones

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

Fases e Hitos (Milestones)

Inceptio Elaboration Constructio Transition


n n

Objetivo Arquitectura Capacidad Release


s Operaciona del
(Vision) l Producto
Inicial
tiemp
o

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

 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: Requirements Workflow Detail:Analyse the Problem

Workers Artefactos
Actividades
 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
• Architecture Reviewer Other workers
• Capsule Designer  Any Worker
• Code Reviewer  Course Developer
• Database Designer  Graphic Artist
• Design Reviewer  Stakeholder
• Designer  System Administrator
• Implementer  Technical Writer
• Integrator  Tool Specialist
 www.dsic.upv.es/~uml
IV. Proceso de Desarrollo de SW basado en UML

... Elementos en RUP


Workers, Actividades, Artefactos
Ejemplo: System Analyst Worker

 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  Deployment Set


Set  Project Management Set
 Requirements Set  Configuration & Change
 Analysis & Design Set Management Set

 Implementation Set  Environment Set

 Test Set
 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

 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

 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
Realizar los
casos de uso
Implementación
Verificar que se
Pruebas satisfacen los
casos de uso

 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 »
» Pruebas
Unitaria
s
Pruebas X
Funcionales
Caso de
Prueba

[The Unified Software Development Process. I. Jacobson, G. Booch and J. Rumbaugh. Addison-Wesley, 1999]

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

... Proceso dirigido por los Casos de


Uso

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

Proceso Iterativo e
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

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

... Proceso Iterativo e


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.
n veces Pruebas
e
Integraci
 www.dsic.upv.es/~uml
IV. Proceso de Desarrollo de SW basado en UML

... Proceso Iterativo e


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)
 www.dsic.upv.es/~uml
IV. Proceso de Desarrollo de SW basado en UML

Proceso Iterativo e Incremental

Enfoque
Secuencial

Enfoque
Iterativo e
Incremental

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

... Proceso Iterativo e


Incremental
Grado de Finalización de Artefactos

 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 Elaboration Constructio Transition
n n

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

Fases, Release, Base Line,


Generación
ciclo de desarrollo ciclo de
evolución

release base line generación


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

Esfuerzo y dedicación por Fases en


RUP

Elaboració Construcció Transició


Inicio
n n n
Esfuerzo 5% 20 % 65 % 10%

Tiempo
10 % 30 % 50 % 10%
Dedicado

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

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

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

Claves en el Desarrollo de SI
Notación
UML

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

Modelado de SI: Algunas


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
 www.dsic.upv.es/~uml
V. Conclusiones

Adaptabilidad al contexto del


proyecto

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

 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)
 www.dsic.upv.es/~uml
Diagramas en UML 2.0

 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/
 

 www.dsic.upv.es/~uml