1. Gloria Margot Gonzales Fernandez
Ingeniero en Informática
Instituto Superior Jesús María Fé y Alegría
Materia: Análisis y Diseño de Sistemas II
Curso: 3ero de Análisis de Sistemas

2.  Introducción
 Modelado estructural
 Modelado del comportamiento
 Modelado arquitectónico
2

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

4.  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, ...
4

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

6.  El UML modela sistema mediante el uso de objetos
que forman parte de él así como, las relaciones
estáticas o dinámicas que existen entre ellos.
 UML puede ser utilizado por cualquier metodología
de análisis y diseño orientada por objetos para
expresar los diseños.

7. 1. Diagrama de Casos de Uso
2. Diagrama de Clases
3. Diagrama de Actividades
4. Diagrama de Iteración
4.1. Diagrama de Secuencia
4.2. Diagrama de Colaboración

8. 5. Diagrama de Estados
6. Diagrama de Implementación
6.1. Diagrama de Componentes
6.2 Diagrama de Despliegue

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

10. Relaciones Dependencia
0..1 *
Asociación
role1 role2
Generalización
Realización
Diagrama de clases
Diagrama de objetos
Diagramas
Diagrama de casos de uso
Diagrama de secuencia
Diagrama de colaboración
Diagrama de estados
Diagrama de actividades
Diagrama de componentes
Diagrama de despliegue
10

11. Nombres Cliente
nombre
Reglas
Ámbito dirección
Elena:Cliente
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()
vaciar() {ordenado}
11

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

13. :Cliente
José:Cliente
José Pérez
Claudia
13

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

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

16. EEPROM
EEPStart
EEPStop
enviarDir(dir:Tparam) :EEPROM
EnviarByte(dato:Tvalor)
Control(accion:integer)
EEPAck
EEPNoAck
16

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

