Tema 2

Tema 3.
El Lenguaje de
Modelado Unificado
Departamento de Lenguajes y Ciencias de la Computación

E.T.S. de Ingenieros en Informática
Universidad de Málaga
Ingeniería del Software.
Especificación
Contenido
– Introducción
– Modelado estructural
– Modelado del comportamiento
– Modelado arquitectónico
Departamento de Lenguajes y Ciencias de la

Computación. 2
Especificación
 UML es un lenguaje de modelado de software:

– Proporciona un vocabulario y reglas para crear modelos softw.
– Suficientemente expresivo para cubrir distintas vistas de la
arquitectura del software a lo largo del ciclo de vida.
– Mayor nivel de abstracción que un lenguaje de programación.
 UML es un lenguaje para visualizar los elementos de un
gran sistema software, facilitando:
– la comunicación entre los participantes (incluidas herramientas)
en el desarrollo,
– la comprensión de las soluciones (notación gráfica),
– el mantenimiento de las soluciones conceptuales a lo largo del
tiempo (documentación).

Computación. 3
Especificación
 UML es un lenguaje para especificar software:

– Se pueden construir modelos precisos, no ambiguos y
completos.
– Cubre las decisiones de análisis, diseño e implementación.
 UML es un lenguaje para construir software:
– No es un lenguaje de programación visual, pero sus modelos se
pueden conectar de forma directa a una gran variedad de ellos.
– Correspondencias entre UML y lenguajes: Java, C++, etc.
– Ingeniería directa: generación de código.
– Ingeniería inversa: reconstrucción de modelos.
 UML es un lenguaje para documentar:
– requisitos, arquitectura, diseño, código fuente, pruebas, ...

Computación. 4
Especificación
 El modelo conceptual está compuesto por 3

bloques de construcción básicos:
– Elementos
• Abstracciones básicas a partir de las que se construyen los
modelos
– Relaciones
• Entre los elementos
– Diagramas
• Grupo consistente de elementos y sus relaciones

Computación. 5
Especificación
UML: El Lenguaje
Clase Clase Colaboración
Interfaz atributos IInterfaz
Colaboración métodos Clase Act
Estructurales Caso de uso Caso de Uso
atributos
Clases activs métodos
Nodo Componente
Elementos
Componente Nodo
Interacción Interacción
Comportamiento
Máquina de estados Estado
Paquetes
Frameworks
Agrupación Paquete
Modelos
Subsistemas
Anotación Nota Nota

Computación. 6
Especificación
UML: El Lenguaje
Relaciones Dependencia
0..1 *
Asociación
role1 role2
Generalización
Realización
Diagrama de clases
Diagrama de objetos
Diagrama de casos de uso
Diagramas
Diagrama de secuencia
Diagrama de colaboración
Diagrama de estados
Diagrama de actividades
Diagrama de componentes
Diagrama de despliegue
Computación. 7
Especificación
UML: El Lenguaje
Nombres Cliente
nombre
Ámbito Elena:Cliente
Reglas
dirección
Visibilidad
preferencial() :Cliente
Integridad
Ejecución
IUnknown asistOrtog.dll
Especificaciones
Mecanismos
Adornos
Entidad IOrtografía
Divisiones comunes
Instancia «exception»
ColaEventos Overflow
Estereotipo {vers = 3.2
autor=eps}
Extensiones Valor etiquetado
Restricción añadir()
quitar()
Departamento de Lenguajes y Ciencias de la vaciar() {ordenado}
Computación. 8
Especificación
Modelado Estructural: Modelo de

Objetos
 Describe estructura de los objetos de

un sistema:
❈ identidad,
❈ relaciones con otros objetos,
❈ atributos y operaciones
 Es el más característico del Diseño
O.O.
 Gráficamente:
❈ diagramas de clases
❈ diagramas de instancias

Computación. 9
Especificación
Clases e Instancias
:Cliente
Cliente
José:Cliente
nombre
dirección
José Pérez
comprar
Claudia

Computación. 10
Especificación
Atributos y Operaciones
Cada atributo es único en la clase

Sólo datos “simples” y NO otros objetos Clase
Opcionalmente, tipo y valor por defecto
atributos
operaciones
Funciones o procedimientos
Cada operación tiene un objeto destino implícito
Se puede aplicar la misma operación a clases distintas
Opcionalmente, lista de argumentos y tipo devuelto (no omitir)

Computación. 11
Especificación
Punto
x: float :Punto
y: float
x=0
trasladar(dx:float, dy:float)
y=0
distancia(pto: Punto) : float
:Punto
:Punto
x=3.5
x=1 y=2.25
y=2

Computación. 12
Especificación
EEPROM
EEPStart
EEPStop
enviarDir(dir:Tparam) :EEPROM
EnviarByte(dato:Tvalor)
Control(accion:integer)
EEPAck
EEPNoAck

Computación. 13
Especificación
Combo
Protocolo
estado: TEstadoCombo
mensaje: TMensajeMovil movil_origen: TIdMovil
movil_origen: TIdMovil
MandarRegRx(c: Tcanal)
EntradaCombo(m: TMensajeMovil) MandarRegTx(c: Tcanal)
LIGBM() MandarReg0(c: Tcanal)
LL_ENT() MandarRegMode(c: Tcanal)
SILEN() MandarRegGain(c: Tcanal)
FIN_LIG() MandarRegRefP(c: Tcanal)
INTBM() LeerPortadora()
FIN_LLENT() LeerCabecera()
CODSEG() EscribirCabecera()
FININTB() EscribirDato(m: TMensajeBase)
LeerDato(m: TMensajeMovil)
SubirSquelch()
BajarSquelch()
RestituirSquelch()
Computación. 14
Especificación
Enlaces y Asociaciones
 Enlace: conexión entre dos o más instancias

 Asociación: abstracción de un grupo de
enlaces
 Todos los enlaces de una misma asociación:
❈ conectan objetos de las mismas clases
❈ tienen una semántica común
 Asociaciones inherentemente bidireccionales
 Pueden ser: binarias, ternarias o de orden
superior

Computación. 15
Especificación
Asociaciones
Clase Clase
atributos asociación atributos
operaciones operaciones
Multiplicidad 0o1
Muchos
n Exactamente n
m,n mon
m-n Entre m y n
n+ Más de n
Exactamente 1
Direccionalidad
Computación. 16
Especificación
Punto intersecta +2 Línea

x: float ángulo: float
y: float
trasladar(dx:float, dy:float)
trasladar(dx:float, dy:float) punto_referencia distancia(pto: Punto) : float
distancia(pto: Punto) : float rotar(ang: float)
L1
P1:Punto L1:Línea P2
P1
L2
P2:Punto L2:Línea
L3
L4
P3:Punto L3:Línea
L4:Línea
P3
Computación. 17
Especificación
GestorLEDs
inicializar()
llamadaEntrante()
leds tomaDeLínea()
colgar()
pilaBaja()
modoContestador()
6 ...
LED
ident: LEDID
parpadea(te:Duration, ta:Duration)

Computación. 18
Especificación
Proyecto Lenguaje
Persona
C:Lenguaje Eole400:Proyecto Ensamblador:Lenguaje
Luis:Persona José María:Persona
CentralNuclear:Proyecto Fortran:Lenguaje

Computación. 19
Especificación
Asociaciones con Atributos
 Las asociaciones pueden tener atributos

 Propiedad de la asociación. No puede
incluirse en ninguna de las clases
asociadas
 Cuando hay multiplicidad 1/1 o 1/M, el
atributo puede incluirse en la clase de
multiplicidad 1
 A veces, este tipo de asociación se
puede modelar como una clase
independiente

Computación. 20
Especificación
Clase Clase
atributos atributos
operaciones operaciones
atributo

Computación. 21
Especificación
acceso
Fichero Usuario
permiso de acceso
trabajo
Empresa Persona
sueldo
puesto

Computación. 22
Especificación
Roles
 Un rol es un extremo de una asociación

 Una asociación binaria tiene dos roles
 Se pueden nombrar explícitamente:
❈ para recorrer asociaciones, y
❈ para especificar direccionalidad
 Los nombres de los roles:
❈ deben ser únicos en asociaciones que parten de una
misma clase
❈ son necesarios para asociaciones entre objetos de la
misma clase

Computación. 23
Especificación
Clase Clase
atributos rol rol atributos
operaciones asociación operaciones

Computación. 24
Especificación
propietario padre
Usuario Directorio
usuario_autorizado
subdirectorios

Computación. 25
Especificación
Protocolo
Combo
estado: TEstadoCombo mensaje: TMensajeMovil
movil_origen: TIdMovil movil_origen: TIdMovil
... EntradaCombo(m: TMensajeMovil)
LIGBM()
LL_ENT()
SILEN()
FIN_LIG()
INTBM()
CtrlCombo FIN_LLENT()
ultimoCanal: Tcanal CODSEG()
estado: TEstadoCtrlCombo FININTB()
inicioComunicación
finComunicación mensajes recepción
enviarMensaje(m:TMensajeBase)
noPortadora emisión

