Clase 6

Ingeniería de Software
Clase 6
UML
UNPSJB - 2005 Ingeniería de Software - Clase 6 1

Contenido de la clase 6
 Desarrollo de soft OO usando UML
 Introducción
 Modelado del soft
 UML (Conceptos básicos)
 Paradigma OO
 Fundamentos
 Diagramas de CU
 Diagramas de Interacciones
 Diagramas de clase
 Diagramas de estado/actividad
 Diagrama de componentes
 Diagrama de despliegue

Bibliografía
 UML
 www.dsic.upv.es/~uml
 Patricio Letelier Torres UPV (politécnica de
Valencia)
 UML Gota a Gota (Fowler)
 UML (Booch, Rumbaugh, Jacobson)
 Instant UML (Muller)
 Webs
 www.omg.org/uml

Modelado del software www.dsic.upv.es/~uml
 Ejemplos  Modelado
 Construcción de una  Proceso bien
definido
cucha para un perro
 Herramientas más
 Puede hacerlo sofisticadas
una sola persona  Construcción de un
Requiere: rascacielos
 Modelado mínimo
 Proceso simple  Contexto de
 Herramientas desarrollo
simples  Determinar
 Construcción de una configuración del
casa proceso
Recursos
Construida


necesarios
eficientemente y
 Herramientas más
en un tiempo
sofisticadas aún.
razonable de un
UNPSJB - 2005
equipoIngeniería de Software - Clase 6 4
www.dsic.upv.es/~uml
Claves en Desarrollo de SI
Notación
Herramientas Proceso

Abstracción - Modelado Visual (MV)

“El modelado captura las
partes esenciales del sistema”
Orden
Item
envío
Proceso de Negocios
Sistema Computacional

¿Qué es UML? www.dsic.upv.es/~uml
 UML = Unified Modeling Language

 Un lenguaje de propósito general para el
modelado orientado a objetos
 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)

Motivación www.dsic.upv.es/~uml
 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

Historia de UML www.dsic.upv.es/~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

Historia de UML
2001 UML 2.0
2000 UML 1.4
1999 UML 1.3

Revisiones menores
1998
UML 1.2
Nov ‘97 UML aprobado por el OMG

UML “aglutina” enfoques 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
Aspectos Novedosos www.dsic.upv.es/~uml
 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

Inconvenientes en UML www.dsic.upv.es/~uml
 Definición del proceso de desarrollo

usando UML. UML no es una metodología
 Falta integración con respecto de otras
técnicas tales como patrones de diseño,
interfaces de usuario, documentación,
etc.
 “Monopolio de conceptos, técnicas y
métodos en torno a UML”

Perspectivas de UML www.dsic.upv.es/~uml
 UML será el lenguaje de modelado

orientado a objetos estándar
predominante los próximos años
 Razones:
 Participación de metodólogos influyentes
 Participación de importantes empresas
 Aceptación del OMG como notación estándar
 Evidencias:
 Herramientas que proveen la notación UML
 “Edición” de libros
 Congresos, cursos, etc.

Modelos y Diagramas www.dsic.upv.es/~uml
 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 completamente 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

... Modelos y Diagramas www.dsic.upv.es/~uml
 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

Diagramas de UML www.dsic.upv.es/~uml
 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

... Diagramas de UML www.dsic.upv.es/~uml
Los diagramas expresan gráficamente partes de un modelo

State
State
Use Case Diagramas de
Diagrams
Use Case Diagrams State
Use Case Diagramas de
Diagrams Clases State
Use Case Diagrams Diagramas de
Diagrams
Diagramas de
Diagrams Casos de Uso Diagrams
Diagrams Objetos
Secuencia
Scenario State
Scenario State
Diagramas de
Diagrams Diagramas de
Diagrams
Diagrams Diagrams
Colaboración Modelo Componentes
Scenario Component
Scenario Component
Diagramas
Diagrams de
Diagramas de
Diagrams Diagrams
Diagrams Distribución
Estados Diagramas de
Actividad
Organización de Modelos www.dsic.upv.es/~uml
 4+1 vistas de Kruchten (1995)
Vista de
Vista Lógica Realización
Vista de los
Casos de Uso
Vista de Vista de
Procesos Distribución
Este enfoque sigue el browser de Rational Rose

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

Paquetes en UML www.dsic.upv.es/~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

… Paquetes en UML www.dsic.upv.es/~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
 Todas las clases 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


Diagrama de Casos de Uso www.dsic.upv.es/~uml
 Casos de Uso es una

técnica para capturar
información de cómo
un sistema o negocio Supervisor Verificar Situación del Cliente
trabaja, o de cómo se
desea que trabaje
 No pertenece