18.  Especificación que denota si una carácterística
de una clase puede ser utilizada por otros
clasificadores
 Public (+) .- Cualquier clasificador externo
 Protected (#) .- Cualquier descendiente
 Private (-) .- Solo el propio clasificador

19.  Representan el nivel más abstracto al que
se modelan las características estructurales
de las clases.
 De forma general la sintaxis de un atributo
contiene:
 [visibilidad] nombre [multiplicidad] [: tipo] [=valor
inicial] [{propiedades}]

20.  Cuáles de las siguientes declaraciones son válidas?
 Origen OK
 + origen
 & origen OK
 *Cabeza: Item NO
 Nombre [0..+] : String
NO
 Id: Integer {frozen}
 Id: Integer = {0,0} NO
OK
OK

21.  Representan el nivel más abstracto al que se
modelan las carácterísticas comportamentales de
una clase
 De forma general la sintaxis de un atributo contiene:
 [visibilidad] nombre [(lista de parámetros)] [: tipo de retorno]
[{propiedades}]

22.  Cuáles de las siguientes declaraciones son válidas?
 mostrar OK
 + mostrar OK
 set(n: nombre, s: string) (0,0) NO
 obtenerID() :Integer OK
 reiniciar() :{concurrent} NO

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

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

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

26. GestorLEDs
inicializar()
llamadaEntrante()
leds tomaDeLínea()
colgar()
pilaBaja()
modoContestador()
6 ...
LED
ident: LEDID
parpadea(te:Duration, ta:Duration)
26

27. Proyecto Lenguaje
Persona
C:Lenguaje Eole400:Proyecto Ensamblador:Lenguaje
Luis:Persona José María:Persona
CentralNuclear:Proyecto Fortran:Lenguaje
27

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

29. Clase Clase
atributos atributos
operaciones operaciones
atributo
29

30. acceso
Fichero Usuario
permiso de acceso
trabajo
Empresa Persona
sueldo
puesto
30

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

32. Clase Clase
atributos rol rol atributos
operaciones asociación operaciones
32

33. propietario padre
Usuario Directorio
usuario_autorizado
subdirectorios
33

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

35. LED
ident: LEDID
parpadea(te:Duration, ta:Duration)
led_que_enciende
Temporización
tEncendido:Duration
tApagado: Duration
tSilencio: Duration
35

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

37. Clase Clase
atributos {ordered} atributos
operaciones asociación operaciones
37

38. {ordered}
Ventana Pantalla
visibilidad
{sorted}
Alumnos Curso
calificación
38

39. Puerto Teclado
{ordered} ultimaTecla
leerNivel() puertosTeclado ...
39

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

41. Clase Clase
atributos atributos
operaciones asociación operaciones
disminuye multiplicidad
Clase Clase
atributos atributos
calificador
operaciones asociación operaciones
41

42. contenido
Directorio File
contenido
Directorio nombre File
empleados
Empresa Persona
empleados
Empresa departamento Persona
42

43. LED
ident: LEDID GestorLEDs
parpadea(te:Duration, ta:Duration)
led inicializar()
3 llamadaEntrante()
ledsPuerto tomaDeLínea()
colagar()
pilaBaja()
modoContestador()
...
tipoEvento
Temporización
tEncendido:Duration parpadeoLed
tApagado: Duration
tSilencio: Duration
43

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

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

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

47. Clase Clase
atributos atributos
operaciones asociación operaciones
47

48. Polígono dibujar Punto
dibujar() vértices dibujar()
48

49. Puerto Teclado
3 {ordered}
ultimaTecla
puertosTeclado
leerNivel() ...
Display LED
6
InterfazExterno
49

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

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

52. Herencia con
SuperClase solapamiento
atributos
Herencia con
operaciones discriminador discriminador
SubClase SubClase SubClase
atributos atributos atributos
...
operaciones operaciones operaciones
52

53. 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
perímetro(): float
53

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

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

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

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

58.  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 que Contabilidad
se modela. No confundir con superclase.
 Se expresa mediante un nombre entre
comillas tipográficas. <<excepción>>
VentaRechazada
razón
58

59.  Son elementos de
modelado que pueden
tener instancias
 Interfaz, Tipo de
datos, Señal, Componen Tarjeta
te, 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
59

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

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

62.  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()
62

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

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

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

66. Diagramas en UML y su uso
Captura de Requisitos Análisis y Diseño Implementación
Diagramas de
Estados
Diagramas de
Secuencia Diagramas de
Distribución
Diagramas de Diagramas
Casos de Uso De Clases
Diagramas de Diagramas de
Colaboración Componentes
Diagramas de Diagramas de
Actividad Actividad

67.  Introducción
 Modelado estructural
 Modelado del comportamiento
 Modelado Básico
 Interacciones
 Diagramas de interacción
 Casos de uso y diagramas
 Diagramas de actividades
 Modelado Avanzado
 Modelado arquitectónico
67

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

69. Persona Empresa
1..* *
Asignar(d:Departamento) empleado contratante
Asociación
Asignar(desarrollo)
P:Persona :Empresa
Enlace
69

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

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

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

73.  Hacen énfasis en la ordenación temporal de los
mensajes.
 Se coloca a la izquierda el objeto que inicia la
interacción y a la derecha los objetos
subordinados.
 Muestran la “línea de vida” de la secuencia
completa
 Muestran el “foco de control” como un
rectángulo delgado que representa el tiempo
que se ejecuta una acción.

75. Lector Pantal Cuenta Ranura
Tarjet la Joe de
Joe: cliente
as Captur dinero
1: Acepta tarjeta a
2: Lee Num. Tarjetas
3: Inicializa pantalla
4: Abre cuenta
5: Solicita PIN
6: Da PIN
7: Verfica PIN
8: Solicita Transacción
9: Selecciona Transacción
10: Solicita Cantidad
11: Captura Cantidad
12: Retira Dinero
13: Verifica Fondos
14: Descuenta Cantidad
15: Da dinero
16: Da recibo
17: Expulsa Tarjeta

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

77.  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
4: logout
 En Rational Rose, la
5: fin 6: destroy
creación de objetos
no se puede reflejar
de la forma estándar
77

78. 78

79.  Muestran la organización de los objetos de una
interacción de modo estructural.
 Se dibujan los objetos a manera de nodos en
un grafo.
 Se representan los enlaces y los adornos.
 Muestran el camino entre los enlaces
 Incluyen un número para especificar el orden
en la secuencia de interacción.
 Son semanticamente equivalentes a los
diagramas de secuencia.

81. 6: Da PIN
Joe: cliente Selecciona Transacción
9: Pantal
11: Captura Cantidad la
Captur
5: Solicita PIN
8: Solicita Transacción a
10: Solicita Cantidad 7: Verfica PIN
12: Retira Dinero
3: Inicializa pantalla
1: Acepta tarjeta 13: Verifica Fond
2: Lee Num. 14: Descuenta
Cantidad
Tarjetas
Lector
Tarjet Cuenta
4: Abre cuenta
as Joe
17: Expulsa Tarjeta
Ranura
de 15: Da dinero
16: Da recibo
dinero

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

83.  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,.....)
83

84. 84

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

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

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

88.  Caso de Uso:
 Descripción de un conjunto de secuencias de
acciones, incluyendo variantes, que ejecuta un
sistema para producir un resultado observable de
valor para un actor
 Actor:
 Se refiere a los distintos roles que los usuarios
juegan al interactuar con los casos de uso.

89.  Contienen:
 Casos de Uso,
 Actores y
 Relaciones de dependencia, generalización y
asociación
 Usos comunes:
 Para modelar el contexto del sistema
 Para modelar los requisitos del sistema

93. 1. Identificar QUIÉN(es) va(n) a utilizar el sistema
directamente --- Ese (esos) será(n) nuestro(s) actor(es).
2. Tomar uno de esos actores
3. Definir lo que el actor quiere hacer con el sistema
4. Para cada uno de estos escenarios (caso de uso) decida
cuál sería la forma natural de interacción
5. Hacer una descripción de alto nivel de la interacción
actor – sistema (cuando el actor hace “x”, el sistema
hace “y”)
6. Considere ahora los casos extendidos de uso (aquellos
menos naturales pero posibles)
7. Repita los pasos 2 al 7 para cada actor

94.  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
April 12 94

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

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

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

98.  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.
April 12 98