Computación. 26
Especificación
LED
ident: LEDID
led_que_enciende
Temporización
tEncendido:Duration
tApagado: Duration
tSilencio: Duration

Computación. 27
Especificación
Restricciones en Asociaciones
 Con las propiedades vistas hasta ahora se

pueden modelar la mayoría de las relaciones
estructurales
 Sin embargo, existen algunas que son más
fácilmente expresables con las siguientes
restriciones
– {ordered}/{sorted} indica que los objetos están ordenados
– {implicit} indica que la relación no es manifiesta, solo
conceptual
– {changeable} se pueden modificar los enlaces
– {addonly} solo se pueden añadir
– {frozen} no se pueden modificar

Computación. 28
Especificación
Clase Clase
atributos {ordered} atributos

Computación. 29
Especificación
{ordered}
Ventana Pantalla
visibilidad
{sorted}
Alumnos Curso
calificación

Computación. 30
Especificación
Puerto Teclado
{ordered} ultimaTecla
leerNivel() puertosTeclado ...

Computación. 31
Especificación
Asociaciones Calificadas
 Relacionan dos clases y un
calificador
 El calificador es un atributo especial
que:
❈ reduce la multiplicidad de la asociación,
❈ clasifica el conjunto de objetos del extremo
“muchos”,
❈ puede considerarse como una asociación
ternaria.
 Partición disjunta de la asociación

Computación. 32
Especificación
Clase Clase
atributos atributos
disminuye multiplicidad
Clase Clase
atributos atributos
calificador

Computación. 33
Especificación
contenido
Directorio File
contenido
Directorio nombre File
empleados
Empresa Persona
empleados
Empresa departamento Persona

Computación. 34
Especificación
LED
ident: LEDID GestorLEDs

led inicializar()
3 llamadaEntrante()
ledsPuerto tomaDeLínea()
colagar()
pilaBaja()
modoContestador()
...
tipoEvento
Temporización
tEncendido:Duration parpadeoLed
tApagado: Duration
tSilencio: Duration

Computación. 35
Especificación
Restricciones
A veces es necesario especificar

restricciones
– sobre objetos asociados
– sobre atributos de un objeto
– sobre la vida de los objetos
– sobre enlaces
 Se expresan en lenguaje natural o con
fórmulas

Computación. 36
Especificación
Empleado directivo Ventana

salario anchura
altura
subordinado {anchura<altura}
{salario < directivo.salario}
miembro
Persona {subconjunto} Comisión
presidente

Computación. 37
Especificación
Agregación
 La agregación es un tipo especial de

asociación
 Modela la relación “ser parte de”
 Transitiva y antisimétrica
 Es usual la propagación de operaciones
entre un objeto y sus componentes
 La existencia de un objeto componente
suele depender de la existencia del
objeto compuesto

Computación. 38
Especificación
Clase Clase
atributos atributos

Computación. 39
Especificación
Polígono dibujar Punto
dibujar() vértices dibujar()

Computación. 40
Especificación
Puerto Teclado
3 {ordered}
ultimaTecla
puertosTeclado
leerNivel() ...
Display LED
InterfazExterno

Computación. 41
Especificación
Agregación
 Fija (lámpara) Lámpara
 Tulipa Bombilla Pie

 Variable (empresa-departamento)
Empresa
 *
Departamento
 Recursiva (sentencia-bloque)
Sentencia *

S. Simple Bloque
– No es implementable eficientemente.
– En algunos casos puede llegar a no permitirse.
Computación. 42
Especificación
Herencia
 Generalización o Especialización
 Encapsulamiento de características
comunes
 Reutilización y Extensión
 En la notación gráfica:
❈ Posible uso de “discriminadores”
❈ Herencia disjunta y no disjunta
❈ Redefinición de métodos
❈ Clases abstractas
❈ Herencia múltiple

Computación. 43
Especificación
Herencia con
SuperClase solapamiento
atributos
Herencia con
operaciones discriminador discriminador
SubClase SubClase SubClase

atributos atributos atributos
...
operaciones operaciones operaciones
Computación. 44
Especificación
Punto Figura
área(): float {abstract}

perímetro(): float {abstract}
Polígono Elipse
perímetro(): float área(): float

perímetro(): float
Triángulo Cuadrado
Círculo
área(): float área(): float
Departamento de Lenguajes y Ciencias de la perímetro(): float
Computación. 45
Especificación
LED GestorLEDs
leds
ident: LEDID
6 inicializar()
parpadea(te:Duration, ta:Duration) llamadaEntrante()
tomaDeLínea()
colagar()
pilaBaja()
modoContestador()
...
LEDPuerto LEDRegistro
encender()
apagar()
3
3 ledsRgto
ledsPto
Computación. 46
Especificación
Herencia Múltiple
Computador Identificación
PC Smart Card DNI
 La herencia múltiple permite a una clase tener más de una
superclase, heredando las características de todos sus padres.
↓ Complica las jerarquías de herencia, que dejan de ser árboles para
convertirse en grafos.
↑ Incrementa las posibilidades de reutilización.
↓ Pérdida de simplicidad conceptual y de implementación.
 Problemas: conflictos y herencia repetida.
Computación. 47
Especificación
Herencia Repetida
Vehículo
Vehículo Terrestre Vehículo Acuático
Coche Vehículo Anfibio Bote
Se puede
– Prohibir situaciones conflictivas (C++, Eiffel)
– Usar un heurístico para linealizar el árbol de herencia
(CommonLoops)
– Prohibir la herencia múltiple (Java)
Computación. 48
Especificación
Relaciones de Dependencia
 Dependencia=Relación de uso
origen * destino
 Se da cuando el cambio en un elemento puede

afectar a otro elemento que lo utiliza pero no
necesariamente a la inversa
 Etiquetas especiales:
– bind (el destino es una plantilla instanciada por el origen)
– instantiate (el origen crea instancias del destino)
– instanceOf (el origen es instancia del destino)
– refine (el origen está a un grado de abstracción más detallado que el
destino)
– use (la semántica del origen depende de la del destino)

Computación. 49
Especificación
Ampliando los modelos

 Notas
No controla saldo
– Expresa comentarios o aclaraciones
del cliente
relativas a un elemento o grupo de ellos.
 Responsabilidades
ControlVentas
– Contrato u obligación de una clase
– Se expresan mediante texto libre
 Estereotipos Responsabilidades
--determinar validez venta
– Crea nuevos tipos de bloques de --comunicar a Almacen y
construcción específicos al problema Contabilidad
que se modela. No confundir con
superclase.
– Se expresa mediante un nombre entre <<excepción>>
comillas tipográficas. VentaRechazada
razón

Computación. 50
Especificación
Adornos para Clasificadores

 Son elementos de
modelado que pueden
tener instancias
– Interfaz, Tipo de datos,
Señal, Componente, Tarjeta
Nodo, Casos de uso,
Subsistema. - Saldo:long
- PIN:int
 Visibilidad # Límite:long = 25.000
+ Public + GetSaldo: long
# Protected + Recarga(long cant)
+ Comprobar(long cant):boolean
- Private
 Alcance
instancia
clasificador

Computación. 51
Especificación
Especificación de Atributos
 Formato atributos
[visibilidad] nombre [multiplicidad] [:tipo]
[=valor inicial] [{propiedades}]
Propiedades predefinidas: changeable, addOnly, frozen
Tarjeta
- Saldo:long
- PIN [1..*] : int {addOnly}
# Límite:long = 25.000
+ GetSaldo: long
+ Recarga(long cant)
+ Comprobar(long cant):boolean

Computación. 52
Especificación
Especificación de Operaciones
 Formato operaciones
[visibilidad] nombre [(lista parámetros)]
[:tipoDevuelto] [{propiedades}]
Propiedades predefinidas: isQuery, ...(para concurrencia)
 Formato parámetros
[dirección] nombre : tipo [=valor defecto]
direcciones: in,out, inout
Tarjeta
- Saldo:long
- PIN [1..*] : int {addOnly}
# Límite:long = 25.000
+ GetSaldo: long {isQuery}
+ Recarga(long cant)
+ ComprobarPIN(int pinPrueba):boolean

Computación. 53
Especificación
Interfaces
 Interfaz: colección de operaciones que se usa para
especificar un servicio de una clase o componente.
 Si es necesario puede
representarse como una
Tarjeta Multifunción
clase estereotipada. No
tendrá atributos ni métodos;
sólo operaciones.
 Las operaciones pueden
incluir adornos como IIdentificación IPago
estereotipos, valores <<interface>>
etiquetados, restricciones y IPago
propiedades de visibilidad y GetSaldo()
concurrencia. Recarga()
Computación. 54
Especificación
Paquetes
 Un paquete es un elemento de propósito general