estrictamente al
enfoque orientado a Administrativo Preparar Catálogo
Sistema
objeto, es una técnica Inventario
para captura de
requisitos Tipos de Venta

… Ejemplos www.dsic.upv.es/~uml
En el paquete tipos de venta: Otro Ejemplo
Venta Normal Solicitar Préstamo

Cliente
[Tarjeta Caducada]
<<extend>>
Venta en Rebajas
Vendedor
Solicitar Nueva Tarjeta

Venta en Ofertas

<<include>>
Reintegro Cuenta Corriente
Cliente Verificar Operación
<<include>>
Reintegro Cuenta de Crédito

Diagrama de Secuencia www.dsic.upv.es/~uml
:WInPréstamos :Socio :Video :Préstamo

: Encargado
prestar(video, socio)
verificar situación socio
verificar situación video
registrar préstamo
entregar recibo

Diagrama de Colaboración www.dsic.upv.es/~uml
: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

Diagrama de Clases www.dsic.upv.es/~uml
 El Diagrama de Clases es el diagrama principal

para el análisis y diseño
 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 aporta información
para establecer las clases, objetos, atributos y
operaciones

Ejemplos www.dsic.upv.es/~uml
(Clase y Visibilidad) Asociación
dirige director
Departamento Profesor
0..1 1

… Ejemplos (Clase Asociación)
empleador trabajadores
Empresa Empleado
* 1..*
Cargo
superior
nombre
sueldo 0..1
subordinado 1..*

… Ejemplos (Generalización) www.dsic.upv.es/~uml
Trabajador
{ disjunta, completa }
Directivo Administrativo Obrero

Motor Piloto Vendedor de billetes
1..4 1..2 1
1 n
n
1 n 1 n
Avión Vuelo Reserva
n
Avión militar Avión comercial Línea aérea
Avión de carga Avión de pasajeros

Diagrama de Estados www.dsic.upv.es/~uml
alta baja
número_préstamos = 0
sin préstamos
Socio
número : int
nombre : char[50]
número_prestamos : int = 0
prestar devolver[ número_préstamos = 1 ]
alta()
baja()
prestar(código_libro : int, fecha : date)
devolver(código_libro : int, fecha : date)
número_préstamos > 0
con préstamos
prestar
devolver[ número_préstamos > 1 ]

Diagrama de Actividad www.dsic.upv.es/~uml
[no hay café] [no zumo]

