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
Introducción
Modelado estructural
Modelado del comportamiento
Modelado arquitectónico
2
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
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
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
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.
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
5. Diagrama de Estados
6. Diagrama de Implementación
6.1. Diagrama de Componentes
6.2 Diagrama de Despliegue
9
Ele
men
tos
Estructurales
Comportamiento
Agrupación
Anotación
Clase
Interfaz
Colaboración
Caso de uso
Clases activs
Componente
Nodo
Interacción
Máquina de estados
Paquetes
Frameworks
Modelos
Subsistemas
Nota
Clase
atributos
métodos
IInterfaz
Colaboración
Caso de UsoClase Act
atributos
métodosComponente
Nodo
Interacción
Estado
Paquete
Nota
10
Rel
acio
nes Dependencia
Asociación
Generalización
Realización
Dia
gra
mas
Diagrama de clases
Diagrama de objetos
Diagrama de casos de uso
Diagrama de secuencia
Diagrama de colaboración
Diagrama de estados
Diagrama de actividades
Diagrama de componentes
Diagrama de despliegue
0..1 *
role1 role2
11
Reg
las
Mec
anis
mo
sNombres
Ámbito
Visibilidad
Integridad
Ejecución
Especificaciones
Adornos
Divisiones comunes
Extensiones
Entidad
Instancia
Estereotipo
Valor etiquetado
Restricción
Cliente
nombre
dirección
preferencial()
IUnknown
IOrtografía
Elena:Cliente
ColaEventos{vers = 3.2autor=eps}
añadir()
quitar()
vaciar()
«exception»
Overflow
{ordenado}
asistOrtog.dll
:Cliente
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
José:Cliente
José Pérez
:Cliente
Claudia
14
Clase
atributos
operaciones
Cada atributo es único en la clase
Sólo datos “simples” y NO otros objetos
Opcionalmente, tipo y valor por defecto
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)
15
Punto
x: float
y: float
trasladar(dx:float, dy:float)
distancia(pto: Punto) : float
:Punto
x=0
y=0
:Punto
x=3.5
y=2.25
:Punto
x=1
y=2
16
EEPROM
EEPStart
EEPStop
enviarDir(dir:Tparam)
EnviarByte(dato:Tvalor)
Control(accion:integer)
EEPAck
EEPNoAck
:EEPROM
17
Protocolo
EntradaCombo(m: TMensajeMovil)
LIGBM()
LL_ENT()
SILEN()
FIN_LIG()
INTBM()
FIN_LLENT()
CODSEG()
FININTB()
mensaje: TMensajeMovil
movil_origen: TIdMovil
Combo
MandarRegRx(c: Tcanal)
MandarRegTx(c: Tcanal)
MandarReg0(c: Tcanal)
MandarRegMode(c: Tcanal)
MandarRegGain(c: Tcanal)
MandarRegRefP(c: Tcanal)
LeerPortadora()
LeerCabecera()
EscribirCabecera()
EscribirDato(m: TMensajeBase)
LeerDato(m: TMensajeMovil)
SubirSquelch()
BajarSquelch()
RestituirSquelch()
estado: TEstadoCombo
movil_origen: TIdMovil
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
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}]
Cuáles de las siguientes declaraciones son válidas? Origen
+ origen
& origen
*Cabeza: Item
Nombre [0..+] : String
Id: Integer {frozen}
Id: Integer = {0,0}
OK
OK
NO
NO
NO
OK
OK
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}]
Cuáles de las siguientes declaraciones son válidas?
mostrar
+ mostrar
set(n: nombre, s: string) (0,0)
obtenerID() :Integer
reiniciar() :{concurrent}
OK
OK
NO
OK
NO
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
0 o 1
Muchos
n Exactamente n
m,n m o n
m-n Entre m y n
n+ Más de n
Exactamente 1
Direccionalidad
Multiplicidad
Clase
atributos
operaciones
Clase
atributos
operaciones
asociación
25
Punto
x: float
y: float
trasladar(dx:float, dy:float)
distancia(pto: Punto) : float
Línea
trasladar(dx:float, dy:float)
distancia(pto: Punto) : float
rotar(ang: float)
intersecta +2
punto_referencia
ángulo: float
P1:Punto
P2:Punto
P3:Punto
L4:Línea
L3:Línea
L2:Línea
L1:Línea P2P1
L1
P3
L2
L3L4
26
GestorLEDs
inicializar()
llamadaEntrante()
tomaDeLínea()
colgar()
pilaBaja()
modoContestador()
...
leds
6
LED
ident: LEDID
parpadea(te:Duration, ta:Duration)
27
Proyecto Lenguaje
Persona
C:Lenguaje
CentralNuclear:Proyecto
Luis:Persona
Ensamblador:LenguajeEole400:Proyecto
Fortran:Lenguaje
José María:Persona
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
atributos
operaciones
Clase
atributos
operaciones
atributo
30
Fichero Usuario
permiso de acceso
acceso
Empresa Persona
sueldo
puesto
trabajo
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
atributos
operaciones
Clase
atributos
operaciones
rol rol
asociación
33
propietario
usuario_autorizadosubdirectorios
Usuario Directoriopadre
34
recepción
emisión
Protocolo
EntradaCombo(m: TMensajeMovil)
LIGBM()
LL_ENT()
SILEN()
FIN_LIG()
INTBM()
FIN_LLENT()
CODSEG()
FININTB()
mensaje: TMensajeMovil
movil_origen: TIdMovil
Combo
...
estado: TEstadoCombo
movil_origen: TIdMovil
CtrlCombo
ultimoCanal: Tcanal
estado: TEstadoCtrlCombo
inicioComunicación
finComunicación
enviarMensaje(m:TMensajeBase)
noPortadora
mensajes
35
Temporización
tEncendido:Duration
tApagado: Duration
tSilencio: Duration
LED
ident: LEDID
parpadea(te:Duration, ta:Duration)
led_que_enciende
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
atributos
operaciones
Clase
atributos
operaciones
{ordered}
asociación
38
Ventana{ordered}
visibilidadPantalla
Alumnos{sorted}
calificaciónCurso
39
Puerto
leerNivel()
Teclado
ultimaTecla
...
{ordered}
puertosTeclado
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
atributos
operaciones
Clase
atributos
operacionesasociación
Clase
atributos
operaciones
Clase
atributos
operacionesasociación
calificador
disminuye multiplicidad
42
Empresa Personaempleados
empleadosdepartamentoEmpresa Persona
Directorio Filecontenido
contenidonombreDirectorio File
43
GestorLEDs
inicializar()
llamadaEntrante()
tomaDeLínea()
colagar()
pilaBaja()
modoContestador()
...
ledsPuerto
3
LED
ident: LEDID
parpadea(te:Duration, ta:Duration)
Temporización
tEncendido:Duration
tApagado: Duration
tSilencio: Duration
led
tipoEvento
parpadeoLed
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
salario
directivo
subordinado
{salario < directivo.salario}
Ventana
anchura
altura
{anchura<altura}
presidente
Persona {subconjunto} Comisión
miembro
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
atributos
operaciones
Clase
atributos
operacionesasociación
48
vértices
Polígono
dibujar()
Punto
dibujar()
dibujar
49
Puerto
leerNivel()
{ordered}
puertosTeclado
3Teclado
...
ultimaTecla
InterfazExterno
Display LED
6
Fija (lámpara)
Variable (empresa-departamento)
Recursiva (sentencia-bloque)
No es implementable eficientemente.
En algunos casos puede llegar a no permitirse.
50
Bloque
Sentencia
S. Simple
*
Departamento
Empresa
*
Lámpara
PieBombillaTulipa
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
SuperClase
atributos
operaciones
SubClase
atributos
operaciones
SubClase
atributos
operaciones
SubClase
atributos
operaciones
...
discriminador
Herencia con
solapamiento
Herencia con
discriminador
53
Punto Figura
área(): float {abstract}
perímetro(): float {abstract}
Elipse
área(): float
perímetro(): float
Polígono
perímetro(): float
Triángulo
área(): float
Cuadrado
área(): float
Círculo
perímetro(): float
54
LEDPuerto
encender()
apagar()
LEDRegistro
GestorLEDs
inicializar()
llamadaEntrante()
tomaDeLínea()
colagar()
pilaBaja()
modoContestador()
...
LED
ident: LEDID
parpadea(te:Duration, ta:Duration)
ledsRgto33
ledsPto
6
leds
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
Computador Identificación
DNI PC Smart Card
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
Vehículo
Vehículo Terrestre Vehículo Acuático
Bote Coche Vehículo Anfibio
Dependencia=Relación de uso
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
destino*origen
Notas Expresa comentarios o aclaraciones
relativas a un elemento o grupo de ellos.
Responsabilidades Contrato u obligación de una clase
Se expresan mediante texto libre
Estereotipos Crea nuevos tipos de bloques de
construcción específicos al problema que
se modela. No confundir con superclase.
Se expresa mediante un nombre entre
comillas tipográficas.
58
ControlVentas
Responsabilidades
--determinar validez venta
--comunicar a Almacen y
Contabilidad
No controla saldo
del cliente
<<excepción>>
VentaRechazada
razón
Son elementos de modelado que pueden tener instancias Interfaz, Tipo de
datos, Señal, Componente, Nodo, Casos de uso, Subsistema.
Visibilidad
+ Public
# Protected
- Private
Alcanceinstancia
clasificador
59
Tarjeta
+ GetSaldo: long
+ Recarga(long cant)
+ Comprobar(long cant):boolean
- Saldo:long
- PIN:int
# Límite:long = 25.000
Formato atributos[visibilidad] nombre [multiplicidad] [:tipo]
[=valor inicial] [{propiedades}]
Propiedades predefinidas: changeable, addOnly, frozen
60
Tarjeta
+ GetSaldo: long
+ Recarga(long cant)
+ Comprobar(long cant):boolean
- Saldo:long
- PIN [1..*] : int {addOnly}
# Límite:long = 25.000
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
61
Tarjeta
+ GetSaldo: long {isQuery}
+ Recarga(long cant)
+ ComprobarPIN(int pinPrueba):boolean
- Saldo:long
- PIN [1..*] : int {addOnly}
# Límite:long = 25.000
Interfaz: colección de operaciones que se usa para
especificar un servicio de una clase o componente.
62
Tarjeta Multifunción
IIdentificación IPago
Si es necesario puede
representarse como una
clase estereotipada. No
tendrá atributos ni métodos;
sólo operaciones.
<<interface>>
IPago
GetSaldo()
Recarga()
Las operaciones pueden
incluir adornos como
estereotipos, valores
etiquetados, restricciones y
propiedades de visibilidad y
concurrencia.
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:framework, subsystem, system
stub, facade
63
+FormularioDePedido
+FormularioDeEstado
- Pedido
Cliente
Visibilidad.
64
+FormularioDePedido
+FormularioDeEstado
- Pedido
Cliente
<<import>>
Importación y Exportación.
+Ventana
+Formulario
#GestorEventos
GUI
exportación
Generalización.
WinGUI
LinuxGUI
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
Diagramas en UML y su uso
Diagramas deCasos de Uso
Diagramas deSecuencia
Diagramas deColaboración
DiagramasDe Clases
Diagramas deEstados
Diagramas deActividad
Diagramas deComponentes
Diagramas deDistribución
Diagramas deActividad
Captura de Requisitos Análisis y Diseño Implementación
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
DefiniciónUna 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
Asignar(d:Departamento)
Empresa
empleado contratante
1..* *
P:Persona :Empresa
Asignar(desarrollo)
Enlace
Asociación
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
70
[Pre] 1:*(expr):mensaje(p,q):Valor
Precondición
ParámetrosExpresión
IteraciónIdentificador
Nº secuencia
Valor de
Retorno
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
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
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.
1: Acepta tarjeta
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
Lector
Tarjet
as
Pantal
la
Captur
a
Cuenta
Joe
Ranura
de
dineroJoe: cliente
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
76
: InstructorConsola Instructor
BDinstructores
1: login(usuario)2: leer(usuario)
3: usuario correcto
4: iniciar sesion
5: usuario aceptado
Foco de
Control
Línea de
Vida
Los mensajes se
corresponden
generalmente a
métodos de los
objetos
Los objetos pueden
ser creados durante
la ejecución
En Rational Rose, la
creación de objetos
no se puede reflejar
de la forma estándar
77
: Alumno
Cliente
Aplicación
Interfaz
Cliente
Sesion
1: login
2: crear sesion
3: create
4: logout
5: fin 6: destroy
78
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.
6: Da PIN
9: Selecciona Transacción
11: Captura Cantidad
5: Solicita PIN
8: Solicita Transacción
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
4: Abre cuenta
17: Expulsa Tarjeta
15: Da dinero
16: Da recibo
Pantal
la
Captur
a
Joe: cliente
Cuenta
Joe
Lector
Tarjet
as
Ranura
de
dinero
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
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
Utilizando el submenu Browse se puede generar un diagrama a
partir del otro
85
: Instructor
Consola
Instructor
BD
instructores
1: login(usuario)
2: leer(usuario)
3: usuario correcto
4: iniciar sesion
5: usuario aceptado
: InstructorConsola
Instructor
BD
instructores
1: login(usuario)
2: leer(usuario)
3: usuario correcto
4: iniciar sesion
5: usuario aceptado
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
: InstructorConsola
Instructor
BD
instructores
1: login(usuario)
2: leer(usuario)
3: usuario correcto
4: iniciar sesion
5: usuario aceptado
inicio
fin
{inicio-fin<10s}
{Iniciar sesion.executionTime<5s}
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.
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
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
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
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
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
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
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
April 12 99
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
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 repetidos101
102
sesión alumno
controlCI
cambiar estado
modificar parámetros
Instructor
login
logout
acciones instructor
sesion instructor <<include>>
<<include>>
<<include>>
control backtrack
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
Alumno
identificación
sesion alumno
<<include>>
Acción errónea
Acciones de Alumno
<<include>><<extend>>
Todos los valores
Petición de valores
Valores cambiados Selección
Activar vble dinámica
105
Nacional
Internacional
LlamadoRecibir Llamada
Llamada no atendida
<<extends>>
Llamante
Numero no existe
Comunicando
No hay linea
Realizar Llamada<<extends>>
<<extends>>
<<extends>>
Marcar Número<<includes>>
Numero Incorrecto
<<extends>>
106
Cliente
Correo
Transferir DineroObtener un Balance
Sacar Dinero
Ciclo de Vida Cuenta
Ingresar Dinero
Cajero
Identificar Cliente
<<includes>>
Cajero Automático
Identificar Cliente y Cuenta en Cajero Automático
<<includes>> <<includes>>
<<includes>>
<<includes>>
<<includes>>
<<includes>>
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
Se utilizan para dar un formato uniforme a la
explicación textual de los casos de uso
108
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: ...
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: ...
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
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
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
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
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
........
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
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
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
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
Solicitar Producto
Recibir Pedido
Pagar Factura
Procesar Pedido
Facturar al Cliente
Cerrar Pedido
Extraer Artículos
Enviar Pedido
Diagramas de Actividades
120
Estado Inicial
Actividad
Acción
EstadoEstado
Condición
Actividad
Actividad
Transición
sin Disparador
División Unión
Estado Final
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
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)
122
Asignar Tareas
Replanificar
Seleccionar
Trabajos
[Hay Materiales]
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
Solicitar Producto
Recibir Pedido
Pagar Factura
Procesar Pedido
Facturar al Cliente
Cerrar Pedido
Extraer Artículos
Enviar Pedido
Cliente Ventas Almacen
O:Pedido
[en progreso]
O:Pedido
[completado]
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
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
return Punto(0,0)
do/ x=(l.delta-delta)/(pendiente-l.pendiente);
do/ y=(pendiente*x)+delta;
return Punto(0,0)
return Punto(x,y)
Punto Linea::intersec (L:Linea)
{
if (pendiente==l.pendiente) return Punto(0,0)
int x= (l.delta-delta)/(pendiente-l.pendiente);
int y=(pendiente*x)+delta;
return Punto(x,y);
}
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
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
Declaración de un evento
130
<<Signal>>
Colgar Inactivo
Activo
Colgar / cortarConexion()
<<signal>>
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
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
La relación entre una operación y los eventos que
puede generar se modela con una relación de
dependencia estereotipada como send.
134
colisión
fuerza : Float
(from eventos)
Agente de movimiento
posición
velocidad
moverA()
(from eventos)
<<send>>
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
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
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
Inactivo
Activo
When (11:49pm) / autotest()
after(2 seg) / cortar conexión
Aunque un evento de cambio modela un test continuo,
normalmente se transforma en condiciones puntuales
discretos en el tiempo
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
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.
140
gestor de Teclado
estado
tipo
reset()
Señales
pulsarBoton(b:boton)
encendido
apagado
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
fallo hardwarecolision
sensor : integer
fallo batería fallo mecanico Fallo de visión fallo de rango
Atasco Motor
Abstractas
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()
Conjunto
añadir()
eliminar()
Duplicado
Overflow
Underflow<<send>>
<<send>>
<<send>>
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
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
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
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
Inactivo
Activo
Timeout
do/ mensaje timeout
Tono de marcado
do/ reproducir tono
Marcando
Invalido
do/ Mensaje invalido
Espera
Hablando
Comunicando
do/ tono comunicando
Sonando
do/ tono llamada
Conexión
Timeout
do/ mensaje timeout
Tono de marcado
do/ reproducir tono
Marcando
Invalido
do/ Mensaje invalido
Espera
Hablando
Comunicando
do/ tono comunicando
Sonando
do/ tono llamada
Conexión
after( 15 seg ) tecla( t )[ incompleto ]
tecla( t )[ completo ]
conectado
ocupado
tecla( t )[ invalido ]
after( 15 seg )
tecla( t )
responde / habilitar voz
usr. llamado cuelga
descuelga / tono de marcado
cuelga / desconectar
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
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
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
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
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
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.
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
155 www.dsic.upv.es/~uml
Generalización de Estados
Ejemplo:
A B
C
e1
e2
e2
III. El Paradigma OO: Diagrama de Estados
156 www.dsic.upv.es/~uml
Quedaría como:
C
a bA Be1
e2
Generalización de Estados
III. El Paradigma OO: Diagrama de Estados
157 www.dsic.upv.es/~uml
Las transiciones de entrada deben ir hacia subestados específicos:
C
a bA B
e1
e2
e0
… Generalización de Estados
III. El Paradigma OO: Diagrama de Estados
158 www.dsic.upv.es/~uml
Es preferible tener estados iniciales de entrada a un nivel de manera que desde los niveles superiores no se sepa a qué subestado se entra:
C
a bA B
e1
e2
e1
e0
… Generalización de Estados
III. El Paradigma OO: Diagrama de Estados
Abrir
Cerrar
Sobregiro
Noficar a cliente
Retiro [balance <0]
Depósito [balance <0]
Verifica Balance
[Balance <0 for >30 días]
Cliente
Solicita
Cancelación
Estados
Nombre
Acciones de I / O
Transiciones
internas
Subestados
Eventos diferidos
Transiciones
Estado origen
Evento de
disparo
Condición de
guarda
Acción
Estado destino
Estado Inicial Estado Final
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
Initialization
Registration
Closed
Open
exit/ update database
do/ refresh screen
on select window( window )/ display new window
Closed
Open
exit/ update database
do/ refresh screen
on select window( window )/ display new window
Cancelled
Cancel course
Add student / Set
count = 0
Add student[ Count < 10 ]
[ Count = 10 ]
^CourseReport.Create
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
idle
inicializar( Nombre Simulador )
freeze
Cargar IC
cargar nueva IC
En Ejecución
EsperarConfirmación
run
Enviar Información
Interpretar comando
EsperarConfirmación
run
Pasar a Run[ IC cargada ] ^Gestor MC.pasar_a_run
Enviar Información
freeze
run
Interpretar comando
after 0.5 seg
comando simulación
H*
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
El símbolo representa una historia superficial, recuerda el
estado de la submáquina inmediata
Para recordar el estado más interno a cualquier profundidad se
utiliza
167
H
H*
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
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
169
Inactivo
Mantenimiento
Probar
Perifericos
Autodiagno
sis
Espera Orden
Probar
Perifericos
Autodiagno
sis
Espera Orden
mantener
continuar
tecla pulsada
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
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
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
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
Representación Gráfica:
En realidad se trata de un estereotipo
En Rational Rose, no existe este
estereotipo, hay que crearlo
174
Control comunicacion
estado
Ultimo mensaje
reset()
Señales
mensaje recibido
error_enviar
error_recibir
<<active>>
Control comunicacion
estado
Ultimo mensaje
reset()
Señales
mensaje recibido
error_enviar
error_recibir
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
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
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
En Rational Rose los objetos activos se pueden especificar en la
definición de la clase, pero no como estereotipo:
178
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
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
181
A : proceso
active
D :
proceso
active
B : proceso
active
C :
proceso
F : otro
sequential
G :
proceso
active1: sincrona
2: asincrona
3: balking
4: normal
5: timeout
H :
proceso
active
6: periódico
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
182
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
La clave en este caso es tratar un objeto como
una sección crítica
183
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
184
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
185
Uno de los diagramas más utilizados en las vistas de procesos son
los diagramas de interacción con flujos múltiples
186
leer_temperatura :
proceso
active
leer_presion :
proceso
active
controlador :
proceso
visualizar :
proceso
active
estadistica :
proceso
active
datos compartidos :
otro
guarded
calentador :
proceso
valvula :
proceso
p1: presion
t1: temp
t2: calentar
p2: abrir valvula
c1: actualizar
v1:
e1:
Introducción
Modelado estructural
Modelado del comportamiento
Modelado Arquitectónico
Componentes y diagramas de componentes
Diagramas de despliegue
Patrones y marcos de trabajo
187
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
188
Un componente es una parte física y
reemplazable de un sistema que implementa
un conjunto de interfaces
Gráficamente se representa por
189
Componente
En muchos 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
190
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
191
La relación entre un componente y las clases que
representa puede especificarse explícitamente
192
Cliente
Simulación
(.exe)
Interfaz CORBA
Ejecutivo Laminas
Dataview
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:
193
visualizador
Interfaz
dependencia
realización
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
194
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
195
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
196
Rational Rose no utiliza los anteriores componentes
estándar, sino el siguiente conjunto propio de
estereotipos
197
Espec. Paquete
Cuerpo Subprog.
Prog. PrincipalEspec. Subprog.
Cuerpo Paquete Espec. Proceso Cuerpo Proceso
198
199
signal.h {ver=3.5} signal.h {ver=4.0} signal.h {ver=4.1}
interp.cpp signal.cpp
irq.h device.cpp
parent
Su contenido particular incluye Componentes
Interfaces
Relaciones de dependencia, generalización, asociación y realización
Usos comunes Modelar código fuente
Modelar versiones ejecutables
Modelar bases de datos físicas
Modelar sistemas adaptables
Introducción
Modelado estructural
Modelado del comportamiento
Modelado Arquitectónico
Componentes y diagramas de componentes
Diagramas de despliegue
Patrones y marcos de trabajo
202
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
203
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
204
Procesador 1 Procesador 2
Dispositivo
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
205
Servidor
preemptive
dbadmintktmstr
terminal
preemptive
user.exe
Consola
10-T Ethernet
RS-232
UnidadRAID
206
207
208
Muestra la configuración de los nodos que
participan en la ejecución y los componentes que
residen en ellos.
Sus contenidos particulares son:
Nodos
Relaciones de dependencia y asociación
Usos comunes:
Modelar vistas de despliegue estáticas
Por ejemplo: distribución, entrega e instalación de las
partes que configuran el sistema físico
Modelar sistemas empotrados, cliente/servidor y de
componentes distribuidos
Sistemas Empotrados
Sistemas Cliente-Servidor
Sistemas Completamente Distribuidos
Introducción
Modelado estructural
Modelado del comportamiento
Modelado Arquitectónico
Componentes y diagramas de componentes
Diagramas de despliegue
Patrones y marcos de trabajo
212
Muestran el flujo de las actividades del sistema.
Son un caso particular de los diagramas de estados
Las actividades producen acciones.
Se usan para especificar Métodos
Casos de uso
Flujo de trabajo (workflow)
Los diagramas de actividades contienen: Estados de actividad y de acción
Transiciones
Objetos
Adquiere
información del
cliente
Crea nueva cuenta
de crédito
:Cuenta
[inicializando]
Ajusta Limite de Crédito
Verifica historia crediticia
del cliente
Revisar
histori
a
crediti
ciaRechaza
Cuenta
:Cuenta
[Rechazada]
Acepta
Cuenta
:Cuenta
[Aprobada]
Acepta
Términos
:Cuenta
[Abierta]
Firma
Contrato
Servicio a usuario Adm. Depto. Crédito Cliente
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
216
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
217
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
218
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
219
220
IDistribuido
Cola
añadirMensaje()
quitarMensaje()
contar()
Mensaje
ID
cabecera
cuerpo
Agente de Transporte
emisor
recibido
enviarMensaje()
1
1..*
1
+Buzón 1..* 1..*
1
1..*
colaDeEntrada colaDeSalida
221
: Actor: Mensaje : colaDeSalida : Agente de
Transporte
los agentes de transporte
periódicamente quitan
mensjaes de las colas
asignadas, según sus
politicas de planificación
1: crear
2: añadirMensaje
3: quitarMensaje
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
222
Paso de Mensajes
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
223
224
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
225
Observador
Sujeto
Observador
Cola Tareas
BarraDesplazamiento
Sujeto
Observador
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
226
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,....
227
228
Ejecutivo Cíclico<<framework>>
Gestor de Eventos
Cliente
Gestor
Eventos Comunes
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
229
Estudie el ejemplo de modelado del elevador
con UML accesibe de la página de apoyos del
curso
Top Related