para organizar elementos del modelo en grupos.
 Puede contener clases, interfaces, nodos,
colaboraciones, casos de uso, diagramas e incluso
otros paquetes.
 Un paquete forma un espacio de nombres.
 Estereotipos estándar: Cliente
framework, subsystem, system
stub, facade +FormularioDePedido
+FormularioDeEstado
- Pedido

Computación. 55
Especificación
Paquetes
 Visibilidad.
 Importación y Exportación.
Cliente
 Generalización.
+FormularioDePedido
GUI +FormularioDeEstado
- Pedido
+Ventana
+Formulario
#GestorEventos <<import>>
exportación
WinGUI
LinuxGUI

Computación. 56
Especificación
Consejos Prácticos
 No lanzarse a dibujar clases y asociaciones sin sentido.
 Intentar que el modelo sea simple, evitando complicaciones
innecesarias.
 Los nombres deben ser significativos.
 No incluir en los objetos punteros a otros objetos.
 Utilizar, si es posible, asociaciones binarias. Utilizar
preferentemente asociaciones calificadas en vez de ternarias o
con atributos.
 Dejar la definición de la multiplicidad para cuando se tenga un
mejor conocimiento del problema.
 No incluir los atributos de las asociaciones en las clases.
 Evitar las jerarquías de composición o generalización de
muchos niveles.
 Revisar el modelo hasta que sea satisfactorio.
 Documentar el modelo.
 Utilizar sólo los elementos necesarios.
Computación. 57
Especificación
Contenido
– Introducción
• Modelado Básico
• Interacciones
• Diagramas de interacción
• Casos de uso y diagramas
• Diagramas de actividades
• Modelado Avanzado

Computación. 58
Especificación
Interacciones
 Definición
Una interacción es un comportamiento que implica un
intercambio de de mensajes entre varios objetos en un
contexto determinado con un objetivo determinado
 Se utilizan para expresar los aspectos dinámicos
de las colaboraciones
 Las interacciones se llevan a cabo entre objetos
no entre clases
 Un enlace es una conexión semántica entre
objetos
– Para que se pueda enviar un mensaje entre dos objetos
debe existir un enlace
– Un enlace es una instancia de una asociación entre
clases
Computación. 59
Especificación
Interacciones
Persona Empresa
1..* *
Asignar(d:Departamento) empleado contratante
Asociación
Asignar(desarrollo)
P:Persona :Empresa
Enlace
Computación. 60
Especificación
Interacciones
 Normalmente basta con indicar que existe un enalce, pero
se puede indicar el tipo de enlace utilizando los
estereotipos:
– Association
– Self
– Global
– Local
– Parameter
 Los mensajes también pueden ser más o menos detallados
[Pre] 1:*(expr):mensaje(p,q):Valor
Precondición Valor de
Retorno
Nº secuencia Parámetros
Expresión Identificador
Iteración
Computación. 61
Especificación
Diagramas de Interacción
 Hay dos tipos:
– Diagramas de secuencia
– Diagramas de colaboración
 Son dos de los cinco que se utilizan para
modelar el comportamiento dinámico de
los sistemas
 Un diagrama de interacción consiste en:
– Un conjunto de objetos (no clases) y sus
relaciones
– Los mensajes que se pueden enviar entre ellos

Computación. 62
Especificación
 Un diagrama de secuencia es un diagrama en el
que se destaca la ordenación temporal de los
eventos
 Un diagrama de colaboración destaca la
organización estructural de los objetos que
envían y reciben los mensajes
 Son semánticamente equivalentes
– Se puede generar uno a partir del otro, sin perdida de
información
– Visualmente, sin embargo, esta información puede ser
más difícil de percibir

Computación. 63
Especificación
Diagramas de Secuencia
 Los diagramas de secuencia se suelen asociar a los casos de
uso, mostrando como estos se realizan a través de
interacciones entre sociedades de objetos
Consola BD
: Instructor Instructor instructores
Foco de
1: login(usuario)
2: leer(usuario) Control
Línea de
3: usuario correcto
Vida
4: iniciar sesion
5: usuario aceptado

Computación. 64
Especificación
 Los mensajes se
corresponden Cliente Interfaz
generalmente a : Alumno
Aplicación Cliente
métodos de los 1: login
objetos 2: crear sesion
 Los objetos pueden 3: create

Sesion
ser creados durante
la ejecución
 En Rational Rose, la 4: logout
5: fin 6: destroy
creación de objetos
no se puede reflejar
de la forma estándar

Computación. 65
Especificación

Computación. 66
Especificación
Diagramas de Colaboración
 Destacan la organización de los objetos que
participan en una interacción
 Es un grafo en el que los nodos son los objetos y

los arcos los enlaces
 Los arcos se etiquetan con los mensajes que

envían y reciben los objetos
 Dan una visión del flujo de control en el contexto

de la organización de los objetos que colaboran

Computación. 67
Especificación
 Hay dos características que los distinguen
de los diagramas de secuencia:
– El camino
• Para indicar como se enlazan los objetos se utilizan
estereotipos en los extremos de los enlaces (local,
global y self)
– El número de secuencia
• Para indicar la ordenación de los mensajes se utiliza
la numeración decimal de Deway (1, 1.1,.....)

Computación. 68
Especificación

Computación. 69
Especificación
Equivalencia entre Diagramas
 Utilizando el submenu Browse se puede generar un diagrama a

partir del otro
4: iniciar sesion
Consola BD
1: login(usuario) : Instructor Instructor instructores
Consola
Instructor
5: usuario aceptado 1: login(usuario)

2: leer(usuario)
: Instructor
3: usuario correcto
3: usuario correcto
2: leer(usuario)
4: iniciar sesion
BD 5: usuario aceptado
instructores

Computación. 70
Especificación
 No tienen por que utilizarse sólo para los

casos de uso
 Son útiles para modelar aspectos
dinámicos de cualquier interacción entre
cualquier instancia en cualquier vista del
sistema (clases, interfaces,
componentes,...)
 Las interacciones se pueden “adornar”
con restricciones temporales (marcas
temporales)

Computación. 71
Especificación
Consola BD
: Instructor Instructor instructores
inicio 1: login(usuario)
2: leer(usuario)
3: usuario correcto
4: iniciar sesion
{Iniciar sesion.executionTime<5s}
5: usuario aceptado
fin
{inicio-fin<10s}

Computación. 72
Feb 10, 2008
Especificación
Casos de Uso
 Se utilizan para especificar el comportamiento
deseado del un sistema o subsistema
– Describe el conjunto de secuencias de acciones que
lleva a cabo el sistema para producir un resultado para
un actor.
– Capturan el comportamiento deseado del sistema, sin
especificar como se lleva a cabo dicho comportamiento
 Principalmente son un medio de comunicación
para que los desarrolladores y los usuarios
lleguen a un consenso en la especificación
 Ayudan a validar el sistema durante el desarrollo

Computación. 73
Especificación
Casos de Uso
 Los casos de uso son principalmente
descripciones textuales
 La notación gráfica de UML (diagrama de
casos de uso) solo muestra los nombres y
sus relaciones
 Al ser textuales, son informales y no son
buenas para razonar acerca del sistema
– Es mejor utilizar los diagramas de interacción
resultantes de su formalización

Computación. 74
Especificación
Casos de Uso
 Un caso de uso es una descripción de las
posibles secuencias de interacción entre
el sistema y actores externos en relación
a el objetivo de un actor particular
 Un caso de uso sigue normalmente
cuatro fases:
1. El actor envía al sistema una petición y los datos
necesarios para llevarla a cabo
2. El sistema valida la petición y los datos
3. El sistema altera su estado interno
4. El sistema devuelve el resultado al actor

Computación. 75
Especificación
Casos de Uso
 Los casos de uso se pueden detallar a muy
distintos niveles de granularidad
 Se suelen distinguir los siguientes niveles:
– Nivel de resumen: muestran ciclo de vida de la
secuencia de objetivos directamente relacionadas.
• Se pueden considerar como una tabla de contenidos de
casos de uso de niveles más detallados
– Nivel de usuario: describen el objetivo del actor cuando
intenta llevar a cabo una acción sobre el sistema
– Nivel de subfunción: son casos de uso requeridos para
llevar a cabo los de usuario, con un mayor nivel de
detalle
• Pueden ser considerados prácticamente como manuales
de operación

Computación. 76
Feb 10, 2008
Especificación
Casos de Uso
 Un actor representa un conjunto
coherente de roles que los usuarios de los
casos de uso juegan al interactuar con
ellos
– Normalmente representan a una persona, un
dispositivo hardware u otro sistema al
interactuar con el nuestro
 Se pueden definir categorías generales de
actores y especializarlos a través de la
relaciones de generalización
 Los actores se conectan a los casos de