Buscar Bebida
[hay café [hay zumo]
Poner café en filtro Añadir agua al depósito Agarrar taza
Poner filtro en máquina Agarrar zumo
Encender máquina
/ cafetera.On
Café en preparación
indicador de fin
Servir café
Beber

… Otro Ejemplo (con swim lines) www.dsic.upv.es/~uml
Pasajero Vendedor Airline
Solicitar pasaje
Verificar
existencia vuelo
Dar detalles vuelo
Informar alternativas
y precios
Seleccionar vuelo
Solicitar pago Reservar plazas
Confirmar
Pagar pasaje plaza reservada
Emitir billete

Diagrama Componentes www.dsic.upv.es/~uml
Control y Análisis
Interf az de Terminal
Comment
Comment
Gestión de Cuentas Acceso a BD

Rutinas de Coneccion
Comment Comment
Comment

Diagrama de Despliegue www.dsic.upv.es/~uml
Servidor Central Control y Análisis
Acceso a BD Comment
Comment
Comment
T erminal de Consulta
Interfaz de Terminal
Comment Comment
Punto de Venta
Comment
Gestión de Cuentas Interfaz de Terminal
Comment Comment

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

UML
Paradigma OO
Diagramas

¿Por qué la Orientación a Objetos?
 Conceptos comunes
 Proximidad de los conceptos de modelado durante
de modelado respecto de las el análisis, diseño e
entidades del mundo real implementación
 Mejora captura y validación  Facilita la transición
de requisitos
entre distintas fases
 Acerca el “espacio del
problema” y el “espacio de la  Favorece el desarrollo
solución” iterativo del sistema
 Modelado integrado de  Disipa la barrera
propiedades estáticas y entre el “qué” y el
dinámicas del ámbito del “cómo”
problema  Sin embargo, existen
 Facilita construcción, problemas ...
mantenimiento y reutilización

Problemas en OO www.dsic.upv.es/~uml
“...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
… Problemas en OO www.dsic.upv.es/~uml
 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”
Reflexiones respecto de Situación Actual de
Desarrollo de SI
Análisis Diseño Implementación
DFDs DEs
Enfoque Entornos de
Estructurado E-R Programación
Modelo Visual
Diagramas de Casos de Uso Relacional
Diagramas de Actividad
Diagramas de Secuencia
Diagramas de Colaboración d Modelo
Relacional !! Bases de Datos
(Objeto-)
Enfoque OO Diagrama de Clases
Relacionales
Diagrama de Estados
Diagramas de Actividad

Diagramas de Casos de Uso

Casos de Uso www.dsic.upv.es/~uml
 Los Casos de Uso (Ivar  Comparación con respecto a los

Jacobson) describen bajo Diagramas de Flujo de Datos del
Enfoque Estructurado
la forma de acciones y  Un caso de uso es una función
reacciones el atómica ofrecida por el sistema al
comportamiento de un entorno (actores)
sistema desde el p.d.v. del  DFD puede ser detallada en un
usuario DFD Hijo
 Caso Uso y Proceso igual
 Permiten definir los límites modelado, pero caso de uso
del sistema y las expresa funcionalidad mediante
relaciones entre el sistema interacción de actores
y el entorno  Caso de uno no modela detalle
funcional interno
 Los Casos de Uso son  Relaciones de extensión y
descripciones de la generalización de CU no tienen
funcionalidad del sistema igual en DFD
independientes de la
implementación

… Casos de Uso www.dsic.upv.es/~uml
 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 Actor A
Caso de Uso A
particionan el conjunto
de necesidades
atendiendo a la Caso de Uso B
categoría de usuarios Actor B
que participan en el
mismo
 Están basado en el
lenguaje natural, es
decir, es accesible por
los usuarios
 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

 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

Casos de Uso: Relacioneswww.dsic.upv.es/~uml
 UML define cuatro  Inclusión : una
instancia del Caso de
tipos de relación Uso origen incluye
en los Diagramas también el
comportamiento
de Casos de Uso: descrito por el Caso
 Comunicación de Uso destino
<<include>>
Caso de Uso Origen Caso de Uso Destino
 <<include>>
reemplazó al
Caso de Uso
Actor
denominado
<<uses>>
… Casos de Uso: Relaciones
 Extensión : el Caso  Herencia : el Caso

de Uso origen de Uso origen
extiende el hereda la
comportamiento especificación del
del Caso de Uso Caso de Uso
destino destino y
posiblemente la
modifica y/o amplía
<<extend>>
Caso de Uso Origen Caso de Uso Destino
Caso de Uso Hijo Caso de Uso Padre

 Ejemplo:
Identificación
<<include>>
Transferencia
Cliente
<<extend>>
Transferencia en Internet

 Ejemplo:

Casos de Uso: Construcción
 Un caso de uso debe ser simple, inteligible, claro

y conciso
 Generalmente hay pocos actores asociados a cada
Caso de Uso
 Preguntas clave:
 ¿cuáles son las tareas del actor?
 ¿qué información crea, guarda, modifica, destruye o
lee el actor?
 ¿debe el actor notificar al sistema los cambios
externos?
 ¿debe el sistema informar al actor de los cambios
internos?

… Casos de Uso: Construcción
 La descripción del Caso de Uso comprende:

 el inicio: cuándo y qué actor lo produce?
 el fin: cuándo se produce y qué valor devuelve?
 la interacción actor-caso de uso: qué mensajes
intercambian ambos?
 objetivo del caso de uso: ¿qué lleva a cabo o
intenta?
 cronología y origen de las interacciones
 repeticiones de comportamiento: ¿qué operaciones
son iteradas?
 situaciones opcionales: ¿qué ejecuciones
alternativas se presentan en el caso de uso?

RF- <id del requisito> <nombre del requisito funcional>
Versión <numero de versión y fecha>
Autores <autor>
Fuentes <fuente de la versión actual>
Objetivos asociados <nombre del objetivo>
Descripción El sistema deberá comportarse tal como se describe en
el siguiente caso de uso { concreto cuando <evento de
activación> , abstracto durante la realización de los
casos de uso <lista de casos de uso>}
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 RF-x>
2 Si <condición>, {el <actor> , el sistema} <acción
realizada por el actor o sistema>>, se realiza el
caso de uso < caso de uso RF-x>
3
4
5
6
n
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 RF-x>, a continuación este caso
de uso {continua, aborta}
2
3
Rendimiento Paso Cota de tiempo
1 n segundos
2 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>
Modelo de Casos de Uso y
Modelo Conceptual (Análisis)
 La especificación de cada caso de uso y

los correspondientes D. de Interacción
establecen el vínculo con el modelo
conceptual
 En métodos OO que carecen de una
técnica de captura de requisitos se
comienza inmediatamente con la
construcción del modelo conceptual
(análisis)

Diagramas de Interacción

Interacción www.dsic.upv.es/~uml
 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
 Mensajes:
 Sintaxis para mensajes
Predecesor/fuarda secuencia:retorno := msg
(args)

Diagramas de interacción www.dsic.upv.es/~uml
 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)