99. April 12 99

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

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

102. logout
<<include>> modificar parámetros
<<include>>
acciones instructor
sesion instructor <<include>> cambiar estado
login controlCI
Instructor
control backtrack
sesión alumno
102

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

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

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

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

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

108.  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: ...
108

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

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

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

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

113. Escenario de Éxito Principal:
Los pasos del 5 al 8 son opcionales,
individualmente repetibles y pueden ocurrir en
cualquier orden
5. El cliente ingresa dinero – sub-caso de uso
6. El cliente obtienen un balance – sub-caso de uso
7. El cliente saca dinero – sub-caso de uso
8. El cliente transfiere dinero – sub-caso de uso
9. 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 envia un balance con los últimos
movimientos 113

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

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

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

117.  Introducción
 Modelado estructural
 Modelado del comportamiento
 Modelado Básico
 Interacciones
 Diagramas de interacción
 Casos de uso y diagramas
 Diagramas de actividades
 Modelado Avanzado
 Modelado arquitectónico
117

118.  Se pueden 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.
April 12 118

119. Diagramas de Actividades
Solicitar
Producto
Procesar Extraer
Pedido Artículos
Enviar Pedido
Recibir Facturar al
Pedido Cliente
Pagar
Factura
Cerrar Pedido
119

120. Estado Inicial Estado Final
Actividad
Acción Actividad
Estado
Transición
Estado sin Disparador
Actividad
Condición
División Unión
120

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

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

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

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

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

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

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

128.  Introducción
 Modelado estructural
 Modelado del comportamiento
 Modelado Básico
 Modelado Avanzado
 Eventos y Señales
 Máquinas de Estados
 Procesos y Hebras
 Modelado arquitectónico
128

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

130.  Declaración de un evento
<<Signal>>
Colgar Inactivo
<<signal>>
Colgar / cortarConexion()
Activo
130

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

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

133. 133

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

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

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

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

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

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

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

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

142. Señal de robot
Abstractas
fallo hardware
colision
sensor : integer
fallo batería fallo mecanico Fallo de visión fallo de rango
Atasco Motor
142

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

144. Excepción
establecerManejador()
primerManejador()
ultimoManejador()
Duplicado
Overflow
Conjunto
<<send>> <<send>> Underflow
añadir()
eliminar()
<<send>>
144

145.  Introducción
 Modelado estructural
 Modelado del comportamiento
 Modelado Básico
 Modelado Avanzado
 Eventos y Señales
 Máquinas de Estados
 Procesos y Hebras
 Diagramas de estados
 Modelado arquitectónico
145

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

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

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

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

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

151. 151

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

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

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

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

156. 156

157.  Representan autómatas de estados finitos
 Especifica la secuencia de estados por los que
pasa un objeto a lo largo de su vida en
respuesta a eventos.
 Un estado es una condición en la vida de un
objeto durante la cual satisface alguna
condición, realiza alguna actividad o espera
algún evento.
 Un evento es un acontecimiento significativo
que ocupa un espacio y un tiempo y que
produce un estímulo que puede disparar una
transición.
 Una transición es una relación entre dos
estados especificada por la aparición de un
evento.

158.  Generalización
 Sirve para reducir la complejidad de un diagrama de
estados
 Se definen así subestados y superestados
 Los subestados heredan las variables de estado y
las transiciones internas

159. III. El Paradigma OO: Diagrama de Estados III. El Paradigma OO: Diagrama de Estados
Generalización de Estados Generalización de Estados
 Ejemplo:  Quedaría como:
e1
A e1
B Aa b
B
e2
e2
e2
C
C
155 156
 www.dsic.upv.es/~uml  www.dsic.upv.es/~uml
III. El Paradigma OO: Diagrama de Estados
III. El Paradigma OO: Diagrama de Estados
… Generalización de Estados … Generalización de Estados
 Las transiciones de entrada deben ir hacia  Es preferible tener estados iniciales de
subestados específicos: entrada a un nivel de manera que desde los
niveles superiores no se sepa a qué
e1 subestado se entra:
a
A b
B
e1
e2
Aa b
B
e0 e2 C
e0
C
157 158
 www.dsic.upv.es/~uml  www.dsic.upv.es/~uml

160. Retiro [balance <0]
Sobregiro
Abrir Noficar a cliente
Depósito [balance <0]
Cliente
Solicita
Cancelación
Verifica Balance
[Balance <0 for >30 días]
Cerrar

161.  Estados  Transiciones
 Nombre  Estado origen
 Acciones de I / O  Evento de
 Transiciones disparo
internas  Condición de
 Subestados guarda
 Eventos diferidos  Acción
 Estado destino
Estado Inicial Estado Final

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

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

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

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

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

167.  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*
167

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

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

170.  Introducción
 Modelado estructural
 Modelado del comportamiento
 Modelado Básico
 Modelado Avanzado
 Eventos y Señales
 Máquinas de Estados
 Procesos y Hebras
 Modelado arquitectónico
170

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

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

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

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

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

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

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

178.  En Rational Rose los objetos activos se pueden especificar en la
definición de la clase, pero no como estereotipo:
178

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

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