uso mediante asociaciones.
Computación. 77
Feb 10, 2008
Especificación
Casos de Uso

Computación. 78
Especificación
Diagramas de Casos de Uso

 Se pueden organizar en paquetes
 Se pueden especificar relaciones entre
ellos:
– generalización
– extensión
– inclusión
 Estas relaciones se usan para:
– Factorizar el comportamiento común
• extrayendo un comportamiento de los casos en que
se incluye
– Factorizar variantes
• poniendo ese comportamiento en otros casos de
uso que lo extienden
Computación. 79
Especificación

 Generalización
– El caso de uso hijo hereda el comportamiento
y el significado del caso de uso padre
– El hijo puede añadir o redefinir el
comportamiento del padre
– El hijo se puede colocar en cualquier lugar en
que aparezca el padre
 Inclusión
– El caso de uso base incorpora explícitamente
el comportamiento del caso de uso incluido
– El caso de uso incluido forma parte de otro
más complejo
– Se utiliza para evitar describir flujos repetidos
Computación. 80
Especificación
logout
<<include>> modificar parámetros
<<include>>
acciones instructor
sesion instructor <<include>> cambiar estado
login controlCI
Instructor
control backtrack
sesión alumno

Computación. 81
Especificación
 Extensión
– Se utilizan para modelar la parte de un caso de
uso que puede ser vista como un
comportamiento opcional
– También se pueden utilizar para modelar un
subflujo separado que solo se ejecuta bajo
ciertas condiciones
• Un ejemplo es el modelado de varios flujos que se
puedan dar en un punto dado por la interacción
explicita con un actor

Computación. 82
Especificación
identificación
<<include>>
Alumno sesion alumno <<include>>

<<extend>>
Acción errónea
Acciones de Alumno
Petición de valores Activar vble dinámica
Todos los valores

Valores cambiados Selección

Computación. 83
Especificación
Nacional
<<includes>>
Marcar Número
<<extends>> Internacional
Realizar Llamada
Llamante
<<extends>>
<<extends>>
Numero no existe
<<extends>>
Numero Incorrecto
Comunicando
Recibir Llamada
Llamado
<<extends>> No hay linea
Llamada no atendida
Computación. 84
Especificación
Identificar Cliente Identificar Cliente y Cuenta en
Cajero Automático
<<includes>>
<<includes>> <<includes>>
<<includes>>
Obtener un Balance
Ingresar Dinero Transferir Dinero Sacar Dinero
<<includes>>
<<includes>>
<<includes>>
Correo
Ciclo de Vida Cuenta
Cajero Cliente Cajero Automático

Computación. 85
Especificación
Casos de Uso
 Niveles:
– Resumen
• Ciclo de vida Cuenta
– Usuario
• Ingresar Dinero
• Transferir Dinero
• Obtener un Balance
• Sacar Dinero
– Subfunción
• Identificar Cliente
• Identificar Ciente y Cuenta en Cajero Automático

Computación. 86
Especificación
Cuestionario de Casos de Uso

 Se utilizan para dar un formato uniforme a la
explicación textual de los casos de uso
Caso de uso: Nombre del caso de uso
Este es el objetivo del caso de uso descrito con una
frase corta
Ámbito: La “caja negra” considerada
Nivel: Uno de los tres niveles anteriores
Contexto de uso: Una frase más larga con la
descripción del objetivo y las condiciones normales de
desarrollo
Actor Principal: Un nombre de rol del actor principal o
su descripción
Escenario de Éxito Principal: ...
Extensiones: ...

Computación. 87
Especificación
Escenario de Éxito Principal:
Número_de_Paso "." descripción_de_acción

Se numeran todos los pasos del escenario desde
el disparo al objetivo
Se pueden anidar, utilizando numeración de
Dewey (3.1.2)
No se deben incluir sentencias condicionales; las
condiciones y alternativas se muestran en la parte
de extensión
Extensiones: ...

Computación. 88
Especificación
Extensiones:
Condición especial ":" Descripción de acción
| sub-caso de uso
Siempre se refiere a un paso del escenario principal
Una extensión o sustituye al paso principal o es una

alternativa. La notación utilizada es:
Sustitución: 2 ||
Alternativa: 2a
Una alternativa puede corresponder a un

comportamiento regular, excepcional recuperable o
erróneo no recuperable

Computación. 89
Especificación
Ejemplo
Caso de uso: Ciclo de Vida de Cuenta
Ámbito: El sistema completo

Nivel: Resumen
Contexto de uso: Para interactuar con el sistema el
cliente es representado por un cajero o por cajero
automático
Actor Principal: Cliente

Computación. 90
Especificación
Ejemplo

2. Un cliente informa al cajero de que quiere abrir una
cuenta
3. En representación del cliente el cajero inicia la
apertura de la cuenta en el sistema
4. El sistema solicita al cajero la siguiente
información:
Nombre
Dirección
DNI
Tipo de Cuenta
5. El sistema valida la información y crea la cuenta del
cliente

Computación. 91
Especificación
Ejemplo
Los pasos del 5 al 8 son opcionales,
individualmente repetibles y pueden ocurrir en
cualquier orden
 El cliente ingresa dinero – sub-caso de uso

 El cliente obtienen un balance – sub-caso de uso
 El cliente saca dinero – sub-caso de uso
 El cliente transfiere dinero – sub-caso de uso
 Este paso se repite indefinidamente una vez al mes
desde la fecha de apertura hasta fecha de cierre
El Sistema envía por correo ordinario la información
de su cuenta al cliente
10. El cajero, en representación del cliente, inicia el
cierre de la cuenta
11. El sistema elimina la cuenta
12. El sistema
Departamento envia yun
de Lenguajes balance
Ciencias de la con los últimos
movimientos
Computación. 92
Especificación
Ejemplo
Extensiones:
4a. El sistema informa que el cliente ya tiene una cuenta
de este tipo abierta
4a.1. El sistema solicita al cajero que confirme la
creación de la cuenta
4a.2a. El cajero confirma la creación y el caso de
uso continua por el paso 3
4a.2b. El cliente decide no crearla y el caso de
uso finaliza sin ningún efecto sobre el
estado
........

Computación. 93
Especificación
Casos de Uso. Resumen

 Los diagramas de casos de uso pueden
ser vistos como un mapa general de las
funcionalidades más importantes des
sistema
 Deben ser lo suficientemente claros para
que alguien externo al sistema los
entienda
 Los casos de uso se deben utilizar para:
– Modelar el contexto del sistema
• Especificar las fronteras e identificar los actores
– Modelar los requisitos del mismo
• Especificar que debe hacer el sistema desde el
punto de vista externo
Computación. 94
Especificación
Casos de Uso. Resumen

 Los casos de uso son la base para
establecer las pruebas del sistema
– Para este cometido deben ir refinandose a lo
largo del desarrollo
 También pueden utilizarse en ingeniería
inversa. En este caso los pasos a seguir
son:
– Identificar cada actor que interactúa con el
sistema
– Trazar el flujo de eventos del sistema
ejecutable en relación con cada actor
– Agrupar flujos relacionados en casos de uso
– Organizarlos utilizando las relaciones vistas
Computación. 95
Especificación
Contenido
– Introducción
• Interacciones
• Diagramas de interacción
• Casos de uso y diagramas
• Diagramas de actividades

Computación. 96
Feb 10, 2008
Especificación
Diagramas de Actividades
 Sepueden considerar un caso especial de
máquina de estados en la que:
– La mayoría de los estados son actividades
– La mayoría de las transiciones se disparan
implícitamente por la terminación de acciones
 Diferencias con un diagrama de estados.
– Un diagrama de actividad se usa para modelar
una secuencia de acciones en un proceso
– Un diagrama de estados para modelar los
estados discretos de un objeto a lo largo de su
ejecución.

Computación. 97
Especificación
Diagramas de Actividades
Solicitar
Producto
Procesar Extraer
Pedido Artículos
Enviar Pedido
Recibir Facturar al
Pedido Cliente
Pagar
Factura
Cerrar Pedido

Computación. 98
Especificación
Diagramas de Actividad
Elementos Básicos
Estado Inicial Estado Final

Actividad
Acción Actividad
Estado
Transición
Estado sin Disparador
Actividad
Condición
División Unión

Computación. 99
Especificación
 Estados:
– Las acciones son un tipo especial de estado
– UML no impone un lenguaje para expresar las acciones,
pero se suele utilizar la sintaxis y semántica de un
lenguaje de programación
 Transiciones:
– Son transiciones sin disparadores o de terminación
– El flujo de control pasa inmediatamente al siguiente
estado después de finalizar la tarea del estado origen
– El flujo continua indefinidamente hasta que se
encuentra un estado de parada (puede haber flujos
infinitos)

Computación. 100
Especificación
 Bifurcación:
– Tienen una entrada y dos o más salidas
– En cada transición de salida se incluye una guarda
– Se puede dejar una salida sin especificar (else)
– UML no impone el lenguaje de las guardas (también se
suele utilizar un lenguaje de programación especifico)
Seleccionar
Trabajos
Replanificar
[Hay Materiales]
Asignar Tareas

Computación. 101
Especificación
Calles y Flujos de Objetos
 Calles
– Representan una división de actividades en grupos,
normalmente asignados a objetos o subsistemas
– Cada calle tiene un nombre único en un diagrama
– Existe una relación entre calles y flujos concurrentes
 Flujos de Objetos
– Se pueden asignar objetos concretos a actividades y
reflejarlos en el diagrama
– También se puede indicar como cambian sus atributos, su
estado y sus roles a lo largo del flujo

Computación. 102
Especificación
Calles y Flujos de Objetos
Cliente Ventas Almacen

O:Pedido
Solicitar [en progreso]
Producto
Procesar Extraer
Pedido Artículos
Enviar Pedido
Recibir Facturar al O:Pedido

Pedido Cliente
[completado]
Pagar
Factura
Cerrar Pedido

Computación. 103
Especificación
Diagramas de Actividad. Usos Comunes
 Son diagramas de tipo general que pueden

involucrar la actividad de cualquier tipo de
abstracción en cualquier vista (clases, componentes,
nodos,...)
 Sin embargo, se suelen utilizar para:
– Modelar un flujo de trabajo
• Se hace hincapié en actividades tal y como las ven los actores
– Para modelar una operación
• Se utilizan como diagramas de flujo, para modelar los detalles
de una computación

Computación. 104
Especificación
Diagramas de Actividad. Modelado de una

operación
 Pueden hacer de UML un lenguaje de programación

visual, pero éste no es el objetivo
 Sólo se debe utilizar en el caso de que sea un
comportamiento:
– Complejo y difícil de entender analizando el código
– Especialmente importante y que sirva de documentación de
algún aspecto fundamental del sistema
 Se pueden utilizar tanto en ingeniería directa como
en ingeniería inversa

Computación. 105
Especificación
Modelado de una operación
Punto Linea::intersec (L:Linea)

{
if (pendiente==l.pendiente) return Punto(0,0)
return
Punto(0,0)
int x= (l.delta-delta)/(pendiente-l.pendiente);
int y=(pendiente*x)+delta;
do/ x=(l.delta-delta)/(pendiente-l.pendiente);
return Punto(x,y);
}
do/ y=(pendiente*x)+delta;
return
Punto(x,y)

Computación. 106
Especificación
Contenido
– Introducción
• Eventos y Señales
• Máquinas de Estados
• Procesos y Hebras
• Modelado arquitectónico

Computación. 107
Especificación
Eventos y Señales
 En UML un evento es la especificación de un

acontecimiento significativo que ocupa un lugar
en el tiempo y en el espacio.
 En el contexto de las máquinas de estados
modelan los estímulos que producen un cambio
de estado.
 Los eventos pueden ser:
– Síncronos:invocación de operaciones.
– Asíncronos:señales, paso del tiempo

Computación. 108
Especificación
Eventos y Señales
 Declaración de un evento
<<Signal>>
Colgar Inactivo
<<signal>>
Colgar / cortarConexion()
Activo

Computación. 109
Especificación
Eventos
 Tipos:
– Externos: entre el sistema y sus actores
(interrupción, pulsación de una tecla,...)
– Internos: entre los objetos del sistema
 Se pueden modelar 4 tipos de eventos:
– Señales
– Eventos de llamada
– Paso del tiempo
– Cambio de estado

Computación. 110
Especificación
Señales
 Son objetos con nombre enviados (lanzados),

asíncronamente por un objeto y capturados por
otro.
 El tipo más común de señales internas son las
excepciones, tal y como son soportadas por los
lenguajes de programación.
 Son una clase en sentido general:
– Pueden existir instancias
– Pueden existir relaciones de generalización
– Pueden tener atributos y operaciones
 Se generan como resultado de una transición en
una máquina de estados de un objeto

Computación. 111
Especificación

Computación. 112
Especificación
Señales
 La relación entre una operación y los eventos
que puede generar se modela con una relación
de dependencia estereotipada como send.
Agente de movimiento
(from eventos)
posición
velocidad
colisión <<send>> moverA()

(from eventos)
fuerza : Float

Computación. 113
Especificación
Eventos de Llamada
 Representan la invocación de una
operación de un objeto
 Son eventos síncronos
 Cuando un objeto invoca una operación
sobre otro objeto que tiene una máquina
de estados:
– el control pasa del emisor al receptor
– el evento dispara la transición
– la operación acaba
– el receptor pasa a un nuevo estado y el control
regresa al emisor
Computación. 114
Especificación
Eventos de Llamada
 No existen señales visuales para distinguir un

evento de señal de un evento de llamada, sólo el
contexto del modelo
 La operación aparecerá declarada en la lista de

operaciones del objeto receptor
 Una señal será manejada por la máquina de

estados y un evento de llamada por un método

Computación. 115
Especificación
Eventos de Tiempo y Cambio

 Un evento de tiempo representa el paso
del tiempo
 Se modela con la palabra after seguida de
una expresión
 El tiempo se mide desde el instante en el
que se entra en el estado
 Un evento de cambio representa un
cambio en el estado o el cumplimiento de
alguna condición
 Se modela con la palabra when seguida de
una expresión booleana

Computación. 116
Especificación
Eventos de Tiempo y Cambio

When (11:49pm) / autotest()
Inactivo
after(2 seg) / cortar conexión
Activo
Aunque un evento de cambio modela un test continuo,

normalmente se transforma en condiciones puntuales
discretos en el tiempo

Computación. 117
Especificación
Envio y Recepción de Eventos

 Los eventos de llamada y de señal implican al menos
dos objetos (el que lo provoca y el que lo trata)
 En ocasiones es necesario modelar el envio de una
señal a un conjunto de objetos (mulicasting) o a
todos los objetos de sistema (broadcasting).
 Multicasting
– Se representa un objeto que envía una señal a una colección
que contendrá un conjunto de receptores
 Broadcasting
– Se mostrará un objeto que envía una señal a otro objeto que
representa el resto del sistema

Computación. 118
Especificación
Señales y Clases Activas

 Los eventos de llamada que pueda recibir un
objeto se modelan como operaciones
 Las señales que puede recibir un objeto se
reflejan en un compartimento extra de la clase
 No son las declaraciones de las señales, sino su
uso.
gestor de Teclado
estado
tipo
reset()
Señales
pulsarBoton(b:boton)
encendido
apagado

Computación. 119
Especificación
Modelado de una familia de señales
 En los sistema dirigidos por eventos, las señales

forman una jerarquía
 Se pueden generar eventos polimórficos y/o

eventos abstractos (para ajustar la jerarquía)
 Una familia de señales se modela principalmente

para especificar los tipos de señales que puede
recibir un objeto activo

Computación. 120
Especificación
Modelado de una familia de señales
Señal de robot
Abstractas
fallo hardware
colision
sensor : integer
fallo batería fallo mecanico Fallo de visión fallo de rango
Atasco Motor

Computación. 121
Especificación
Modelado de Excepciones
 Cuando se especifica un interfaz o una clase,
además de atributos y operaciones, es
conveniente especificar las excepciones
 Las excepciones son un tipo de señales y se

modelan como clases estereotipadas
 Se asocian a la especificación de las operaciónes
 Son lo contrario que las familias de señales:

– Se modelan para especificar las excepciones que puede
generar un objeto a través de sus operaciones

Computación. 122
Especificación
Modelado de Excepciones
Excepción
establecerManejador()
primerManejador()
ultimoManejador()
Duplicado
Overflow
Conjunto
<<send>> <<send>> Underflow
añadir()
eliminar()
<<send>>

Computación. 123
Especificación
Contenido
– Introducción
• Diagramas de estados

Computación. 124
Especificación
Máquinas de Estados
 Una máquina de estados especifica la secuencia
de estados por la que pasa un objeto durante su
vida
 La evolución se produce a causa de eventos,

bien internos, bien enviados desde otro objeto
 También se pueden utilizar para modelar el

comportamiento dinámico de otros elementos de
modelado (instancias de una clase, un caso de
uso o un sistema completo).

Computación. 125
Especificación
Máquinas de estados
 Relación con otros diagramas:
– Diagramas de interacción. Modelan el
comportamiento de una sociedad de objetos,
mientras que la máquina de estados modela el
comportamiento de un objeto individual
– Diagramas de actividades. Se centran en el
flujo de control entre actividades, no en el flujo
de control entre estados.
• El evento para pasar de una actividad a otra es la
finalización de la anterior actividad

Computación. 126
Especificación
Máquinas de estados
 Elementos:
– Estado: condición o situación de un objeto durante la
cual:
• se satisface alguna condición
• se realiza alguna actividad
• se espera algún evento
– Evento: especificación de un acontecimiento
significativo que ocupa un lugar en el tiempo y en el
espacio
• en el contexto de las máquinas de estados, un estímulo
que puede disparar una transición entre estados
– Transición: relación entre dos estados que indica como
los objetos cambian de estado (eventos+condiciones)
– Actividad:ejecución no atómica en curso dentro de una
máquina de estados
– Acción: computación atómica ejecutable que produce
un cambio de estado en el modelo o devuelve un valor
Computación. 127
Especificación
Activo
Timeout
do/ mensaje timeout

after( 15 seg ) tecla( t )[ incompleto ]
after( 15 seg )
Tono de marcado tecla( t ) Marcando
do/ reproducir tono
tecla( t )[ completo ]
tecla( t )[ invalido ]
descuelga / tono de marcado
Invalido
Inactivo
do/ Mensaje invalido Conexión
cuelga / desconectar
Espera ocupado
Comunicando
conectado
do/ tono comunicando
usr. llamado cuelga
Hablando Sonando
responde / habilitar voz do/ tono llamada

Computación. 128
Especificación
Estados
 Elementos:
– Nombre (puede ser anónimo)
– Acciones de entrada/salida (al entrar y salir del
estado)
– Transiciones internas (se manejan sin cambiar
de estado)
– Subestados: estructura anidada que engloba
subestados:
• Secuenciales: subestados disjuntos, es decir activos
secuencialmente
• Concurrentes: activos concurrentemente
– Eventos diferidos: lista de eventos que no se
manejan en eses estado, pero que no se
pierden
Computación. 129
Especificación
Estados

Computación. 130
Especificación
Estados
 Acciones de entrada/salida:
– Se utilizan cuando al entrar o salir de un
estado se requiere realizar una acción
– Son independientes de la transición por la que
se llega o por la que se abandona el estado
– Se puede lograr el mismo efecto con una
máquina de estados plana, pero sería
necesario especificar estas acciones en cada
entrada y salida
– No pueden tener parámetros, ni guardas
– Se representan con entry/acción, exit/acción
dentro del estado
Computación. 131
Especificación
Estados
 Transiciones Internas:
– Son transiciones como respuesta a eventos
que deben ser manejados sin abandonar el
estado
– Son distintas de las autotransiciones:
• En las autotransiciones, se abandona el estado y se
vuelve a él
• Se ejecutan las acciones de entrada y de salida
• Pueden tener eventos con parámetros y guardas
• Son básicamente interrupciones
– Se representan mediante transición/acción,
dentro del estado

Computación. 132
Especificación
Estados
 Actividades:
– Cuando un objeto esta en un estado, puede no
estar ocioso, sino ejecutando alguna tarea
– Estas tareas son las actividades y se ejecutan
de forma continuada hasta que se recibe un
evento
– Para representarlas se utiliza la transición
do/actividad
– Se pueden especificar secuencias do/a1;a2;a3
– En este caso las acciones no se interrumpen,
pero la actividad se puede interrumpir entre
acciones.
Computación. 133
Especificación
Estados
 Eventos diferidos:
– En UML, sólo los eventos especificados son tratados
– Si un evento llega y no esta especificado el
comportamiento en ese estado, se pierde
– Si se quiere conservar un evento, pero no se quiere
tratar, hay que especificarlo como diferido
– Existe una cola interna donde se almacenan estos
eventos
– Son tratados tan pronto como el objeto entra en un
estado que no difiere estos eventos
– Se especifica nombre_evento/defered, dentro del estado

Computación. 134
Especificación
Estados

Computación. 135
Especificación
Transiciones
 Una transición tiene cinco partes
– Estado orígen
– Evento de disparo
– Condición de guarda
– Acción
– Estado destino
 Una transición puede tener:
– Muchos Orígenes (join): unión de estados
concurrentes
– Muchos Destinos (fork): división en múltiples
estados concurentes
Computación. 136
Especificación
Transiciones
Registration
Add student[ Count < 10 ]
Add student / Set

Initialization count = 0 Open
exit/ update database

do/ refresh screen
on select window( window )/ display new window
Cancelled
Cancel course [ Count = 10 ]
^CourseReport.Create
Closed

Computación. 137
Especificación
Subestados
 Ayudan a simplificar las máquinas
complejas
 Pueden ser concurrentes y secuenciales
 Subestados secuenciales:
– Sólo un estado dentro del subestado está
activo al mismo tiempo
– Se pueden especificar transiciones comunes a
todos los subestados (cancelar en el ejemplo)
– Pueden tener o no un estado inicial
– Cómo máximo pueden tener un estado inicial y
otro final
Computación. 138
Especificación
Subestados
inicializar( Nombre Simulador )
idle Cargar IC
cargar nueva IC
freeze
Pasar a Run[ IC cargada ] ^Gestor MC.pasar_a_run

freeze
run
En Ejecución
comando simulación
run Interpretar
comando
after 0.5 seg
H* Esperar
Enviar Confirmación
Información

Computación. 139
Especificación
Subestados
 Estados de historia
– Cuando una transición entra en un subestado
compuesto, por defecto, la máquina anidada
empieza de nuevo su ejecución, a menos que
la transición sea a directa
– A veces se requiere recordar el último
subestado que estaba activo antes de
abandonar el subestado compuesto
– Ej. ¿Cómo se podría hacer con una máquina
plana?
– En UML un estado de historia permite que se
recuerde el último subestado
Computación. 140
Especificación
Subestados
 El símbolo H representa una historia superficial, recuerda el

estado de la submáquina inmediata
 Para recordar el estado más interno a cualquier profundidad se
utiliza H*

Computación. 141
Especificación
Subestados
 Subestados concurrentes:
– Permiten especificar dos o más submáquinas que se
ejecutan en paralelo en el contexto del objeto
– Para describir un subestado concurrente es necesario
especificar un estado por cada submáquina
 En lugar de dividir el estado de un objeto en
estados concurrentes se pueden definir dos
objetos activos, con su propia máquina
 Si el comportamiento de uno de los objetos
depende del estado del otro es mejor usar
subestados

Computación. 142
Especificación
Subestados
 Si los comportamientos dependen sólo de los
mensajes, es mejor utilizar objetos activos
 Si hay poca o ninguna comunicación es
indiferente usar uno u otro, aunque en general es
más claro usar objetos activos
Inactivo
mantener
Mantenimiento
Probar Autodiagno
Perifericos sis
continuar
Espera Orden
tecla pulsada

Computación. 143
Especificación
Contenido
– Introducción

Computación. 144
Especificación
Procesos y Hebras
 Cualquier sistema contiene elementos

activos (al menos uno)
– Un elemento activo es aquel capaz de iniciar
una acción por si mismo
– Un elemento pasivo es aquel que sólo ejecuta
operaciones porque otros las invocan
– Los elementos activos son complejos:
• Concurrencia, comunicación y sincronización
 UML modela los elementos activos como
objetos activos

Computación. 145
Especificación
Procesos y Hebras
 Cada flujo de control independiente se modela
como un objeto activo
 Distinguimos dos tipos de objetos activos:
– Procesos: Flujo pesado, que se ejecuta
concurrentemente con otros procesos y que,
normalmente, dispone de un espacio de direcciones
independiente
– Hebras: Flujo que se ejecuta dentro de un proceso. Un
mismo proceso puede tener varios flujos de control que
comparte el espacio de direcciones
 Esta distinción coincide con la existente en la
mayoría de los sistemas operativos actuales
(POSIX, NT)

Computación. 146
Especificación
Procesos y Hebras
 Los objetos activos son instancias de

clases activas
 La comunicación entre objetos activos es
también mediante paso de mensajes, pero
con una semántica distinta
– Los mensajes ayudan a sincronizar las
interacciones de flujos independientes
 La concurrencia a este nivel se especifica
de forma independiente del sistema y
puede ser real o simulada (esto se
indicará en el diagrama de despliegue)
Computación. 147
Especificación
Procesos y Hebras
 Representación Gráfica:
<<active>>
Control comunicacion
Control comunicacion
estado estado
Ultimo mensaje Ultimo mensaje
reset() reset()
Señales Señales
mensaje recibido mensaje recibido
error_enviar error_enviar
error_recibir error_recibir
 En realidad se trata de un estereotipo

 En Rational Rose, no existe este
estereotipo, hay que crearlo

Computación. 148
Especificación
Procesos y Hebras
 Para crear un estereotipo

que solo este disponible
en un modelo basta con
incluirlo en el campo de
estereotipo de la
definición de clase

Computación. 149
Especificación
Procesos y Hebras
 Los estereotipos pueden
tener iconos asignados o
no
 Además se puede mostrar
el nombre o el icono o no
distinguirlos de los
elementos normales de
UML
 Para definir estereotipos