Diagrama de Secuencia www.dsic.upv.es/~uml
 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

… Diagrama de Secuenciawww.dsic.upv.es/~uml

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

… Diagrama de Secuenciawww.dsic.upv.es/~uml

Diagrama de Colaboraciónwww.dsic.upv.es/~uml
 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

Mensajes www.dsic.upv.es/~uml
 Un mensaje  Un mensaje se
desencadena una
acción en el objeto envía de manera
destinatario condicionada:
 Un mensaje se envía
si han sido enviados
los mensajes de una [x>y] 1: Mensaje
lista (sincronización): B
A
A.1, B.3 / 1:Mensaje B

… Mensajes www.dsic.upv.es/~uml
 Un mensaje que devuelve un

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

Diagrama de Clases

Clasificación www.dsic.upv.es/~uml
 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

Clases www.dsic.upv.es/~uml
 La clase define el  Cada clase se

ámbito de representa en un
rectángulo con tres
definición de un compartimientos:
conjunto de  nombre de la clase
objetos  atributos de la clase
 Cada objeto  operaciones de la
pertenece a una clase
clase motocicleta
 Los objetos se
crean por color
cilindrada
instanciación de velocidad maxima
las clases arrancar
acelerar
UNPSJB - 2005 Ingeniería de Software - Clase 6 frenar 71
Clases: Notación Gráfica www.dsic.upv.es/~uml
 Otros ejemplos:
lista
pila
primero
ultimo apilar
añadir desapilar
quitar cardinalidad
cardinalidad

Clases: Encapsulación www.dsic.upv.es/~uml
 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

… Clases: Encapsulación (Recordar)
 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)

… Clases: Encapsulación www.dsic.upv.es/~uml
 Ejemplo:
Reglas de visibilidad
+ Atributo público : int

# Atributo protegido : int
- Atributo privado : int
+ "Operación pública"
# "Operación protegida"
- "Operación privada"

Relaciones entre Clases www.dsic.upv.es/~uml
 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

Asociación www.dsic.upv.es/~uml
 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

… Asociación www.dsic.upv.es/~uml
 Ejemplo:
marido
casado-con 0.. 1
0.. 1 trabaja-para * Compañía
mujer Persona *
nombre emplea-a
jefe nombre
0.. 1 s. s. dirección
Administra * empleado

… Asociación www.dsic.upv.es/~uml
 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

Asociación Cualificada www.dsic.upv.es/~uml
* 0..1
Aerolínea nro_billete Viajero
Tablero fila 1 1
columna
Cuadro
Ajedrez
Reduce la multiplicidad del rol opuesto al considerar el valor

del cualificador

Agregación www.dsic.upv.es/~uml
 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

Agregación: Caracterización
 Caracterizaciones relacionadas con la multiplicidad
Multiplicidad Mínima Objeto Agregado Máxima

0  flexible 1  disjunto
> 0  estricta Multiplicidad
(mín , máx ) > 1  no disjunto
a a
Multiplicidad Mínima Multiplicidad Máxima

0  nulos permitidos (mínc, máxc) 1  univaluado
> 0  nulos no permitidos > 1  multivaluado
Objeto Componente
... Agregación: Caracterización
 En UML sólo se distingue entre agregación

y composición (aggregate composition),
siendo esta última disjunta y estricta
 Además se una agregación se podría
caracterizar según:
 ¿Puede el objeto parte comunicarse
directamente con objetos externos al objeto
agregado?
 No => inclusiva
 Si => no inclusiva
 ¿Puede cambiar La composición del objeto
agregado?
 Si => dinámica
 No => estática

Ejemplos www.dsic.upv.es/~uml

... Ejemplos www.dsic.upv.es/~uml

1 contiene
Agregación Polígono 3.. *
Punto
{ordenado}
* * Persona
Cuenta Asociación excluyente
or
*
Empresa
1
* está-autorizado-en *
Usuario Estación
Autorización
prioridad
Clase de asociación privilegios
camb_privil
Clases y Objetos www.dsic.upv.es/~uml
 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

Generalización www.dsic.upv.es/~uml
 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

... Generalización www.dsic.upv.es/~uml
 La Generalización y
 Nombres usados: clase Especialización son
padre - clase hija. Otros equivalentes en
nombres: superclase - cuanto al resultado: la
subclase, clase base - jerarquía y herencia
clase derivada establecidas
 Las subclases heredan  Generalización y
propiedades de sus clases Especialización no son
padre, es decir, atributos operaciones reflexivas
y operaciones (y ni simétricas pero sí
asociaciones) de la clase transitivas
padre están disponibles
en sus clases hijas

Vehículo
Veihículo Terrestre Vehículo Aéreo
Coche Camión Avión Helicóptero

 La especialización es una técnica muy