permanentes es necesario
modificar:
– DefaultStereotypes.ini
– Especificar un nuevo
icono

Computación. 150
Especificación
Procesos y Hebras
 Todos los mecanismos de extensibilidad

de UML pueden aplicarse a las clases
activas
 Aparte del estereotipo de clase activa se
distinguen otros dos, equivalentes a los
conceptos de proceso y hebra en los
sistemas operativos:
– process
– thread

Computación. 151
Especificación
Procesos y Hebras
 En Rational Rose los objetos activos se pueden especificar
en la definición de la clase, pero no como estereotipo:

Computación. 152
Especificación
Comunicación entre Procesos

 El paso de mensajes tiene una semántica distinta
dependiendo de si los objetos son activos o
pasivos:
– De pasivo a pasivo: se trata de la simple invocación de
una operación
– De activo a activo:
• Rendezvous o cita:
– El emisor envía el mensaje y espera a que sea aceptado
– El receptor lo acepta e invoca la llamada (el emisor sigue
esperando)
– Se devuelve el resultado (si lo hay) y los dos siguen con su
flujo
• Invocación asíncrona:
– Semántica de buzón
– No se espera a que se reciba el mensaje

Computación. 153
Especificación

– De activo a pasivo: hay que tener en cuenta
que varios procesos prueden acceder al
mismo tiempo un mismo objeto
• Exclusión mutua
• Sincronización
– De pasivo a activo:
• Es consecuencia de una llamada previa de otro
objeto activo al pasivo
• Tiene la misma semántica
– Se pueden incluir otras características a los
mensajes
• Balking: mensaje síncrono que no espera si el
receptor no está listo
• Timeout: igual pero espera un tiempo máximo
• Periódicos o aperiódicos
Computación. 154
Especificación
2: asincrona
A : proceso B : proceso
active active
5: timeout
4: normal
G:
proceso
1: sincrona active
3: balking
F : otro
sequential
D:
proceso 6: periódico
active
C:
H:
proceso
proceso
active

Computación. 155
Especificación
 Los tipos de mensajes

se especifican en los
diagramas de
interacción
 En cada mensaje se
especifican los
detalles
 También se puede
indicar el tipo de
objeto (show
concurrency), que
coincidirá con el
especificado en la
clase
Computación. 156
Especificación
Sincronización
 Aparte de en los mensajes, que ayudan a
especificar la sincronización inherente a la
aplicación, es necesario resolver el
problema de los accesos múltiples
 Aparece cuando existe más de un flujo de
control en un objeto:
– Máquinas de estados concurrentes
– Invocaciones de un objeto pasivo por varios
activos
 Laclave en este caso es tratar un objeto
como una sección crítica
Computación. 157
Especificación
Sincronización
– Existen tres enfoques:
• Secuencial: Los emisores
deben de coordinarse
fuera del objeto
• Con guardas: La
integridad del objeto se
garantiza tratando
secuencialmente las
llamadas a las
operaciones con guardas
• Concurrente: La
integridad se garantiza
porque la operación se
ejecuta siempre de forma
atómica

Computación. 158
Especificación
Vistas de procesos
 Además de las vistas de casos de uso y lógicas,
es conveniente tener también una vista de
procesos del sistema
 Esta vista se ocupa principalmente de la

capacidad de adaptación, funcionamiento y
rendimiento del sistema
 Se utilizan los mismos diagramas, pero

centrados en las clases activas que representan
a las hebras y procesos

Computación. 159
Especificación
Flujos de Control Múltiple

 Uno de los diagramas más utilizados en las vistas de procesos
son los diagramas de interacción con flujos múltiples
valvula :
proceso
visualizar :
leer_temperatura : proceso
proceso
p2: abrir valvula active
active
v1:
c1: actualizar
t1: temp datos compartidos :
controlador :
otro
proceso
guarded
p1: presion
e1:
leer_presion :
estadistica :
proceso
proceso
active
active
t2: calentar
calentador :
proceso

Computación. 160
Especificación
Contenido
– Introducción
– Modelado Arquitectónico
• Componentes y diagramas de componentes
• Diagramas de despliegue
• Patrones y marcos de trabajo

Computación. 161
Especificación
Componentes
 Se utilizan para modelar los elementos
físicos que pueden hallarse en un nodo
• Ejecutables
• Bibliotecas
• Tablas
• Archivos
• Documentos
 Deben definir abstracciones precisas con
interfaces bien definidos y que permitan la
reemplazabilidad

Computación. 162
Especificación
Componentes
 Un componente es una parte física y
reemplazable de un sistema que
implementa un conjunto de interfaces
 Gráficamente se representa por
Componente

Computación. 163
Especificación
Componentes
 Enmuchos sentidos los componentes son
como las clases:
– Ambos tienen nombre
– Ambos pueden realizar un conjunto de
interfaces
– Ambos pueden participar en relaciones de
dependencia, generalización y asociación
– Ambos pueden anidarse
– Ambos pueden participar en interacciones
 Sin embargo, hay diferencias
significativas
Computación. 164
Especificación
Componentes
 Diferencias entre componentes y clases:
– Las clases representan abstracciones lógicas
y los componentes elementos físicos
(secuencias de bits)
– Los componentes residen directamente en un
nodo
– Los componentes representan el
empaquetamiento físico de elementos lógicos
(de un distinto nivel de abstracción)
– Las clases tienen atributos y operaciones
directamente accesibles, los componentes
sólo tienen operaciones alcanzables a través
de sus interfaces

Computación. 165
Especificación
Componentes
 La relación entre un componente y las clases que
representa puede especificarse explícitamente
Interfaz CORBA
Cliente
Simulación
(.exe)
Ejecutivo Laminas
Dataview

Computación. 166
Especificación
Componentes e Interfaces
 Un interfaz es una colección de operaciones que
se utiliza para especificar un servicio de una
clase o componente
 Este concepto a dado lugar a los sistemas
basados en componentes (COM, CORBA, Java
Beans)
 Representación standard:
realización
visualizador
Interfaz
dependencia
Computación. 167
Especificación
Componentes e Interfaces
 La existencia de los interfaces rompe la
dependencia entre los componentes
– Un componente que utiliza una interfaz determinada
funcionará adecuadamente independientemente del
componente que realice la interfaz
– El componente que realiza la interfaz es siempre
sustituible por un componente o conjunto de
componentes que implementen dicha interfaz
– Un componente puede utilizarse en un contexto
determinado si y sólo si todas sus interfaces de
importación son suministradas por otros componentes

Computación. 168
Especificación
Tipos de Componentes
 Componentes de despliegue
– Los necesarios y suficientes para formar un
sistema ejecutable
• Bibliotecas dinámicas (DLLs) y ejecutables
 Componentes producto del trabajo
– Productos finales del proceso de desarrollo
• Archivos de código fuente y archivos de datos a
partir de los cuales se crean los componentes de
despliegue
 Componentes de ejecución
– Se crean como consecuencia de un sistema en
ejecución
• Un proceso que se crea a partir de un ejecutable

Computación. 169
Especificación
Tipos de Componentes
 Todos los mecanismos de extensibilidad se
pueden aplicar a los componentes (incluidos los
estereotipos)
 UML define cinco estereotipos estándar

– executable: componente que se puede ejecutar en un
nodo
– library: biblioteca de objetos dinámica o estática
– table: componente que representa una tabla de una
base de datos
– file: documento con código fuente o datos
– document: componente que representa un documento

Computación. 170
Especificación
Componentes en Rational Rose

 Rational Rose no utiliza los anteriores
componentes estándar, sino el siguiente
conjunto propio de estereotipos
Espec. Paquete Espec. Subprog. Prog. Principal
Cuerpo Paquete Cuerpo Subprog. Espec. Proceso Cuerpo Proceso

Computación. 171
Especificación
Especificación de Componentes

Computación. 172
Especificación
Modelado de código fuente
signal.h {ver=3.5} signal.h {ver=4.0} signal.h {ver=4.1}
parent
interp.cpp signal.cpp
irq.h device.cpp

Computación. 173
Especificación
Contenido
– Introducción

Computación. 174
Especificación
Despliegue
 Los nodos al igual que los componentes son un
elemento fundamental en el modelado físico de
un sistema
 Un nodo es un elemento físico que existe en
tiempo de ejecución y representa un recurso
computacional
– Un nodo representa un procesador o un dispositivo
sobre el que se pueden desplegar los componentes
 UML proporciona una representación gráfica de
un nodo genérico que se puede particularizar
para representar procesadores y dispositivos
específicos

Computación. 175
Especificación
Diagramas de Despliegue
 Un diagrama de despliegue muestra:
– los distintos dispositivos y su interconexión
– la asignación de componentes (procesos, ficheros,...) a
dispositivos
 Debe existir un solo diagrama de despliegue por