eficaz para la extensión y reutilización
Coche
 Restricciones predefinidas
Funcionando Estropeadoen UML:
 disjunta - no disjunta
 total (completa) - parcial (incompleta)

 Particionamiento del
 La noción de clase está espacio de objetos =>
próxima a la de conjunto Clasificación Estática
 Dada una clase, podemos  Particionamiento del
ver el conjunto relativo a espacio de estados de
las instancias que posee o los objetos =>
bien relativo a las Clasificación Dinámica
propiedades de la clase  En ambos casos se
 Generalización y recomienda considerar
especialización expresan generalizaciones/espe
relaciones de inclusión cializaciones disjuntas
entre conjuntos

 Un ejemplo de Clasificación
Estática:
Vehículo Aéreo
{ estática }
Avión Helicóptero

 Un ejemplo de Clasificación
Dinámica:
Coche
{ dinámica }
Funcionando Estropeado

 Extensión: Posibles instancias de una

clase
 Intensión: Propiedades definidas en una
clase
A
int(A)  int(B)
ext(B)  ext(A)
B

 Clasificación Estática
C0
ext(C0) =  ext(Ci)  completa

{ static }
ext(Ci)  ext(Cj) =   disjunta
C1 Cn

 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

 Ejemplo: varias especializaciones a partir de

la misma clase padre, usando
discriminadores:
Comercial Militar
uso
Vehículo Aéreo
estructura
Avión Helicóptero
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

… Herencia Múltiple www.dsic.upv.es/~uml
 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

Principio de Sustitución www.dsic.upv.es/~uml
 El Principio de Sustitución de Liskow

(1987) 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.”

… Principio de Sustitución www.dsic.upv.es/~uml
 Dado que los programadores pueden
introducir código en las subclases
redefiniendo las operaciones, es posible
introducir involuntariamente
incoherencias que violen el principio de
sustitución
 El polimorfismo que veremos a
continuación no debería implementarse
sin este principio

Polimorfismo www.dsic.upv.es/~uml
 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
… Polimorfismo www.dsic.upv.es/~uml
 Ejemplo: todo animal duerme, pero

cada clase lo hace de forma distinta
Animal
dormir()
?
dormir
?
León Oso Tigre

Animal Dormir()
{
dormir()
}
León Oso Tigre

dormir() dormir() dormir()
Dormir() Dormir() Dormir()

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

 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

Diagrama de Estados

Diagrama de Estados www.dsic.upv.es/~uml
 Los Diagramas de Estados  Cada objeto está en un estado en

representan autómatas de cierto instante
estados finitos, desde el  El estado está caracterizado
p.d.v. de los estados y las
parcialmente por los valores
transiciones
algunos de los atributos del objeto
 Son útiles sólo para los
objetos con un  El estado en el que se encuentra
comportamiento un objeto determina su
significativo comportamiento
 El formalismo utilizado  Cada objeto sigue el
proviene de los comportamiento descrito en el D.
Statecharts (Harel) de Estados asociado a su clase
 Los D. De Estados y escenarios son
complementarios
… Diagrama de Estados www.dsic.upv.es/~uml
 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

 Estados y Transiciones
Evento [condición] / Acción
A B
Tanto el evento como la acción se

consideran instantáneos

 Ejemplo de un Diagrama de Estados

para la clase persona:
contratar
en el paro en activo
perder empleo
jubilarse
jubilarse
jubilado

Acciones www.dsic.upv.es/~uml
 Podemos especificar la solicitud de un

servicio a otro objeto como consecuencia de
la transición:
Evento [condición] / OtroObjeto.Operación

… Acciones www.dsic.upv.es/~uml
 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

Generalización de Estadoswww.dsic.upv.es/~uml
 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

 Ejemplo:
e1
A B
e2
e2

 Quedaría como:
e1
Aa b
B
e2
C
… Generalización de Estados
 Las transiciones de entrada deben ir hacia

subestados específicos:
e1
Aa Bb
e2
e0

 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

 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

 Ejemplo:
e1
e1

 Ejemplo:

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

… Historia www.dsic.upv.es/~uml
 Ejemplo:
A
d2
B
in
D x y
out
d1
C
H*
… Historia www.dsic.upv.es/~uml
 Ejemplo:
Enjuague Lavado Secado
cerrar puerta abir puerta
Espera

Destrucción del Objeto www.dsic.upv.es/~uml
 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

… Destrucción de Objeto www.dsic.upv.es/~uml
 Ejemplo:
crash
En vuelo
despegar aterrizar
Crear(matricula)
En tierra

Transiciones temporizadaswww.dsic.upv.es/~uml
 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

… Transiciones temporizadas
 Ejemplo: A
/ Abrir ranura
esperar dinero después de

30 segundos anular
entry: Mostrar mensaje
exit: cerrar ranura transacción
Depósito efectuado
B
Diagrama de Actividad www.dsic.upv.es/~uml
 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

Ejemplos

... Ejemplos

... Ejemplos www.dsic.upv.es/~uml

Diagrama de Componentes

Diagrama de Componentes
 Los diagramas de  Los componentes representan

componentes describen todos los tipos de elementos
los elementos físicos del software que entran en la
sistema y sus relaciones fabricación de aplicaciones
informáticas. Pueden ser simples
 Muestran las opciones archivos, paquetes de Ada,
de realización bibliotecas cargadas
incluyendo código dinámicamente, etc.
fuente, binario y  Las relaciones de dependencia se
ejecutable utilizan en los diagramas de
componentes para indicar que un
componente utiliza los servicios
ofrecidos por otro componente

… Diagramas de Componentes
 Ejemplo:

Diagrama de Despliegue

Diagrama de Despliegue www.dsic.upv.es/~uml
 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

… 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

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

<<Cliente>> <<Servidor>>
Terminal Punto <<TCP/IP>>
Base de
de Venta Datos
<<RDSI>>
<<RDSI>>
Podemos distinguir tipos Control
de nodos y connexiones
por estereotipado

Proceso de Desarrollo de SW
basado en UML

¿Qué es un Proceso de Desarrollo de SW?
 Define Quién debe hacer Qué, Cuándo y

Cómo debe hacerlo
Requisitos nuevos Sistema nuevo

o modificados o modificado
Proceso de Desarrollo
 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

Historia de RUP www.dsic.upv.es/~uml
Rational Unified Process • Pruebas funcionales

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

1987-1995
Enfoque Ericsson
Dos dimensiones

Fases e Hitos (Milestones)
Inception Elaboration Construction Transition
Objetivos Arquitectura Capacidad Release

(Vision) Operacional del Producto
Inicial
tiempo

Elementos en RUP www.dsic.upv.es/~uml
 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)

... Elementos en RUP www.dsic.upv.es/~uml
 Workflow, Workflow Detail , Workers, Actividades

y Artefactos. Ejemplos
Workflow: Requirements Workflow Detail:Analyse the Problem
Workers Artefactos
UNPSJB - 2005 Ingeniería de Software - Clase 6 Actividades 146
Workers Testing professional

 workers
 Analyst workers • Test Designer
 Business-Process • Tester
Analyst Manager workers
 Business Designer • Change Control
 Business-Model Manager
Reviewer • Configuration Manager
 Requirements • Deployment Manager
Reviewer • Process Engineer
 System Analyst • Project Manager
 Use-Case Specifier • Project Reviewer
 User-Interface Other workers
Designer
• Any Worker
 Developer workers • Course Developer
 Architect • Graphic Artist
 Architecture • Stakeholder
Reviewer • System Administrator
 Capsule Designer
• Technical Writer
 Code Reviewer
• Tool Specialist
 Database Designer
 Design Reviewer
 Designer
 Implementer Ingeniería de Software - Clase 6
UNPSJB - 2005 147
 Workers, Actividades, Artefactos

 Ejemplo: System Analyst Worker

 Artefactos  Conjuntos de
 Resultado parcial o Artefactos
final que es producido  Business Modeling
y usado durante el Set
proyecto. Son las  Requirements Set
entradas y salidas de  Analysis & Design Set
las actividades
 Implementation Set
 Un artefacto puede  Test Set
ser un documento, un  Deployment Set
modelo o un elemento
 Project Management
de modelo Set
 Configuration & Change
Management Set
 Environment Set

 Artefactos, Workers, Actividades

 Ejemplo:Business Modeling Artifact Set

Características Esenciales de RUP www.dsic.upv.es/~uml
 Proceso Dirigido por los Casos de

Uso
 Proceso Iterativo e Incremental
 Proceso Centrado en la Arquitectura

Proceso dirigido por los Casos de Uso
Capturar, definir y
Requisitos
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
Pruebas satisfacen los casos
de uso

... Proceso dirigido por los Casos de Uso
«trace» «trace»
Caso de Uso Realización de Análisis Realización de Diseño
«trace»
«trace»
Pruebas
Unitarias
Pruebas Funcionales X
Caso de Prueba
[The Unified Software Development Process. I. Jacobson, G. Booch and J. Rumbaugh. Addison-Wesley, 1999]
..Proceso dirigido por los casos de Uso

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

... Proceso Iterativo e Incremental
 Las actividades se encadenan en una mini-
cascada con un alcance limitado por los
objetivos de la iteración
Análisis
Diseño
Codific.
n veces Pruebas e
Integración
... 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)