modelo
Procesador 1 Procesador 2
Dispositivo

Computación. 176
Especificación
Diagramas de Despliegue
 Son especialmente utiles para:
– Describir sistemas empotrados, en los que hay gran
cantidad de software interactuado con el hardware
– Modelar sistemas distribuidos, en los que la asignación de
componentes a procesadores puede ser importante
terminal
preemptive
user.exe
10-T Ethernet
Servidor Unidad
RAID
preemptive
dbadmin
tktmstr
RS-232
Consola

Computación. 177
Especificación
Especificación de Procesadores

Computación. 178
Especificación
Especificación de Procesos

Computación. 179
Especificación
Dispositivos y Conexiones

Computación. 180
Especificación
Contenido
– Introducción

Computación. 181
Especificación
Patrones y Marcos de Trabajo

 Todos los sistemas bien estructurados están
llenos de patrones.
– Un patrón proporciona una solución común a un
problema en un contexto dado
 Un mecanismo es un patrón de diseño que se

aplica a una sociedad de clases
 Un marco de trabajo (framework) es un patrón

arquitectónico que proporciona una plantilla
extensible para aplicaciones dentro de un
dominio

Computación. 182
Especificación
Patrones y Marcos de Trabajo

 Tanto en un sistema nuevo, como en una
modificación de un sistema existente no se debe
empezar desde cero
 Hay que intentar aplicar formas comunes de
resolver problemas
– En sistemas que interactúan con el usuario, una forma
probada de organizar las abstracciones es utilizar el
patrón modelo-vista-control
– En sistemas de solución de problemas de forma
colaborativa se suele utilizar una arquitectura de pizarra
– En sistemas dirigidos por eventos se utiliza el patrón
cadena de responsabilidad para organizar los
manejadores de eventos

Computación. 183
Especificación
Colaboraciones
 Son el elemento básico para describir patrones
de diseño.
 Una colaboración permite nombrar a un bloque

conceptual que incluye tanto aspectos estáticos
como dinámicos
 Denota una sociedad de clases, interfaces y otros

elementos que colaboran para proporcionar
algún comportamiento cooperativo mayor que la
suma de los comportamientos de sus elementos

Computación. 184
Especificación
Colaboraciones
 Una colaboración tiene dos aspectos:
– Estructural: especifica las clases, interfaces o
componentes
• Se organizan utilizando las relaciones normales de UML
(asociaciones, generalizaciones y dependencias)
• Al contrario que los paquetes o subsistemas, no contienen
a sus elementos.
• Puede hacer referencia o utilizar elementos declarados en
distintos sitios
• Se trata de un bloque conceptual de la arquitectura del
sistema
– Comportamiento: dinámica de cómo interactúan estos
elementos
• Se representa mediante diagramas de interacción
• Debe ser consistente con la visión estructural

Computación. 185
Especificación
Colaboraciones
Agente de Transporte
emisor
recibido
IDistribuido
enviarMensaje()
1
1
+Buzón 1..* 1..*
Cola Mensaje
ID
añadirMensaje() cabecera
quitarMensaje() cuerpo
contar()
colaDeEntrada colaDeSalida

Computación. 186
Especificación
Colaboraciones
: Mensaje : colaDeSalida : Agente de

: Actor
Transporte
1: crear
los agentes de transporte

periódicamente quitan
2: añadirMensaje
mensjaes de las colas
asignadas, según sus
3: quitarMensaje politicas de planificación

Computación. 187
Especificación
Colaboraciones
 Ambos diagramas deben ser consistentes

– Los objetos deben ser instancias de clases
– Los mensajes deben ser operaciones visibles
 Puede haber más de un diagrama de interacción por

colaboración, mostrando distintos aspectos de una
colaboración
 Representación
Paso de Mensajes

Computación. 188
Especificación
Colaboraciones
 Además de para mostrar patrones de diseño, las

colaboraciones pueden utilizarse para mostrar la
realización de los casos de uso
 La implementación de un caso de uso vendrá

dada por una o más colaboraciones de los
objetos de implementación del sistema
 Se pueden representar en diagramas de casos de

uso, utilizando relaciones de realización y
refinamiento
Computación. 189
Especificación
Colaboraciones

Computación. 190
Especificación
Mecanismos
 Un mecanismo o patrón de diseño se modela
como una colaboración parametrizada
 Se representan en UML de forma parecida a
como se representan las clases plantilla
Cola Tareas
Sujeto
Sujeto
Observador
BarraDesplazamiento Observador
Observador

Computación. 191
Especificación
Marcos de Trabajo
 Es un patrón arquitectónico que proporciona una
plantilla extensible para aplicaciones dentro de
un dominio
 Por ejemplo, para desarrollar un sistema en

tiempo real podemos utilizar:
– Un ejecutivo cíclico
– Una arquitectura orientada a eventos
– Un conjunto de tareas con un planificador concreto
 Las tres alternativas pueden estar definidas

como marcos de trabajo y “sólo” habrá que
instanciarlas

Computación. 192
Especificación
Marcos de Trabajo
 Un marco de trabajo es algo más grande que un
mecanismo
 Se puede concebir como una microarquitectura
que incluye un conjunto de mecanismos que
colaboran para resolver un problema en un
dominio común
 Un marco de trabajo se especifica como un
paquete estereotipado.
– Dentro del paquete se pueden ver mecanismos
existentes en cualquiera de las vistas del sistema
– No sólo hay mecanismo, también pueden incluirse
casos de uso, colaboraciones simples,....

Computación. 193
Especificación
Marcos de Trabajo
<<framework>>
Ejecutivo Cíclico
Cliente
Gestor
Gestor de Eventos
Eventos Comunes

Computación. 194
Especificación
Marcos de Trabajo
 Los Marcos de Trabajo son diferentes de las

bibliotecas de clases
– Una biblioteca de clases contiene abstracciones que las

abstracciones del desarrollador pueden instanciar o
invocar
– Un marco de trabajo contiene abstracciones que
pueden instanciar o invocar a las abstracciones del
desarrollador

Computación. 195

Tema 2

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Tema 2

Uploaded by

Copyright:

Available Formats

Tema 3.

Departamento de Lenguajes y Ciencias de la Computación

Departamento de Lenguajes y Ciencias de la

 UML es un lenguaje de modelado de software:

Departamento de Lenguajes y Ciencias de la

 UML es un lenguaje para especificar software:

Departamento de Lenguajes y Ciencias de la

 El modelo conceptual está compuesto por 3

Departamento de Lenguajes y Ciencias de la

Anotación Nota Nota

Modelado Estructural: Modelo de

 Describe estructura de los objetos de

Departamento de Lenguajes y Ciencias de la

Departamento de Lenguajes y Ciencias de la

Cada atributo es único en la clase

Departamento de Lenguajes y Ciencias de la

Departamento de Lenguajes y Ciencias de la

Departamento de Lenguajes y Ciencias de la

 Enlace: conexión entre dos o más instancias

Departamento de Lenguajes y Ciencias de la

Punto intersecta +2 Línea

Departamento de Lenguajes y Ciencias de la

C:Lenguaje Eole400:Proyecto Ensamblador:Lenguaje

Luis:Persona José María:Persona

Departamento de Lenguajes y Ciencias de la

Asociaciones con Atributos

 Las asociaciones pueden tener atributos

Departamento de Lenguajes y Ciencias de la

Departamento de Lenguajes y Ciencias de la

Departamento de Lenguajes y Ciencias de la

 Un rol es un extremo de una asociación

Departamento de Lenguajes y Ciencias de la

Departamento de Lenguajes y Ciencias de la

Departamento de Lenguajes y Ciencias de la

Departamento de Lenguajes y Ciencias de la

Departamento de Lenguajes y Ciencias de la

 Con las propiedades vistas hasta ahora se

Departamento de Lenguajes y Ciencias de la

operaciones asociación operaciones

Departamento de Lenguajes y Ciencias de la

Departamento de Lenguajes y Ciencias de la

leerNivel() puertosTeclado ...

Departamento de Lenguajes y Ciencias de la

Departamento de Lenguajes y Ciencias de la

operaciones asociación operaciones

Departamento de Lenguajes y Ciencias de la

Departamento de Lenguajes y Ciencias de la

ident: LEDID GestorLEDs

Departamento de Lenguajes y Ciencias de la

A veces es necesario especificar

Departamento de Lenguajes y Ciencias de la

Empleado directivo Ventana

Departamento de Lenguajes y Ciencias de la

 La agregación es un tipo especial de

Departamento de Lenguajes y Ciencias de la

operaciones asociación operaciones

Departamento de Lenguajes y Ciencias de la

Polígono dibujar Punto

dibujar() vértices dibujar()

Departamento de Lenguajes y Ciencias de la

Departamento de Lenguajes y Ciencias de la

 Tulipa Bombilla Pie

Departamento de Lenguajes y Ciencias de la