Proceso Iterativo e Incremental www.dsic.upv.es/~uml
Enfoque
Cascada
Enfoque
Iterativo e
Incremental

... Proceso Iterativo e Incremental www.dsic.upv.es/~uml
Grado de Finalización de Artefactos

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
Architecture
Fases del Ciclo de Vida www.dsic.upv.es/~uml
 El ciclo de vida consiste en una serie de ciclos,

cada uno de los cuales produce una nueva versión
del producto
 Cada ciclo está compuesto por fases y cada una
de estas fases está compuesta por un número de
iteraciones
 Las fases son:
 Inicio o Estudio de oportunidad
 Elaboración
 Construcción
 Transición

...Fases del Ciclo de Vida www.dsic.upv.es/~uml
 Inicio o Estudio de oportunidad
(inception)
 Define el ámbito y objetivos del proyecto
 Se define la funcionalidad y capacidades del
producto
 Elaboración
 Tanto la funcionalidad como el dominio del
problema se estudian en profundidad
 Se define una arquitectura básica
 Se planifica el proyecto considerando recursos
disponibles

 Construcción
 El producto se desarrolla a través de iteraciones
donde cada iteración involucra tareas de análisis,
diseño e implementación
 Las fases de estudio y análisis sólo dieron una
arquitectura básica que es aquí refinada de
manera incremental conforme se construye (se
permiten cambios en la estructura)
 Gran parte del trabajo es programación y pruebas
 Se documenta tanto el sistema construido como el
manejo del mismo
 Esta fase proporciona un producto construido
junto con la documentación

 Transición
 Se libera el producto y se entrega al usuario
para un uso real
 Se incluyen tareas de marketing, empaquetado
atractivo, instalación, configuración,
entrenamiento, soporte, mantenimiento, etc.
 Los manuales de usuario se completan y
refinan con la información anterior
 Estas tareas se realizan también en iteraciones

Esfuerzo respecto de las Workflows
15%
Requisitos
Una iteración en la
fase de elaboración
Análisis
10%
Diseño 15%
Implementación
30%
Pruebas 15%
P re lim ina ry ite r. ite r. ite r. ite r. ite r. ite r. ite r.
Ite ra tion (s) #1 #2 #n # n+ 1 # n+2 #m #m +1
5% mantenimiento 10% gestión cambios

...Esfuerzo respecto de las Fases
Requisitos
Una iteración en la
fase de elaboración
Análisis
Diseño
Implementación
Pruebas
P re lim ina ry ite r. ite r. ite r. ite r. ite r. ite r. ite r.

Ite ra tion (s) #1 #2 #n # n+ 1 # n+2 #m #m +1
Esfuerzo: 5% 20% 65% 10%

UNPSJB Duración:
- 2005 10% 30%
Ingeniería 50%
de Software - Clase 6 10% 166
UML - ANEXO
Fundamentos del Modelado OO

Para evaluación por parte de los
alumnos

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

… Objetos www.dsic.upv.es/~uml
 El Modelado de Objetos permite

representar el ciclo de vida de los
objetos a través de sus interacciones
 En UML, un objeto se representa por
un rectángulo con un nombre
subrayado Otro
Objeto
Un Objeto
más
Otro
Objeto

 Ejemplo de varios objetos

relacionados:
Cuenta Corriente 101
Juan
Banco de Valencia
Felipe
Cuenta Corriente 114

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

Clases y Objetos www.dsic.upv.es/~uml

Identidad
 Oid (Object Identifier)
Cada objeto posee un oid. El oid establece la
identidad del objeto y tiene las siguientes
características:
 Constituye un identificador único y global para
cada objeto dentro del sistema
 Es determinado en el momento de la creación del

objeto
 Es independiente de la localización física del

objeto, es decir, provee completa independencia
de localización

… Identidad
 Es independiente de las propiedades del
objeto, lo cual implica independencia de valor
y de estructura
 No cambia durante toda la vida del objeto.
Además, un oid no se reutiliza aunque el
objeto deje de existir
 No se tiene ningún control sobre los oids y su
manipulación resulta transparente
 Sin embargo, es preciso contar con algún
medio para hacer referencia a un objeto
utilizando referencias del dominio (valores de
atributos)

Estado www.dsic.upv.es/~uml
 El estado evoluciona con el tiempo

 Algunos atributos pueden ser
constantes
 El comportamiento agrupa las
competencias de un objeto y describe
las acciones y reacciones de ese
objeto
 Las operaciones de un objeto son
consecuencia de un estímulo externo
representado como mensaje enviado
desde otro objeto
Comportamiento www.dsic.upv.es/~uml
 Ejemplo de interacción:
Otro objeto
Un mensaje
Operacion 2
Un objeto
Operacion 1

… Comportamiento www.dsic.upv.es/~uml
 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

Persistencia www.dsic.upv.es/~uml
 La persistencia de los objetos designa la

capacidad de un objeto trascender en el
espacio/tiempo
 Podremos después reconstruirlo, es decir,
tomarlo 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

Comunicación www.dsic.upv.es/~uml
 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

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
… Comunicación www.dsic.upv.es/~uml
 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

… Comunicación www.dsic.upv.es/~uml
 Ejemplo en el que un agente hace de

aislante:
Sevidor 1
Un agente
Servidor 2
Un cliente

El Concepto de Mensaje www.dsic.upv.es/~uml
 La unidad de comunicación entre objetos se

llama mensaje
 El mensaje es el soporte de una comunicación
que vincula dinámicamente los objetos que
fueron separados previamente en el proceso
de descomposición
 Adquiere toda su fuerza cuando se asocia al
polimorfismo y al enlace dinámico

… El Concepto de Mensajewww.dsic.upv.es/~uml
Objeto 1
: Mensaje A
Objeto 2
: Mensaje C : Mensaje E
Objeto 3 Objeto 4
: Mensaje D
Mensaje y Estímulo www.dsic.upv.es/~uml
 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)

Clase 6

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Clase 6

Cargado por

Copyright:

Formatos disponibles

Ingeniería de Software

UNPSJB - 2005 Ingeniería de Software - Clase 6 1

UNPSJB - 2005 Ingeniería de Software - Clase 6 2

UNPSJB - 2005 Ingeniería de Software - Clase 6 3

UNPSJB - 2005 Ingeniería de Software - Clase 6 5

Abstracción - Modelado Visual (MV)

UNPSJB - 2005 Ingeniería de Software - Clase 6 6

 UML = Unified Modeling Language

UNPSJB - 2005 Ingeniería de Software - Clase 6 7

 Diversos métodos y técnicas OO, con

UNPSJB - 2005 Ingeniería de Software - Clase 6 8

 Comenzó como el “Método Unificado”, con

 El mismo año se unió Ivar Jacobson. Los

UNPSJB - 2005 Ingeniería de Software - Clase 6 9

2001 UML 2.0

2000 UML 1.4

1999 UML 1.3

UNPSJB - 2005 Ingeniería de Software - Clase 6 10

 Definición semi-formal del Metamodelo de

Permiten adaptar los elementos de modelado,

UNPSJB - 2005 Ingeniería de Software - Clase 6 12

 Definición del proceso de desarrollo

UNPSJB - 2005 Ingeniería de Software - Clase 6 13

 UML será el lenguaje de modelado

UNPSJB - 2005 Ingeniería de Software - Clase 6 14

 Un modelo captura una vista de un sistema del

UNPSJB - 2005 Ingeniería de Software - Clase 6 15

 Un proceso de desarrollo de software debe ofrecer un

 Cada modelo es completo desde su punto de vista del

UNPSJB - 2005 Ingeniería de Software - Clase 6 16

 Diagrama de Casos de Uso

UNPSJB - 2005 Ingeniería de Software - Clase 6 17

Los diagramas expresan gráficamente partes de un modelo

 4+1 vistas de Kruchten (1995)

Este enfoque sigue el browser de Rational Rose

Propuesta de Rational Unified Process (RUP)

UNPSJB - 2005 Ingeniería de Software - Clase 6 20

 Los paquetes ofrecen un mecanismo

UNPSJB - 2005 Ingeniería de Software - Clase 6 21

 Cada paquete corresponde a un

 Todas las clases no son

UNPSJB - 2005 Ingeniería de Software - Clase 6 23

UNPSJB - 2005 Ingeniería de Software - Clase 6 24

 Casos de Uso es una

objeto, es una técnica Inventario

UNPSJB - 2005 Ingeniería de Software - Clase 6 25

En el paquete tipos de venta: Otro Ejemplo

Venta Normal Solicitar Préstamo

Solicitar Nueva Tarjeta

UNPSJB - 2005 Ingeniería de Software - Clase 6 26

Cliente Verificar Operación

Reintegro Cuenta de Crédito

UNPSJB - 2005 Ingeniería de Software - Clase 6 27

:WInPréstamos :Socio :Video :Préstamo

verificar situación video

UNPSJB - 2005 Ingeniería de Software - Clase 6 28

2: verificar situación socio

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

UNPSJB - 2005 Ingeniería de Software - Clase 6 29

 El Diagrama de Clases es el diagrama principal

UNPSJB - 2005 Ingeniería de Software - Clase 6 30

(Clase y Visibilidad) Asociación

UNPSJB - 2005 Ingeniería de Software - Clase 6 31