SlideShare uma empresa Scribd logo
1 de 122
Baixar para ler offline
1
Paquetes
• Elemento organizativo
• Puede contener elementos de cualquier tipo.
• Un elemento es exclusivo a un paquete.
• Posibilidad de anidar paquetes.
Modelo
Modelo
+ Producto
+ CarroCompra
+ Comercio
2
Paquetes
• Un paquete bien estructurado debe:
– ser cohesivo
– estar poco acoplado
– poco anidamientos
– conjunto equilibrado de elementos
3
Importación/Exportación en paquetes
• Los paquetes permiten controlar la complejidad del manejo de un
gran número de abstracciones, controlando los accesos mediante la
importación.
• La parte pública de un paquete son sus exportaciones.
• Las partes públicas son visibles en los paquetes que
importan al paquete contenedor.
• La importación no es transitiva.
• Los paquetes anidados pueden ver todo lo que ven los
paquetes que los contienen.
Servidor
+ BaseDeDatos
+ ServicioDeRegistro
Cliente
+ FormularioPedido
+ FormularioDeSeguimiento
- Pedido
GUI
+ Ventana
+ Formulario
# GestorEventos
Politicas
+ ReglasPedidos
+ GUI:Ventana
import
import
5
Generalización de Paquetes
WindowsGUI
+ GUI:Ventana
+ Formulario
# GUI:GestorEventos
+ VBForm
GUI
+ Ventana
+ Formulario
# GestorEventos
MacGUI
6
Uso de los paquetes
• Agrupar elementos, normalmente del mismo tipo, para
manejarlos en conjunto.
Paquete “Clases e interfaces del modelo”
Paquete “Interfaces de usuario”
Paquete “Servicios base de datos”
• Un modelo es un paquete que incluye todos los
elementos que constituyen una particular vista del
sistema modelado.
7
Sistema, modelo, vista, diagrama
• Un sistema es aquello que se está desarrollando y para
lo que se crean modelos.
• Un subsistema es una parte de un sistema.
• Un modelo es una abstracción de un sistema que ayuda
a comprenderlo.
• Una vista es una proyección de la estructura y
organización de un modelo del sistema, centrada en
algún aspecto.
• Un diagrama es una representación de un conjunto de
elementos de un modelo.
8
Vistas UML
Vista de Diseño
Vista de Implementación
Vista de Procesos Vista de Despliegue
Vista de casos de uso
vocabulario
funcionalidad ensamblado
gestión conf.
topología
entrega
distribución
instalación
Funcionamiento
escalabilidad
rendimiento
comportamiento
9
Vistas UML
Vista de Diseño
Vista de Implementación
Vista de Procesos Vista de Despliegue
Vista de casos de uso
clases
interfaces
colaboraciones componentes
nodosclases activas
casos de uso
10
Vistas UML
Vista de Diseño
Vista de Implementación
Vista de Procesos Vista de Despliegue
Vista de casos de uso
Diagramas de clase
Diagramas de interacción
Diagramas de estado
Diagramas de componentes
Diagrama de interacción
Diagramas de estado
Diagramas de despliegue
Diagrama de interacción
Diagramas de estado
Diagramas de casos de uso
Diagramas de clase
Diagramas de interacción
Diagramas de estado
11
Diagrama de Objetos
d:DiagramaClases
:Clase
:Relacion
:Atributo
:Metodo :Clase :Clase
12
Diagrama de Objetos
:Universidad
d2:Departam ento d2:Departam ento
d ire cto r:Pro fe so r :P rofes or
:A signatur
a
13
Enlaces y Asociaciones
• Un enlace es :
– una conexión semántica entre objetos.
– una instancia de una asociación.
– un camino por el cual enviar un mensaje
Persona
calcularCompensacion()
asignar()
Empresa
*1..*
+patron+empleado
*1..*
p:Persona :Em presa
1: asignar(desarrollo)
mensaje
enlace
14
Interacciones y Mensajes
• Interacción: comportamiento que comprende un
conjunto de mensajes intercambiados entre un conjunto
de objetos dentro de un contexto para lograr un
propósito.
• Mensaje: especificación de una comunicación entre
objetos que transmite información, con la expectativa
de desencadenar una actividad.
15
Modelado del comportamiento
• Se describe cómo los objetos colaboran entre sí para
realizar cierta actividad.
• Se expresa mediante los diagramas de interacción:
– Diagramas de Secuencia y Diagramas de Colaboración (de
Comunicación en UML 2.0).
• También se describe las máquinas de estado que
caracterizan los objetos
– Diagramas de estado
– Diagramas de actividades
16
Diagramas de Interacción
• Describen una interacción.
• Dos tipos: Diagramas de Secuencia y Colaboración
• Diagramas de Secuencia:
– Destacan la ordenación temporal de los mensajes
• Diagramas de Colaboración:
– Destacan la organización estructural de los objetos
participantes.
• Equivalencia semántica
17
Diagramas de Secuencia
• Representan escenarios.
• Incluye:
– Objetos y su línea de tiempo
– Mensajes : argumentos y self-delegation
– Información de control: condiciones y marcas de
iteración
– Indicar el objeto devuelto por el mensaje: return
(añadirlos sólo cuando ayuden a clarificar la interacción)
– Especificar procesos concurrentes: focos de control
18
Sincronización
Envío de mensaje simple:
– Un solo hilo de ejecución
– El objeto activo pasa el control al objeto pasivo
Otro objetoUn cliente : Envío simple
19
Sincronización
Envío de mensaje síncrono:
– Sólo se desencadena la operación cuando el servidor
acepta el mensaje
– El cliente se bloquea hasta que el servidor lo acepta
o rechaza
Otro objetoUn cliente
: Envío síncrono
20
Sincronización
Envío de mensaje asíncrono:
– Un mensaje asíncrono no interrumpe la ejecución
del cliente
– El cliente envía el mensaje sin saber cuándo ni si se
llevará a cabo
Otro objetoUn cliente
: Envío asíncrono
Diagrama de secuencia
Un objeto puede enviarse a sí mismo un mensaje:
a
m ens aje reflex ivo
Puede representar
también la entrada por
parte del objeto en
cierta actividad de más
bajo nivel
Diagrama de secuencia
• Gráficamente también se puede indicar cuándo
el mensaje es para crear el objeto (va dirigido al
rectángulo del objeto o etiquetado con new) o
para destruirlo (va dirigido a la línea del objeto
pero el final de la flecha es una cruz)
Diagrama de secuencia
Normalmente no es necesario indicar el retorno del
control, cuando el envío es síncrono:
a b
E l retorno se
considera im plíc ito
cuando el envío es
síncrono
Diagrama de secuencia
En el caso asíncrono el retorno, si existe, se debe
representar:
a : aa b : aa
La flecha discontinua indica retorno del control
Media punta de flecha indica mensaje asíncrono (desde UML 1.3; en
UML 1.5 ya no se distingue, aunque se acepta)
Tipos de Control
El Diagrama de Secuencia refleja de manera
indirecta las opciones de control
Un control centralizado tiene una forma como esta:
Tipos de control
Un control descentralizado tiene una forma como
ésta:
Estructuras de control
Podemos representar iteraciones en el envío de
mensajes mientras, p.e., se cumpla una condición:
W hile X
Loop
end Loop
Estructuras de control
La iteración puede expresarse también como parte
del mensaje:
*[c ondic ión] M ens aje
Estructuras de control
Las bifurcaciones condicionales pueden
representarse de esta forma:
If condición
else
end if
Diagrama de secuencia
Diagrama de Secuencia
c:Comprador
:Transaccion
p:ServidorWeb
<<create>>
asignarrAcciones
asignarValores
exito
<<destroy>>
asignarValorestiempo
Línea de vida
del objeto
Foco de
control
La flecha discontínua indica
un retorno del control
Foco de control:Muestra el periodo de tiempo que un objeto está realizando una acción (períodos de actividad del
objeto). La parte superior indica cuándo se inicia la acción y la inferior cuándo se termina (puede estar marcada
con un mensaje de respuesta -return-, indicando que se devuelve el control al objeto destino -se indica con flecha
discontinua-)
31
Diagrama de Colaboración
c:Cliente :Transac
cion
p:Proxy
ODBC
1: <<create>>
2: establecerAcciones
3: establecerValores
5: exito
4: establecerValores
6: <<destroy>>
32
Diagrama de Secuencia
c:Cliente
:AgenteBilletes
a:Ayuda
Planificacion
<<create>>
establecerItinerario(i)
calcularRuta
ruta
<<destroy>>
notificar
33
Diagrama de Colaboración
a:Ay uda
Planificacion
c:Cliente :A gente
Billetes
3: calcularRuta
1: <<create>>
2: establecerItinerario(i)
5: <<destroy>>
4: ruta
6: notific ar
34
Diagramas de Secuencia
PedidoItem
:Interface
Entrada Pedido
:Pedido :LineaDe
Pedido
:Item
ItemEntregado
preparar
*preparar
hayStock:=comprobar
[hayStock] eliminar
pedir?:=necesarioPedir
[pedir?]<<create>>
[hayStock] <<create>>
35
Diagramas de Colaboración
:Interface Entrada
Pedido
:Pedido :LineaDe
Pedido
:Item
Pedido
Item
Item
Entregado
5: pedir?:=necesarioPedir
1: preparar 2: *preparar
3: hayStock:=comprobar
4: [hayStock] eliminar
7:
8: [hayStock] <<create>>
6: [pedir?]<<create>>
36
Uso de los diagramas de interacción
• Modelado del aspecto dinámico.
• Modelado del flujo de control que caracteriza el
comportamiento de un sistema:
– casos de uso
– colaboraciones
– patrones
– frameworks
– operaciones
37
Diagrama de Secuencia (Caso de uso)
: Interfaz Compra:
Cliente
: CarroCompra : Producto
iniciarCompra()
nuevoCarroCompra(cliente)
decremStock(cantidad)
seleccProducto(cantidad)
cargarProd(cliente,prod,cantidad)
obtenerDescripcionDe(prod)
confirmarCompra()
confirmarCompraDe(cliente)
Realizar para cada
producto incluido en
el carro de compra
38
Diagrama de Colaboración Caso de Uso)
: Interfaz
Compra
: Cliente
: Carro
Compra
: Producto
4: obtenerDescripcionDe(prod)
2: nuevoCarroCompra(cliente)
5: cargarProd(cliente,prod,c antidad)
7: confirmarCompraDe(cliente)
1: iniciarCompra()
3: seleccProducto(cantidad)
6: confirmarCompra()
8: decremS toc k(c antidad)
39
:OrderManager: Technical
Responsible
: Launch
Manufacturing GUI
:EvaluatedOrders o : Order : Product : WorkOrder: OrderLine
selectOrder()
selectOrder(cod)
o:=find(cod)
launchManufacturing()
launchManufacturing(cod)
launch manufacturing()
*generateWO()
tpl:=getTemplate()
createWO(tpl)
Diagrama de Secuencia
40
Escenario de un proceso de negocio
traveler : Employee authorizer : Employee bookkeeper : Employee paymaster : Employee
travelPermissionRequest()
travelPermission()
sendExpenseReport(anExpRep)
expenseReportOk(anE xpRep)
pay Reques t(aTraveler)
41
Escenario de un proceso de negocio
: JefeTecnico: Cliente : Comercial : JefeProduccion
darCursoPedido()
estudiarPedido()
* analizarFabricacionProducto()
informarAnalisisPedido()
planificarFabricacion()
acceptarPedido()
42
Patrón Observer
Observer
Update()
Subject
subjectState
Attach()
Detach()
Notify()
1..*1..1 1..*
+observers
1..1
ConcreteSubject
subjectState
getState()
setState()
ConcreteObserver
observerState
update()
+subject
observerState=
subject->getState()
for all o in observers
{o->update}
43
Patrón Observer
: Subject one : Observer
Update( )
SetState( )
Notify( )
GetState( )
another : Observer
Update( )
GetState( )
44
Patrón Observer
: Subject
one :
Observer
2: Notify( )
another :
Observer
1: SetState( )
4: GetS tate( )
3: Update( )
5: Update( )6: GetS tate( )
45
Colaboración
FabricaDeEditor
Editor
1..1
1..1
1..1
1..1
especifica
Gestor
1..*1..1 1..*1..1
ObjetoInformacion
1..*1..* 1..*1..*
editado con
ClienteDeGestor
1..11..* 1..11..*
1..*
0..*
1..*
0..*
necesita editar
46
Colaboración
: ClienteDeGestor : Gestor : FabricaDeEditor : ObjetoInformacion : Editor
obtenerEditorPara(objInfo)
obtenerInterfazSoportada()
s oportaInterfaz (nombreInterfaz)
crearEditorCon(objInfo)
Crear&IniciarCon(objInfo)
47
Caso de Uso (Nivel alto de abstracción)
:ReceptorPedido
: Cliente
:RealizacionPedido
enviarPedido
tramitarP edido
confirmarPedido
48
Caso de Uso (Nivel más bajo de abstracción)
: Cliente
:ReceptorPedidos :AgenteTarjeta
Credito
:RealizacionPedido :A genteFac turacion
enviarPedido
procesarTarjeta
tramitarPedido
confirmarPedido
emitirFactura
49
Casos de Uso y Escenarios
Caso de Uso Buscar Pedido
1. Se inicia al seleccionar el usuario la opción “Buscar
Pedido”.
2. El sistema presenta la ventana “Buscar Pedido”.
3. El usuario introduce un ID de un pedido
4. El usuario arranca la búsqueda
5. El sistema realiza una búsqueda en la BD de pedidos.
6. El sistema visualiza datos pedido.
:Interfaz Cancelar
Pedido
:Interfaz Buscar
Pedido : Base Datos: Usuario
Encontrar Pedido ()
visualizar ()
setIDPedido (IDPedido)
buscarPedido ()
p:=getPedido (IDPedido)
visualizarPedido (p)
51
new
validación
unaTransacción
unCoordinadorde
Transacción
unaPrimera
Comprobación
unaSegunda
Comprobación
x
x
new
new
ok
Todo
comprobado?
new Mensaje Asíncrono
Activación
Objeto Autoeliminado
ok
Todo
comprobado?
Diagramas de Secuencia:
Procesos concurrentes y activaciones
52
Diagramas de Secuencia vs. Diagramas de
Colaboración
• Equivalencia semántica
• Simples para comportamientos simples.
• Si hay mucho comportamiento condicional, usar
diferentes escenarios.
• Diagramas de secuencia muestran mejor el orden en que
se ejecutan los mensajes
• Diagramas de colaboración muestran claramente los
objetos con que interactúa un determinado objeto.
53
Diagramas de Actividades
• Muestran un flujo de actividades.
• Es un caso especial de máquina de estados.
• Incluye:
– estados actividad y estados acción
– transiciones
– objetos
• Una actividad realiza alguna acción que produce algún
cambio en el sistema o retorna un valor.
54
Estados Acción y Estados Actividad
• Un estado acción no se puede descomponer, representa una
computación atómica.
• Un estado actividad no es atómico, se compone de otros
estados acción y actividad.
• Al entrar se ejecuta la acción o actividad, al terminar el flujo
de control pasa a la siguiente acción o actividad.
• Misma notación
Procesar Pedido
55
Transiciones
Planificar proceso
Asignar tareas
estado final
estado inicial
transiciones
56
Bifurcación
Planificar proceso
Asignar tareas
[materiales disponibles]
Volver a planificar
[materiales no disponibles]
57
División y Unión
Preparar conversación
Limpieza
Emitir audio
Gesticular
Descomprimir
Mover boca
división
unión
Solicitar Producto
Procesar Pedido
Extraer Articulos
Enviar Pedido
Recibir Producto Facturar al cliente
Pagar Factura
Cerrar Pedido
Cliente Ventas Almacen
Solicitar Producto
Procesar Pedido
Extraer Articulos
Enviar Pedido
Recibir Producto Facturar al cliente
Pagar Factura
Cerrar Pedido
Calles
Cliente Ventas Almacen
Solicitar Producto
Procesar Pedido
Extraer Articulos
Enviar Pedido
Recibir Producto Facturar al cliente
Pagar Factura
Cerrar Pedido
o: Pedido
[en progreso]
o: Pedido
[completado]
b: Factura
[impagada]
61
Emitir billete
Pasajero Vendedor Airline
Ejemplo
Solicitar pago Reservar plazas
Confirmar
plaza reservadaPagar pasaje
Informar alternativas
y precios
Verificar
existencia vuelo
Dar detalles vuelo
Solicitar pasaje
Seleccionar vuelo
Rellenar Pedido
Cursar pedido
Notificar aceptacion
de pedido
Fin OK
Notificar rechazo
de pedido
Fin KO
Analizar viabilidad
¿Viable ?[ NO ]
Planificar produccion
[ SI ]
: JefeProduccion: JefeTecnico: Comercial: Cliente
p:Pedido
[propuesto]
p:Pedido
[rechazado]
p:Pedido
[aceptado]
:Orden de
Trabajo
[pendiente]
:Plantilla de
Produccion
:Catalogo
:Producto
Especial
p:Pedido
[en_evaluacion]
p:Pedido
[evaluado]
:Plantilla de
Produccion
Ordenar fabricacion
63
Utilidad de los diagramas de actividades
• Modelado de flujos de trabajo (workflow) como son los
procesos de negocio (business processes).
• Se puede asociar a cualquier elemento de modelado,
pero lo más normal es asociarlo a una operación:
diagrama de flujo de las acciones.
Diagramas de Estados
(Statecharts)
• Los statecharts representan máquinas de
estados (autómatas de estados finitos), con
estados y transiciones
• Los Statecharts de UML son básicamente los de
David Harel, extendidos con características OO
• Puede ser visto como un grafo de estados
conectados por transiciones etiquetadas
Statecharts
Modelan los aspectos dinámicos del sistema
Cada objeto sigue el comportamiento descrito en el Statechart asociado a su
clase
Cada objeto está en un estado en cierto instante
El estado está caracterizado parcialmente por los valores de los atributos del
objeto
Los Statecharts de UML son deterministas
La transición entre estados es instantánea y se debe a la ocurrencia de eventos
La suposición básica es que una máquina de estados procesa un evento cada
vez y termina con todas las consecuencias del evento antes de procesar otro.
Si ocurren dos eventos simultáneamente se procesan como si se hubieran
producido en cualquier orden, sin pérdida de generalidad
66
Eventos
• Un evento es un acontecimiento que ocupa un lugar en el
tiempo y espacio.
• Un evento es un estímulo que dispara una transición en
una máquina de estados.
• Eventos externos vs. Eventos internos.
• Tipos de eventos:
– Señales (excepciones)
– Llamadas
– Paso de tiempo
– Cambio de estado
Tipos de eventos
llamada: la recepción de una petición para invocar una operación. Normalmente un evento de
llamada es modelado como una operación del objeto receptor, manejado por un método del
receptor y se implementa como una acción o transición de la máquina de estados
señal: la recepción de una señal, que es una entidad a la que se ha dado nombre explícitamente
(clase estereotipada), prevista para la comunicación explícita - y asíncrona- entre objetos. Es
enviada por un objeto a otro objeto o conjunto de objetos. Las señales con nombre que
puede recibir un objeto se modelan designándolas en un compartimento extra de la clase de
ese objeto. Normalmente una señal es manejada por la máquina de estados del objeto
receptor y puede disparar una transición en la máquina de estados
tiempo: representa el paso del tiempo (ocurrencia de un tiempo absoluto respecto de un reloj
real o virtual o el paso de una cantidad de tiempo dada desde que un objeto entra en un
estado). Palabra clave after: after (2 segundos); after 1 ms desde la salida de devInactivo
cambio: evento que representa un cambio en el estado o el cumplimiento de alguna condición.
Palabra clave when, seguida de una expresión booleana, que puede ser de tiempo o de otra
clase: when (hora = 11:30); when ( altitud < 1000)
Tipos de eventos
Manual Automático
iniciarPilotoAutomático (normal)
• Evento de llamada (se representa igual que el de señal)
evento
parámetro
• Eventos de tiempo y de cambio
Inactivo Activo
after (2 segundos) / cortarConexión()
when (11:30PM) / autoTest()
evento de
cambio
evento de
tiempo
Modelado Excepciones
Conjunto
añadir()
eliminar()
Excepcion
establecerManejador()
primerManejador()
ultimoManejador()
<<exception>>
Duplicado
<<exception>>
Overflow
<<exception>>
Underflow
<<exception>>
<<send>>
<<send>> <<send>>
70
Estados
• Un estado es una situación en la vida de un objeto en la
que satisface cierta condición, realiza alguna actividad
o espera algún evento.
• Elementos de un estado
– Nombre
– Acciones entrada/salida
– Transiciones internas
– Subestados
– Eventos diferidos
71
Estados
Rastreando
entry/ activarModo(enRastreo)
exit / activarModo(noRastreo)
nuevoObjetivo/rastreador.adquirir
do / seguirObjetivo
autotest / defer
acción entrada
acción salida
transición interna
evento diferido
acción entrada
actividad
Estado inicial
• Se trata de un pseudoestado que indica el punto de partida por defecto para
una transición cuyo destino es el límite de un estado compuesto
• El estado inicial del estado de nivel más alto representa la creación de una
nueva instancia de la clase
• Sólo puede haber un estado inicial (directamente) dentro de cada estado
compuesto
Y
entry/b
X
Z
estado inicial
Transición al estado
inicial
e/a
f/d
/c
No se permiten
disparadores de evento, sí
acciones
Si estando en X se produce e, la transición pasa al estado Y. Se ejecuta la acción de entrada b y el estado inicial queda
activado. La transición saliente se dispara inmediatamente, ejecutando la acción c y pasando al estado Z. Si estando en X
se produce f, se ejecuta d, se ejecuta b, al entrar a Y, y se pasa a Z, sin ejecutar c, pues el estado inicial ya no está
implicado
Primer estado
propiamente dicho
Dueño del estado
inicial
Transición directa a un estado
interior
Estado final
• Estado especial dentro de un estado compuesto que, cuando está
activo, indica que la ejecución del estado compuesto ha terminado
y que una transición de finalización que sale del estado compuesto
está activada.
• Un estado final no es un pseudoestado. Puede ser activado por un
periodo de tiempo, a diferencia del inicial que transita
inmediatamente a su sucesor, p.ej., mientras espera la terminación de
otros subestados concurrentes en el mismo estado compuesto
• Las transiciones entrantes son transiciones normales
X
eY Z
estado final
El evento e causa la transición al estado final, que causa la transición de finalización hacia Z
Estado final
• Sólo puede ocurrir un estado final (directamente) dentro de un estado compuesto.
El símbolo de estado final puede repetirse dentro de un estado, pero cada copia
representa el mismo estado final.
• Si un objeto alcanza su estado final de nivel superior, la máquina de estados
termina y se destruye el objeto
• Es posible que no haya estado final, indicando una actividad continua (común por
ejemplo en sistemas empotrados)
75
Transiciones
• Una transición de un estado A a un estado B, se
produce cuando se origina el evento asociado y se
satisface la condición especificada, en cuyo caso se
ejecuta la acción de salida de A, la acción de entrada a
B y la acción asociada a la transición.
• Elementos de una transición:
– Estados origen y destino
– Evento de disparo
– Condición de guarda
– Acción
Elementos de una transición
estado origen
• la transición se disparará si, estando en el estado origen, se produce el evento de
disparo y si la condición de guarda, si la hay, se satisface
estado destino
• estado activo tras completarse la transición
evento de disparo.
• cuando se produce un evento, afecta a todas las transiciones que lo contienen en su
etiqueta. Todas las apariciones de un evento en la misma máquina de estados deben
tener la misma signatura
condición de guarda
• expresión booleana. Si es falsa, la transición no se dispara, y si no hay otra transición
etiquetada con el mismo evento que pueda dispararse, éste se pierde
acción
• computación atómica ejecutable. Puede incluir llamadas a operaciones sobre el objeto
que contiene la máquina de estados (o sobre otros visibles), creación o destrucción de
objetos, o envío de una señal a otro objeto
Las condiciones o guardas permiten condicionar
la transición:
a b
Eve nto[ condición ]
Guardas en una transición
Acciones en una transición
Podemos especificar la ejecución de una acción
como consecuencia de la transición:
a b
Evento[ condición ] / acción
Dicha acción también se considera instantánea
Acción: computación atómica ejecutable que produce un cambio en el estado del
modelo o que devuelve un valor. Puede ser realizada mediante el envío de un
mensaje a un objeto provocando la modificación de un enlace o del valor de un
atributo en un objeto. Puede incluir llamadas a operaciones (sobre el objeto que
contiene la máquina de estados, así como sobre otros objetos visibles), creación o
destrucción de objetos, o el envío de una señal a un objeto
Podemos especificar el envío de un evento a
otro objeto como consecuencia de la transición:
a
b
Evento( arg1, arg2 )[ condición ] / ^otro_objeto.evento(arg2)
Acciones en una transición
80
Máquina de estados
• Especifica la secuencia de estados por las que pasa un
objeto a lo largo de su vida en respuesta a eventos, junto
con sus respuestas a esos eventos.
• Útil si las instancias de una clase tienen un comportamiento
que depende de su historia o que deben responder a eventos
externos: objetos reactivos.
• Se representa mediante un diagrama de estados.
Asociado a la clase Persona:
en el paro en activo
jubilado
contratar
perder empleo
jubilarse
jubilarse
Ejemplo de Statechart
transición
estado
estado final
estado inicial
Ejemplo de Statechart
Transiciones simples y complejas
Close Open
Background Selected
ReadyFor
Writing
Disabled
Enabled
Position
Visualisation
autotransición
Buscando
Rastreando
Configuración
Acoplamiento
ruido
evento de disparo
transición sin disparador: (denota una transición
final: que se dispara automática-mente cuando
el estado origen termina su actividad)
contactar
after(2 segundos) / send c.estaActivo
envío de señalevento de tiempo
objetivoEn(p) [representaAmenaza] / t.añadirObjetivo(p)
evento de disparo con
parámetros condición de guarda acción
Inactivo
Pendiente de
aceptación
No
aceptada
Pendiente de
envío a factoría
En realización
Realizada
Finaliza S.A.D.
Modificar hoja
Administrador rechaza hoja
Administrador acepta hoja
Modificación por pedido urgente
Envío a factoría
Hojar rutas realizada
Inicio
Pendiente de
envío a Bualgas
Pendiente de
análisis
Viable
AprobadoAsignado a Hoja
de Rutas
Pendiente de
realización
Realizado
Rechazado Pendiente de
aprobación
No
realizado
Envío a Bualgas Factible[ Analizado ]
Modificar hoja
Administrador rechaza hoja
Finaliza S.A.D
Modificar hoja
Envío a factoría
Realizado[ Hoja Rutas realizada ]
No factible[ Analizado ]
Comunicacion de Rechazo a Central
Envío a jefe
Aprobado[ Estudiado ]
No aprobado[ Estudiado ]
No realizado[ Hoja Rutas realizada ]
Aprobado
86
Subestados secuenciales
Selección
Mantenimiento
Activo
Validación
Inactivo
Procesando
Impresión
mantener
introducirTarjeta
cancelar
[continuar]
[no continuar]
entry/leerTarjeta
exit/expulsarTarjeta
87
Subestados secuenciales
Activo
Chequeando
Do/chequeo
Esperando
Enviando
Do/Iniciar_
entrega
Siguiente_item
[No todo items
chequeado] [Todo item chequeado y
disponible]
Item Recibido
[todo item disponible]
[Todo item chequeado y
alguno no disponible]
Item Recibido
[algún item no disponible]
Cancelado Entregado
cancelado
88
Subestados concurrentes
Mantenimiento
Probar
perifericos
Inactivo
AutoDiagnosis
mantener
[continuar]
[no continuar]
Pruebas
Espera Orden
Manejo Ordenes
Pulsar tecla
89
Componentes
• Un componente es una parte física y reemplazable de un
sistema, que conforma con un conjunto de interfaces y
proporciona su implementación.
• Modela artefactos tales como: ejecutables, bibliotecas,
tablas, ficheros, documentos,..
• Representa el empaquetamiento físico de elementos
lógicos tales como clases, interfaces,..
• Residirán en los nodos del sistema
90
Componentes
explorador.java
agenteFraudes.dll
Realiza
agenteFraudes
politicaFraudes
busquedaPatrones
91
Componentes
explorador.java arbol.java
El componente arbol.java puede ser reemplazado por otro
que proporcione la interfaz JerarquíaElementos.
JerarquíaElementos
Estereotipos: executable, library, file, table, document
92
Tipos de componentes
• Despliegue
– Necesarios y suficientes para formar un sistema ejecutable:
librerías dinámicas(dll), ejecutables (exe),..
• Productos del trabajo
– Permanecen al final del proceso de desarrollo: archivos código
fuentes, ficheros de datos,..
– Con ellos se crean los componentes de despliegue
• De ejecución
– Se crean durante la ejecución: objeto COM, instanciado a partir
de una dll.
93
Diagrama de Componentes
• Modelado de ejecutables y bibliotecas
• Modelado de código fuente
• Modelado de una API
94
Modelado de ejecutables
v.exe
Vwbas20.dll vwdev20.dll
vwsrc20.dll
95
Ejemplo
Control y Análisis
Comm
Acceso a BD
Comm
Rutinas de Coneccion
Comm
Interfaz de Terminal
Comm
Gestión de Cuentas
Comm
96
Nodos
• Un nodo es un elemento físico que existe en tiempo de
ejecución y representa un recurso computacional que
puede tener memoria y capacidad de procesamiento.
• Los componentes se ejecutan en nodos
• Los nodos representan el despliegue físico de los
componentes.
97
Diagramas de Despliegue
• Muestra la configuración de los nodos que participan en
la ejecución y de los componentes que residen en los
nodos.
• Incluye nodos y arcos que representan conexiones físicas
entre nodos.
• Modelado de sistemas empotrados, sistemas cliente-
servidor, sistemas distribuidos.
98
Diagrama de Despliegue
servidor Unidad
RAID
Consola
<<RS-232>>
terminal
<<10-T-Ethernet>>
99
servidor cache
<<procesador>
servidor cache
<<procesador>>
servidor
principal
<<procesador>
servidor
<<procesador>
servidor
<<procesador>>
servidor
<<procesador>>
<<red>> red local
internet
Modem
100
Colaboraciones
• Sociedad de clases, interfaces y otros elementos que
colaboran para proporcionar un comportamiento
cooperativo mayor que la suma de los comportamientos
de los elementos.
• Parte estructural (diagrama de clases) y parte de
comportamiento (diagrama de interacción).
101
Colaboraciones
• El núcleo de la arquitectura de un sistema está formado
por un conjunto de colaboraciones que representan las
decisiones de diseño más importantes.
• Un sistema orientado a objetos bien estructurado se
compone de un conjunto relativamente pequeño de
colaboraciones.
• Modelado de un caso de uso, operación o mecanismo
(patrón o framework)
102
Casos de uso y Colaboraciones
Hacer Pedido
Gestión Pedidos
caso de uso
colaboración
realización
103
Gestor Documentos (Parte estática)
FabricaDeEditor
Editor
1..1
1..1
1..1
1..1
especifica
Gestor
1..*1..1 1..*1..1
ObjetoInformacion
1..*1..* 1..*1..*
editado con
ClienteDeGestor
1..11..* 1..11..*
1..*
0..*
1..*
0..*
necesita editar
104
Gestor Documentos (Comportamiento)
Crear&IniciarCon(objInfo)
: ClienteDeGestor : Gestor : FabricaDeEditor : ObjetoInformacion : Editor
obtenerEditorPara(objInfo)
obtenerInterfazSoportada()
soportaInterfaz(nombreInterfaz)
crearEditorCon(objInfo)
105
Colaboraciones Parametrizadas
Observer
Subject
Observer
Alarma Ventana
Subject Observer
Modelado de patrones de diseño
106
Patrón de diseño (Parte Estática)
Observer
Update()
Subject
subjectState
Attach()
Detach()
Notify()
1..*1..1 1..*
+observers
1..1
ConcreteSubject
subjectState
getState()
setState()
ConcreteObserver
observerState
update()
+subject
observerState=
subject->getState()
for all o in observers
{o->update}
107
Patrón de diseño (Parte dinámica)
: Subject one : Observer
Update( )
SetState( )
Notify( )
GetState( )
another : Observer
Update( )
GetState( )
OCL (Object Constraint Language)
• OCL puede ser usado por UML y otros lenguajes para
especificar restricciones, expresiones de navegación,
expresiones booleanas, consultas y otras expresiones
incluidas en sus modelos.
• Lenguaje “formal” (más bien “semiformal”) para
expresar restricciones libres de efectos colaterales.
• Las expresiones OCL no cambian el estado del
sistema. No está destinado a escribir acciones o código
ejecutable
• OCL es un lenguaje tipado.
• Desarrollado por Joe Warmer dentro de IBM.
Uso de OCL
• OCL puede ser usado con distintos fines:
– Para especificar invariantes sobre clases y tipos en el
modelo de clases.
– Para especificar pre y post-condiciones sobre operaciones y
métodos.
– Para describir guardas (en statecharts y otros elementos).
– Como lenguaje de navegación.
– Para especificar restricciones sobre operaciones.
• OCL es utilizado también para especificar la
semántica de UML.
(tomado de la documentación de
UML v1.4)
1
OCL. Self y context; Invariantes
• Cada expresión OCL se escribe en el contexto de una instancia de un tipo
específico. Se usa self para referirse a la instancia contextual. Por ejemplo, si
el contexto es Company, self se refiere a una instancia de Company.
• Ejemplo:
context Company
inv: self.numberOfEmployees > 50
Si el contexto es claro, se puede suprimir self. También se puede representar de
forma alternativa con un nombre distinto como en:
context c : Company
inv:c.numberOfEmployees > 50
OCL. Pre-, Post- condiciones de una
operación
• Se usan las etiquetas ‘pre’ y ‘post’ antes de especificar las pre-y
post-condiciones, que además pueden tener un nombre
(resultOK). La declaración de operación, con sus parámetros,
sigue a context y al tipo al que pertenece.
• self se referirá al objeto sobre el que se llama la operación
• result denota el resultado de la operación, si lo hay.
• Se pueden usar los nombres de los parámetros (param1…).
context Typename::operationName(param1 : Type1, ... ): ReturnType
pre parameterOk: param1 > ...
post resultOk: result = ...
Tipos básicos y predefinidos
• Tipos básicos:
• Boolean, Integer, Real y String.
• Se complementan con:
Collection, Set, Bag y Sequence así como los de
Enumeration, OclExpression, OclType, OclState y
OclAny
Tipos predefinidos
• Tipos Básicos: Existen una serie de tipos básicos predefinidos (y
operaciones sobre ellos) en OCL, que son: Boolean, Integer,
Real, String.
• Collection, Set, Bag y Sequence se consideran también tipos
básicos
Propiedades: Atributos
Ejemplo: la edad de una Persona se escribe como self.age:
context Person inv:
self.age > 0
El valor de la subexpresión self.age es el valor del atributo age
sobre el objeto self. El tipo de esta subexpresión es el tipo del
atributo age (en este caso tipo básico Integer)
El invariante de arriba está expresando que
“la edad de una persona es siempre mayor que cero”
Propiedades: Operaciones
Ejemplo: un objeto persona tiene una operación income que es
función de fecha (Date).
Para un persona aPerson y una fecha aDate, esta operación
sería accedida como:
aPerson.income(aDate)
La operación puede ser definida con una postcondición. El
objeto devuelto por ésta (el resultado) se denomina result:
context Person::income (d: Date) : Integer
post: result = age * 1000
Se ponen paréntesis aunque la operación o método no tenga
argumentos:
context Company inv:
self.stockPrice() > 0
Propiedades: Extremos de asociación y
navegación
Ejemplo: context Company
inv: self.manager.isUnemployed = false
inv: self.employee->notEmpty
En el primer invariante, self.manager es una persona (la
multiplicidad de la asociación es 1)
En el segundo, self.employee se evaluará a un conjunto de
personas. La expresión completa es un valor booleano que
vale true cuando la colección a la izquierda es no vacía.
Si la asociación en el Diagrama de Clases está adornada con
{ordered}, en lugar de un conjunto (valor por defecto de la
navegación) obtendríamos una secuencia como resultado
Propiedades: Extremos de asociación y
navegabilidad
• Se puede acceder a las propiedades de los tipos colección (Sets,
Bags, Sequences ) mediante una flecha ‘->’ seguida por el nombre
de la propiedad:
context Person
inv: self.employer->size < 3
Aplica la propiedad size sobre el conjunto (Set) self.employer, que resulta en
el número de “empleadores” de la persona self.
context Person
inv: self.employer->isEmpty
Aplica la propiedad isEmpty sobre el conjunto self.employer. Se evalúa a
true si el conjunto de empleadores es vacío o false en caso contrario.
OCL. Más ejemplos
Atributos:
context Persona inv:
self.edad>0
context Banco inv límEmpleados:
self.empleados < 100
Opcionalmente, la restricción puede
tener un nombre, en este caso
“límEmpleados”
Extremos de asociación y Navegación:
context Persona inv:
self.esposa->notEmpty implies
self.esposa.sexo=femenino
PERSONA
esCasado: Booleano
fechaNacimiento:Fecha
edad:Integer
nombre: String
sexo: enum{mas,fem}
ingreso(fecha):Integer
MATRIMONIO
lugar: String
fecha: Fecha
BANCO
Empleados:Integer
0..1 Cliente
0..*
Esposo 0..1
Esposa
0..1
implies es una
operación definida
sobre el tipo de
datos predefinido de
OCL, Boolean
OCL. Más ejemplos
Operaciones:
context
Persona::ingreso(fecha):Integer
post: result > 1000
context Person::birthdayHappens()
post: age = age@pre + 1
El valor de una propiedad en una postcondición es el valor
después de haberse completado la operación. Para referirse al
valor de la propiedad al principio de la operación, se usa el
postfijo ‘@pre’, detrás del nombre de la propiedad.
OCL. Colecciones
• Operaciones de las Colecciones.
– Seleccionar y Descartar (Select, Reject)
context Banco inv:
self.cliente->select(edad>50) --cto de personas
--mayores de 50
– Recolectar (Collect)
context Banco inv:
self.cliente->collect(fechaNacimiento) -- bolsa con
--las fechas de nacimiento de los empleados
OCL. Colecciones
– ParaTodos (ForAll)
context Banco inv:
self.cliente->forAll(Nombre=‘Juan’) -- verdadero si
--todos los clientes se llaman Juan
– Existe (Exists)
context Company inv:
self.employee->exists( forename = 'Jack' )
context Company inv:
self.employee->exists( p | p.forename = 'Jack' )
context Company inv:
self.employee->exists( p : Person | p.forename = 'Jack' )
Estas expresiones se evaluan a true si la característica forename de
al menos un empleado es igual a ‘Jack.’

Mais conteúdo relacionado

Mais procurados

Unidad 2. modelo entidad relacion
Unidad 2. modelo entidad relacionUnidad 2. modelo entidad relacion
Unidad 2. modelo entidad relacionLuiS YmAY
 
Diagramas de colaboracion
Diagramas de colaboracionDiagramas de colaboracion
Diagramas de colaboraciond-draem
 
Analisis Y DiseñO Orientado A Objetos
Analisis Y DiseñO Orientado A ObjetosAnalisis Y DiseñO Orientado A Objetos
Analisis Y DiseñO Orientado A Objetosyoiner santiago
 
Diagramas de clases y actividades
Diagramas de clases y actividadesDiagramas de clases y actividades
Diagramas de clases y actividadesTerryJoss
 
Diagrama de clases
Diagrama de clasesDiagrama de clases
Diagrama de clasesNedoww Haw
 
2 2 estilos arquitectonicos
2 2 estilos arquitectonicos2 2 estilos arquitectonicos
2 2 estilos arquitectonicoslandeta_p
 
Gestor de almacenamiento
Gestor de almacenamientoGestor de almacenamiento
Gestor de almacenamientoCarlos Mila
 
Diagramas de clase.pptx
Diagramas de clase.pptxDiagramas de clase.pptx
Diagramas de clase.pptxCAMILORUALES1
 
Ingenieria de requerimientos 1
Ingenieria de requerimientos 1Ingenieria de requerimientos 1
Ingenieria de requerimientos 1jmpov441
 
Unidad 4 graficación
Unidad 4 graficaciónUnidad 4 graficación
Unidad 4 graficaciónAndhy H Palma
 
MODELO COCOMO (INGENIERA DE SOFTWARE)
MODELO COCOMO (INGENIERA DE SOFTWARE)MODELO COCOMO (INGENIERA DE SOFTWARE)
MODELO COCOMO (INGENIERA DE SOFTWARE)Yadith Miranda Silva
 
Modelo Entidad Relación Extendido.
Modelo Entidad Relación Extendido.Modelo Entidad Relación Extendido.
Modelo Entidad Relación Extendido.nayis2010
 
Metodologías de desarrollo de software
Metodologías de desarrollo de softwareMetodologías de desarrollo de software
Metodologías de desarrollo de softwareWilfredo Mogollón
 

Mais procurados (20)

Unidad 2. modelo entidad relacion
Unidad 2. modelo entidad relacionUnidad 2. modelo entidad relacion
Unidad 2. modelo entidad relacion
 
Diagramas de secuencia
Diagramas de secuenciaDiagramas de secuencia
Diagramas de secuencia
 
Diagramas de colaboracion
Diagramas de colaboracionDiagramas de colaboracion
Diagramas de colaboracion
 
Analisis Y DiseñO Orientado A Objetos
Analisis Y DiseñO Orientado A ObjetosAnalisis Y DiseñO Orientado A Objetos
Analisis Y DiseñO Orientado A Objetos
 
Diagramas de clases y actividades
Diagramas de clases y actividadesDiagramas de clases y actividades
Diagramas de clases y actividades
 
Diagrama de clases
Diagrama de clasesDiagrama de clases
Diagrama de clases
 
2 2 estilos arquitectonicos
2 2 estilos arquitectonicos2 2 estilos arquitectonicos
2 2 estilos arquitectonicos
 
Gestor de almacenamiento
Gestor de almacenamientoGestor de almacenamiento
Gestor de almacenamiento
 
Diagramas De Caso De Uso
Diagramas De Caso De UsoDiagramas De Caso De Uso
Diagramas De Caso De Uso
 
Diagramas de clase.pptx
Diagramas de clase.pptxDiagramas de clase.pptx
Diagramas de clase.pptx
 
Requisitos no Funcionales
Requisitos no FuncionalesRequisitos no Funcionales
Requisitos no Funcionales
 
Ingenieria de requerimientos 1
Ingenieria de requerimientos 1Ingenieria de requerimientos 1
Ingenieria de requerimientos 1
 
Unidad 4 graficación
Unidad 4 graficaciónUnidad 4 graficación
Unidad 4 graficación
 
MODELO COCOMO (INGENIERA DE SOFTWARE)
MODELO COCOMO (INGENIERA DE SOFTWARE)MODELO COCOMO (INGENIERA DE SOFTWARE)
MODELO COCOMO (INGENIERA DE SOFTWARE)
 
Modelo relacional
Modelo relacionalModelo relacional
Modelo relacional
 
Ej Normalizacion Juan Glz
Ej Normalizacion Juan GlzEj Normalizacion Juan Glz
Ej Normalizacion Juan Glz
 
Roles desarrollo del software
Roles desarrollo del softwareRoles desarrollo del software
Roles desarrollo del software
 
Diagrama de Actividades
Diagrama de ActividadesDiagrama de Actividades
Diagrama de Actividades
 
Modelo Entidad Relación Extendido.
Modelo Entidad Relación Extendido.Modelo Entidad Relación Extendido.
Modelo Entidad Relación Extendido.
 
Metodologías de desarrollo de software
Metodologías de desarrollo de softwareMetodologías de desarrollo de software
Metodologías de desarrollo de software
 

Destaque

Normalización de las estructuras
Normalización de las estructurasNormalización de las estructuras
Normalización de las estructurasJuan Soubervielle
 
Introducción a las base de datos
Introducción a las base de datosIntroducción a las base de datos
Introducción a las base de datosJuan Soubervielle
 
Sistema de ventas, compras y almacén
Sistema de ventas, compras y almacénSistema de ventas, compras y almacén
Sistema de ventas, compras y almacénLeo Ruelas Rojas
 
Modelado del AnáLisis
Modelado del AnáLisisModelado del AnáLisis
Modelado del AnáLisisCarolina Rojas
 
Diagrama uml ing software i promecys
Diagrama uml ing software i promecysDiagrama uml ing software i promecys
Diagrama uml ing software i promecysLeonel Narvaez Ruiz
 
Diagramas de actividad
Diagramas de actividadDiagramas de actividad
Diagramas de actividadJulio Pari
 
diagrama de casos de uso del negocio y del sistema
diagrama de casos de uso del negocio y del sistemadiagrama de casos de uso del negocio y del sistema
diagrama de casos de uso del negocio y del sistemaUniversidad Tecnológica
 

Destaque (10)

Normalización de las estructuras
Normalización de las estructurasNormalización de las estructuras
Normalización de las estructuras
 
Proyecto Auditoria De Examen Virtual
Proyecto Auditoria De Examen VirtualProyecto Auditoria De Examen Virtual
Proyecto Auditoria De Examen Virtual
 
Tipos de bases de datos
Tipos de bases de datosTipos de bases de datos
Tipos de bases de datos
 
Introducción a las base de datos
Introducción a las base de datosIntroducción a las base de datos
Introducción a las base de datos
 
Sistema de ventas, compras y almacén
Sistema de ventas, compras y almacénSistema de ventas, compras y almacén
Sistema de ventas, compras y almacén
 
Modelado del AnáLisis
Modelado del AnáLisisModelado del AnáLisis
Modelado del AnáLisis
 
Diagrama uml ing software i promecys
Diagrama uml ing software i promecysDiagrama uml ing software i promecys
Diagrama uml ing software i promecys
 
Diagramas de actividad
Diagramas de actividadDiagramas de actividad
Diagramas de actividad
 
Sistema de Ventas, presentacion
Sistema de Ventas, presentacionSistema de Ventas, presentacion
Sistema de Ventas, presentacion
 
diagrama de casos de uso del negocio y del sistema
diagrama de casos de uso del negocio y del sistemadiagrama de casos de uso del negocio y del sistema
diagrama de casos de uso del negocio y del sistema
 

Semelhante a Teoria del modelado de objetos otros diagramas actividad despliegue

UML - Vista de interaccion.pptx
UML - Vista de interaccion.pptxUML - Vista de interaccion.pptx
UML - Vista de interaccion.pptxMichelGarcia69
 
Visual basic
Visual basicVisual basic
Visual basicjosser96
 
A2-Tema4.pdf
A2-Tema4.pdfA2-Tema4.pdf
A2-Tema4.pdfAlMoon5
 
Los 13 diagramas UML y sus componentes
Los 13 diagramas UML y sus componentesLos 13 diagramas UML y sus componentes
Los 13 diagramas UML y sus componentesVictor Escamilla
 
diagramas de interaccion
diagramas de interacciondiagramas de interaccion
diagramas de interaccionjent46
 
Modelado Estrcutural, Modelado Estructural Casos De USO
Modelado Estrcutural, Modelado Estructural Casos De USOModelado Estrcutural, Modelado Estructural Casos De USO
Modelado Estrcutural, Modelado Estructural Casos De USORobert Rodriguez
 
Clase diagramas desecuencia
Clase diagramas desecuenciaClase diagramas desecuencia
Clase diagramas desecuenciaESTEVAN GOMEZ
 
ANALISIS DE LAS RELACIONES.ppt
ANALISIS DE LAS RELACIONES.pptANALISIS DE LAS RELACIONES.ppt
ANALISIS DE LAS RELACIONES.pptRogelioYez1
 
Estructuración del blog
Estructuración del blogEstructuración del blog
Estructuración del blogMatthewMuoz5
 
UDA-Componentes RUP. Wizard
UDA-Componentes RUP. WizardUDA-Componentes RUP. Wizard
UDA-Componentes RUP. WizardAnder Martinez
 
DiagramasDeSecuencia COMP Y ABAST5-SEM.ppt
DiagramasDeSecuencia COMP Y ABAST5-SEM.pptDiagramasDeSecuencia COMP Y ABAST5-SEM.ppt
DiagramasDeSecuencia COMP Y ABAST5-SEM.pptJoseChaaparroo1
 
Introducción JavaScript
Introducción JavaScriptIntroducción JavaScript
Introducción JavaScriptUNED
 
Progressbar
ProgressbarProgressbar
Progressbaredddyx05
 
Diagrama de flujo_de_datos_(dfd)[1]
Diagrama de flujo_de_datos_(dfd)[1]Diagrama de flujo_de_datos_(dfd)[1]
Diagrama de flujo_de_datos_(dfd)[1]jauanilfabian
 

Semelhante a Teoria del modelado de objetos otros diagramas actividad despliegue (20)

UML - Vista de interaccion.pptx
UML - Vista de interaccion.pptxUML - Vista de interaccion.pptx
UML - Vista de interaccion.pptx
 
Visual basic
Visual basicVisual basic
Visual basic
 
A2-Tema4.pdf
A2-Tema4.pdfA2-Tema4.pdf
A2-Tema4.pdf
 
Los 13 diagramas UML y sus componentes
Los 13 diagramas UML y sus componentesLos 13 diagramas UML y sus componentes
Los 13 diagramas UML y sus componentes
 
Dfd
DfdDfd
Dfd
 
diagramas de interaccion
diagramas de interacciondiagramas de interaccion
diagramas de interaccion
 
Modelado Estrcutural, Modelado Estructural Casos De USO
Modelado Estrcutural, Modelado Estructural Casos De USOModelado Estrcutural, Modelado Estructural Casos De USO
Modelado Estrcutural, Modelado Estructural Casos De USO
 
Visual studio 2010
Visual studio 2010Visual studio 2010
Visual studio 2010
 
Diagramas de Interaccion
Diagramas de InteraccionDiagramas de Interaccion
Diagramas de Interaccion
 
Uml
UmlUml
Uml
 
Clase diagramas desecuencia
Clase diagramas desecuenciaClase diagramas desecuencia
Clase diagramas desecuencia
 
Arquitectura integra 2
Arquitectura integra 2Arquitectura integra 2
Arquitectura integra 2
 
ANALISIS DE LAS RELACIONES.ppt
ANALISIS DE LAS RELACIONES.pptANALISIS DE LAS RELACIONES.ppt
ANALISIS DE LAS RELACIONES.ppt
 
Semana13-AOO.ppt
Semana13-AOO.pptSemana13-AOO.ppt
Semana13-AOO.ppt
 
Estructuración del blog
Estructuración del blogEstructuración del blog
Estructuración del blog
 
UDA-Componentes RUP. Wizard
UDA-Componentes RUP. WizardUDA-Componentes RUP. Wizard
UDA-Componentes RUP. Wizard
 
DiagramasDeSecuencia COMP Y ABAST5-SEM.ppt
DiagramasDeSecuencia COMP Y ABAST5-SEM.pptDiagramasDeSecuencia COMP Y ABAST5-SEM.ppt
DiagramasDeSecuencia COMP Y ABAST5-SEM.ppt
 
Introducción JavaScript
Introducción JavaScriptIntroducción JavaScript
Introducción JavaScript
 
Progressbar
ProgressbarProgressbar
Progressbar
 
Diagrama de flujo_de_datos_(dfd)[1]
Diagrama de flujo_de_datos_(dfd)[1]Diagrama de flujo_de_datos_(dfd)[1]
Diagrama de flujo_de_datos_(dfd)[1]
 

Mais de Robert Rodriguez

Modelo Entidad Relacion ,Base de datos
Modelo Entidad Relacion ,Base de datosModelo Entidad Relacion ,Base de datos
Modelo Entidad Relacion ,Base de datosRobert Rodriguez
 
Diseño Logico de base de datos
Diseño Logico de base de datosDiseño Logico de base de datos
Diseño Logico de base de datosRobert Rodriguez
 
Diseño Logico - Diseño de bases de datos relacionales
Diseño Logico - Diseño de bases de datos relacionalesDiseño Logico - Diseño de bases de datos relacionales
Diseño Logico - Diseño de bases de datos relacionalesRobert Rodriguez
 
Diseño Logico de Base de datos Relacionales
Diseño Logico de Base de datos RelacionalesDiseño Logico de Base de datos Relacionales
Diseño Logico de Base de datos RelacionalesRobert Rodriguez
 
Base de Datos, Diseño Comceptual , logico y Fisico
Base de Datos, Diseño Comceptual , logico y FisicoBase de Datos, Diseño Comceptual , logico y Fisico
Base de Datos, Diseño Comceptual , logico y FisicoRobert Rodriguez
 
Teoria del modelado de objetos modificado
Teoria del modelado de objetos modificadoTeoria del modelado de objetos modificado
Teoria del modelado de objetos modificadoRobert Rodriguez
 
Modelado funcional casos de uso
Modelado funcional casos de usoModelado funcional casos de uso
Modelado funcional casos de usoRobert Rodriguez
 
Que es Ingenieria del Software?,
Que es Ingenieria del Software?,Que es Ingenieria del Software?,
Que es Ingenieria del Software?,Robert Rodriguez
 
Diseño logico de una base de datos
Diseño logico de  una base de datosDiseño logico de  una base de datos
Diseño logico de una base de datosRobert Rodriguez
 
Casos de Uso - Juan Bernardo Quintero
Casos de Uso - Juan Bernardo QuinteroCasos de Uso - Juan Bernardo Quintero
Casos de Uso - Juan Bernardo QuinteroRobert Rodriguez
 
Que son los editores WYSIWYG ? ,
Que son los editores WYSIWYG ? , Que son los editores WYSIWYG ? ,
Que son los editores WYSIWYG ? , Robert Rodriguez
 
Diagrama de actividades inscripcion, evaluacion, Asistencia
Diagrama de actividades inscripcion, evaluacion, AsistenciaDiagrama de actividades inscripcion, evaluacion, Asistencia
Diagrama de actividades inscripcion, evaluacion, AsistenciaRobert Rodriguez
 
Contenido de las paginas webs
Contenido de las paginas websContenido de las paginas webs
Contenido de las paginas websRobert Rodriguez
 
Análisis Microsoft Word 2010
Análisis Microsoft Word 2010Análisis Microsoft Word 2010
Análisis Microsoft Word 2010Robert Rodriguez
 
Mantenimiento Preventivo, Correctivo
Mantenimiento Preventivo, CorrectivoMantenimiento Preventivo, Correctivo
Mantenimiento Preventivo, CorrectivoRobert Rodriguez
 
Descripcion y analisis de los elementos del proyecto (desde el problema hasta...
Descripcion y analisis de los elementos del proyecto (desde el problema hasta...Descripcion y analisis de los elementos del proyecto (desde el problema hasta...
Descripcion y analisis de los elementos del proyecto (desde el problema hasta...Robert Rodriguez
 
Instalación de microsoft sql server 2005
Instalación de microsoft sql server 2005Instalación de microsoft sql server 2005
Instalación de microsoft sql server 2005Robert Rodriguez
 
Los atajos de teclado de windows7 guía completa en español
Los atajos de teclado de windows7  guía completa en españolLos atajos de teclado de windows7  guía completa en español
Los atajos de teclado de windows7 guía completa en españolRobert Rodriguez
 

Mais de Robert Rodriguez (20)

Modelo Entidad Relacion ,Base de datos
Modelo Entidad Relacion ,Base de datosModelo Entidad Relacion ,Base de datos
Modelo Entidad Relacion ,Base de datos
 
Diseño Logico de base de datos
Diseño Logico de base de datosDiseño Logico de base de datos
Diseño Logico de base de datos
 
Diseño Logico - Diseño de bases de datos relacionales
Diseño Logico - Diseño de bases de datos relacionalesDiseño Logico - Diseño de bases de datos relacionales
Diseño Logico - Diseño de bases de datos relacionales
 
Diseño Logico de Base de datos Relacionales
Diseño Logico de Base de datos RelacionalesDiseño Logico de Base de datos Relacionales
Diseño Logico de Base de datos Relacionales
 
Base de Datos, Diseño Comceptual , logico y Fisico
Base de Datos, Diseño Comceptual , logico y FisicoBase de Datos, Diseño Comceptual , logico y Fisico
Base de Datos, Diseño Comceptual , logico y Fisico
 
Teoria del modelado de objetos modificado
Teoria del modelado de objetos modificadoTeoria del modelado de objetos modificado
Teoria del modelado de objetos modificado
 
Modelado funcional casos de uso
Modelado funcional casos de usoModelado funcional casos de uso
Modelado funcional casos de uso
 
Que es Ingenieria del Software?,
Que es Ingenieria del Software?,Que es Ingenieria del Software?,
Que es Ingenieria del Software?,
 
Diseño logico de una base de datos
Diseño logico de  una base de datosDiseño logico de  una base de datos
Diseño logico de una base de datos
 
Casos de Uso - Juan Bernardo Quintero
Casos de Uso - Juan Bernardo QuinteroCasos de Uso - Juan Bernardo Quintero
Casos de Uso - Juan Bernardo Quintero
 
Que son los editores WYSIWYG ? ,
Que son los editores WYSIWYG ? , Que son los editores WYSIWYG ? ,
Que son los editores WYSIWYG ? ,
 
Diagrama de actividades inscripcion, evaluacion, Asistencia
Diagrama de actividades inscripcion, evaluacion, AsistenciaDiagrama de actividades inscripcion, evaluacion, Asistencia
Diagrama de actividades inscripcion, evaluacion, Asistencia
 
Contenido de las paginas webs
Contenido de las paginas websContenido de las paginas webs
Contenido de las paginas webs
 
Análisis Microsoft Word 2010
Análisis Microsoft Word 2010Análisis Microsoft Word 2010
Análisis Microsoft Word 2010
 
Mantenimiento Preventivo, Correctivo
Mantenimiento Preventivo, CorrectivoMantenimiento Preventivo, Correctivo
Mantenimiento Preventivo, Correctivo
 
Descripcion y analisis de los elementos del proyecto (desde el problema hasta...
Descripcion y analisis de los elementos del proyecto (desde el problema hasta...Descripcion y analisis de los elementos del proyecto (desde el problema hasta...
Descripcion y analisis de los elementos del proyecto (desde el problema hasta...
 
Tutorial Microsoft Access
Tutorial Microsoft AccessTutorial Microsoft Access
Tutorial Microsoft Access
 
Instalación de microsoft sql server 2005
Instalación de microsoft sql server 2005Instalación de microsoft sql server 2005
Instalación de microsoft sql server 2005
 
Los atajos de teclado de windows7 guía completa en español
Los atajos de teclado de windows7  guía completa en españolLos atajos de teclado de windows7  guía completa en español
Los atajos de teclado de windows7 guía completa en español
 
Manual de access 2010
Manual de access 2010Manual de access 2010
Manual de access 2010
 

Último

COMO SI EL RUIDO PUDIERA MOLESTAR 4TO SECUENCIA.docx
COMO SI EL RUIDO PUDIERA MOLESTAR 4TO SECUENCIA.docxCOMO SI EL RUIDO PUDIERA MOLESTAR 4TO SECUENCIA.docx
COMO SI EL RUIDO PUDIERA MOLESTAR 4TO SECUENCIA.docxAngeles Feu
 
sociales ciencias segundo trimestre tercero
sociales ciencias segundo trimestre tercerosociales ciencias segundo trimestre tercero
sociales ciencias segundo trimestre terceroCEIP TIERRA DE PINARES
 
GUÍA SIANET - Agenda - Tareas - Archivos - Participaciones - Notas.pdf
GUÍA SIANET - Agenda - Tareas - Archivos - Participaciones - Notas.pdfGUÍA SIANET - Agenda - Tareas - Archivos - Participaciones - Notas.pdf
GUÍA SIANET - Agenda - Tareas - Archivos - Participaciones - Notas.pdfNELLYKATTY
 
SIANET - GUÍA SOBRE COMO CREAR EVALUACIONES.pdf
SIANET  - GUÍA SOBRE COMO CREAR EVALUACIONES.pdfSIANET  - GUÍA SOBRE COMO CREAR EVALUACIONES.pdf
SIANET - GUÍA SOBRE COMO CREAR EVALUACIONES.pdfNELLYKATTY
 
Concurso de Innovación Pedagógica T3 FONDEP 2024 Ccesa007.pdf
Concurso de Innovación Pedagógica  T3  FONDEP 2024 Ccesa007.pdfConcurso de Innovación Pedagógica  T3  FONDEP 2024 Ccesa007.pdf
Concurso de Innovación Pedagógica T3 FONDEP 2024 Ccesa007.pdfDemetrio Ccesa Rayme
 
Los escritos administrativos, técnicos y comerciales
Los escritos administrativos, técnicos y comercialesLos escritos administrativos, técnicos y comerciales
Los escritos administrativos, técnicos y comercialeshanda210618
 
Tema 4 Rocas sedimentarias, características y clasificación
Tema 4 Rocas sedimentarias, características y clasificaciónTema 4 Rocas sedimentarias, características y clasificación
Tema 4 Rocas sedimentarias, características y clasificaciónIES Vicent Andres Estelles
 
1ro Programación Anual D.P.C.C ACTUALIZADO
1ro Programación Anual D.P.C.C ACTUALIZADO1ro Programación Anual D.P.C.C ACTUALIZADO
1ro Programación Anual D.P.C.C ACTUALIZADODJElvitt
 
Tecnología educativa en la era actual .pptx
Tecnología educativa en la era actual .pptxTecnología educativa en la era actual .pptx
Tecnología educativa en la era actual .pptxJulioSantin2
 
Programación Anual 2024 - CIENCIAS SOCIALES.docx
Programación Anual 2024  - CIENCIAS SOCIALES.docxProgramación Anual 2024  - CIENCIAS SOCIALES.docx
Programación Anual 2024 - CIENCIAS SOCIALES.docxJhordanBenitesSanche1
 
Semana Santa en Popayán para el año 2024
Semana Santa en Popayán para el año 2024Semana Santa en Popayán para el año 2024
Semana Santa en Popayán para el año 2024yaco173
 
Evaluacion Diagnostica Matematica 5to C1 Secundaria Ccesa007.pdf
Evaluacion Diagnostica Matematica 5to  C1 Secundaria Ccesa007.pdfEvaluacion Diagnostica Matematica 5to  C1 Secundaria Ccesa007.pdf
Evaluacion Diagnostica Matematica 5to C1 Secundaria Ccesa007.pdfDemetrio Ccesa Rayme
 
Escrito administrativo técnico y comerciales
Escrito administrativo técnico y comercialesEscrito administrativo técnico y comerciales
Escrito administrativo técnico y comercialesmelanieteresacontrer
 
Evaluacion Diagnostica Matematica 2do C2 Secundaria Ccesa007.pdf
Evaluacion Diagnostica Matematica 2do C2 Secundaria Ccesa007.pdfEvaluacion Diagnostica Matematica 2do C2 Secundaria Ccesa007.pdf
Evaluacion Diagnostica Matematica 2do C2 Secundaria Ccesa007.pdfDemetrio Ccesa Rayme
 
Presentación del tema: tecnología educativa
Presentación del tema: tecnología educativaPresentación del tema: tecnología educativa
Presentación del tema: tecnología educativaricardoruizaleman
 
La Gatera de la Villa nº 51. Revista cultural sobre Madrid..
La Gatera de la Villa nº 51. Revista cultural sobre Madrid..La Gatera de la Villa nº 51. Revista cultural sobre Madrid..
La Gatera de la Villa nº 51. Revista cultural sobre Madrid..La Gatera de la Villa
 
21 MARZO DIA INTERNACIONAL DOS BOSQUES.pdf
21 MARZO DIA INTERNACIONAL DOS BOSQUES.pdf21 MARZO DIA INTERNACIONAL DOS BOSQUES.pdf
21 MARZO DIA INTERNACIONAL DOS BOSQUES.pdfceeabarcia
 
La poesía del encarcelamiento de Raúl Zurita en el aula: una propuesta didáctica
La poesía del encarcelamiento de Raúl Zurita en el aula: una propuesta didácticaLa poesía del encarcelamiento de Raúl Zurita en el aula: una propuesta didáctica
La poesía del encarcelamiento de Raúl Zurita en el aula: una propuesta didácticaIGNACIO BALLESTER PARDO
 

Último (20)

COMO SI EL RUIDO PUDIERA MOLESTAR 4TO SECUENCIA.docx
COMO SI EL RUIDO PUDIERA MOLESTAR 4TO SECUENCIA.docxCOMO SI EL RUIDO PUDIERA MOLESTAR 4TO SECUENCIA.docx
COMO SI EL RUIDO PUDIERA MOLESTAR 4TO SECUENCIA.docx
 
sociales ciencias segundo trimestre tercero
sociales ciencias segundo trimestre tercerosociales ciencias segundo trimestre tercero
sociales ciencias segundo trimestre tercero
 
GUÍA SIANET - Agenda - Tareas - Archivos - Participaciones - Notas.pdf
GUÍA SIANET - Agenda - Tareas - Archivos - Participaciones - Notas.pdfGUÍA SIANET - Agenda - Tareas - Archivos - Participaciones - Notas.pdf
GUÍA SIANET - Agenda - Tareas - Archivos - Participaciones - Notas.pdf
 
SIANET - GUÍA SOBRE COMO CREAR EVALUACIONES.pdf
SIANET  - GUÍA SOBRE COMO CREAR EVALUACIONES.pdfSIANET  - GUÍA SOBRE COMO CREAR EVALUACIONES.pdf
SIANET - GUÍA SOBRE COMO CREAR EVALUACIONES.pdf
 
EL PROCESO DE INVESTIGACIÓN CUALITATIVA. ENFERMERÍA
EL PROCESO DE INVESTIGACIÓN CUALITATIVA. ENFERMERÍAEL PROCESO DE INVESTIGACIÓN CUALITATIVA. ENFERMERÍA
EL PROCESO DE INVESTIGACIÓN CUALITATIVA. ENFERMERÍA
 
Concurso de Innovación Pedagógica T3 FONDEP 2024 Ccesa007.pdf
Concurso de Innovación Pedagógica  T3  FONDEP 2024 Ccesa007.pdfConcurso de Innovación Pedagógica  T3  FONDEP 2024 Ccesa007.pdf
Concurso de Innovación Pedagógica T3 FONDEP 2024 Ccesa007.pdf
 
Los escritos administrativos, técnicos y comerciales
Los escritos administrativos, técnicos y comercialesLos escritos administrativos, técnicos y comerciales
Los escritos administrativos, técnicos y comerciales
 
Tema 4 Rocas sedimentarias, características y clasificación
Tema 4 Rocas sedimentarias, características y clasificaciónTema 4 Rocas sedimentarias, características y clasificación
Tema 4 Rocas sedimentarias, características y clasificación
 
1ro Programación Anual D.P.C.C ACTUALIZADO
1ro Programación Anual D.P.C.C ACTUALIZADO1ro Programación Anual D.P.C.C ACTUALIZADO
1ro Programación Anual D.P.C.C ACTUALIZADO
 
Tecnología educativa en la era actual .pptx
Tecnología educativa en la era actual .pptxTecnología educativa en la era actual .pptx
Tecnología educativa en la era actual .pptx
 
Programación Anual 2024 - CIENCIAS SOCIALES.docx
Programación Anual 2024  - CIENCIAS SOCIALES.docxProgramación Anual 2024  - CIENCIAS SOCIALES.docx
Programación Anual 2024 - CIENCIAS SOCIALES.docx
 
Semana Santa en Popayán para el año 2024
Semana Santa en Popayán para el año 2024Semana Santa en Popayán para el año 2024
Semana Santa en Popayán para el año 2024
 
Evaluacion Diagnostica Matematica 5to C1 Secundaria Ccesa007.pdf
Evaluacion Diagnostica Matematica 5to  C1 Secundaria Ccesa007.pdfEvaluacion Diagnostica Matematica 5to  C1 Secundaria Ccesa007.pdf
Evaluacion Diagnostica Matematica 5to C1 Secundaria Ccesa007.pdf
 
Escrito administrativo técnico y comerciales
Escrito administrativo técnico y comercialesEscrito administrativo técnico y comerciales
Escrito administrativo técnico y comerciales
 
Evaluacion Diagnostica Matematica 2do C2 Secundaria Ccesa007.pdf
Evaluacion Diagnostica Matematica 2do C2 Secundaria Ccesa007.pdfEvaluacion Diagnostica Matematica 2do C2 Secundaria Ccesa007.pdf
Evaluacion Diagnostica Matematica 2do C2 Secundaria Ccesa007.pdf
 
Presentación del tema: tecnología educativa
Presentación del tema: tecnología educativaPresentación del tema: tecnología educativa
Presentación del tema: tecnología educativa
 
La Gatera de la Villa nº 51. Revista cultural sobre Madrid..
La Gatera de la Villa nº 51. Revista cultural sobre Madrid..La Gatera de la Villa nº 51. Revista cultural sobre Madrid..
La Gatera de la Villa nº 51. Revista cultural sobre Madrid..
 
21 MARZO DIA INTERNACIONAL DOS BOSQUES.pdf
21 MARZO DIA INTERNACIONAL DOS BOSQUES.pdf21 MARZO DIA INTERNACIONAL DOS BOSQUES.pdf
21 MARZO DIA INTERNACIONAL DOS BOSQUES.pdf
 
SITUACIÓN ACTUAL DE LA INVESTIGACIÓN. ENFERMERÍA
SITUACIÓN ACTUAL DE LA INVESTIGACIÓN. ENFERMERÍASITUACIÓN ACTUAL DE LA INVESTIGACIÓN. ENFERMERÍA
SITUACIÓN ACTUAL DE LA INVESTIGACIÓN. ENFERMERÍA
 
La poesía del encarcelamiento de Raúl Zurita en el aula: una propuesta didáctica
La poesía del encarcelamiento de Raúl Zurita en el aula: una propuesta didácticaLa poesía del encarcelamiento de Raúl Zurita en el aula: una propuesta didáctica
La poesía del encarcelamiento de Raúl Zurita en el aula: una propuesta didáctica
 

Teoria del modelado de objetos otros diagramas actividad despliegue

  • 1. 1 Paquetes • Elemento organizativo • Puede contener elementos de cualquier tipo. • Un elemento es exclusivo a un paquete. • Posibilidad de anidar paquetes. Modelo Modelo + Producto + CarroCompra + Comercio
  • 2. 2 Paquetes • Un paquete bien estructurado debe: – ser cohesivo – estar poco acoplado – poco anidamientos – conjunto equilibrado de elementos
  • 3. 3 Importación/Exportación en paquetes • Los paquetes permiten controlar la complejidad del manejo de un gran número de abstracciones, controlando los accesos mediante la importación. • La parte pública de un paquete son sus exportaciones. • Las partes públicas son visibles en los paquetes que importan al paquete contenedor. • La importación no es transitiva. • Los paquetes anidados pueden ver todo lo que ven los paquetes que los contienen.
  • 4. Servidor + BaseDeDatos + ServicioDeRegistro Cliente + FormularioPedido + FormularioDeSeguimiento - Pedido GUI + Ventana + Formulario # GestorEventos Politicas + ReglasPedidos + GUI:Ventana import import
  • 5. 5 Generalización de Paquetes WindowsGUI + GUI:Ventana + Formulario # GUI:GestorEventos + VBForm GUI + Ventana + Formulario # GestorEventos MacGUI
  • 6. 6 Uso de los paquetes • Agrupar elementos, normalmente del mismo tipo, para manejarlos en conjunto. Paquete “Clases e interfaces del modelo” Paquete “Interfaces de usuario” Paquete “Servicios base de datos” • Un modelo es un paquete que incluye todos los elementos que constituyen una particular vista del sistema modelado.
  • 7. 7 Sistema, modelo, vista, diagrama • Un sistema es aquello que se está desarrollando y para lo que se crean modelos. • Un subsistema es una parte de un sistema. • Un modelo es una abstracción de un sistema que ayuda a comprenderlo. • Una vista es una proyección de la estructura y organización de un modelo del sistema, centrada en algún aspecto. • Un diagrama es una representación de un conjunto de elementos de un modelo.
  • 8. 8 Vistas UML Vista de Diseño Vista de Implementación Vista de Procesos Vista de Despliegue Vista de casos de uso vocabulario funcionalidad ensamblado gestión conf. topología entrega distribución instalación Funcionamiento escalabilidad rendimiento comportamiento
  • 9. 9 Vistas UML Vista de Diseño Vista de Implementación Vista de Procesos Vista de Despliegue Vista de casos de uso clases interfaces colaboraciones componentes nodosclases activas casos de uso
  • 10. 10 Vistas UML Vista de Diseño Vista de Implementación Vista de Procesos Vista de Despliegue Vista de casos de uso Diagramas de clase Diagramas de interacción Diagramas de estado Diagramas de componentes Diagrama de interacción Diagramas de estado Diagramas de despliegue Diagrama de interacción Diagramas de estado Diagramas de casos de uso Diagramas de clase Diagramas de interacción Diagramas de estado
  • 12. 12 Diagrama de Objetos :Universidad d2:Departam ento d2:Departam ento d ire cto r:Pro fe so r :P rofes or :A signatur a
  • 13. 13 Enlaces y Asociaciones • Un enlace es : – una conexión semántica entre objetos. – una instancia de una asociación. – un camino por el cual enviar un mensaje Persona calcularCompensacion() asignar() Empresa *1..* +patron+empleado *1..* p:Persona :Em presa 1: asignar(desarrollo) mensaje enlace
  • 14. 14 Interacciones y Mensajes • Interacción: comportamiento que comprende un conjunto de mensajes intercambiados entre un conjunto de objetos dentro de un contexto para lograr un propósito. • Mensaje: especificación de una comunicación entre objetos que transmite información, con la expectativa de desencadenar una actividad.
  • 15. 15 Modelado del comportamiento • Se describe cómo los objetos colaboran entre sí para realizar cierta actividad. • Se expresa mediante los diagramas de interacción: – Diagramas de Secuencia y Diagramas de Colaboración (de Comunicación en UML 2.0). • También se describe las máquinas de estado que caracterizan los objetos – Diagramas de estado – Diagramas de actividades
  • 16. 16 Diagramas de Interacción • Describen una interacción. • Dos tipos: Diagramas de Secuencia y Colaboración • Diagramas de Secuencia: – Destacan la ordenación temporal de los mensajes • Diagramas de Colaboración: – Destacan la organización estructural de los objetos participantes. • Equivalencia semántica
  • 17. 17 Diagramas de Secuencia • Representan escenarios. • Incluye: – Objetos y su línea de tiempo – Mensajes : argumentos y self-delegation – Información de control: condiciones y marcas de iteración – Indicar el objeto devuelto por el mensaje: return (añadirlos sólo cuando ayuden a clarificar la interacción) – Especificar procesos concurrentes: focos de control
  • 18. 18 Sincronización Envío de mensaje simple: – Un solo hilo de ejecución – El objeto activo pasa el control al objeto pasivo Otro objetoUn cliente : Envío simple
  • 19. 19 Sincronización Envío de mensaje síncrono: – Sólo se desencadena la operación cuando el servidor acepta el mensaje – El cliente se bloquea hasta que el servidor lo acepta o rechaza Otro objetoUn cliente : Envío síncrono
  • 20. 20 Sincronización Envío de mensaje asíncrono: – Un mensaje asíncrono no interrumpe la ejecución del cliente – El cliente envía el mensaje sin saber cuándo ni si se llevará a cabo Otro objetoUn cliente : Envío asíncrono
  • 21. Diagrama de secuencia Un objeto puede enviarse a sí mismo un mensaje: a m ens aje reflex ivo Puede representar también la entrada por parte del objeto en cierta actividad de más bajo nivel
  • 22. Diagrama de secuencia • Gráficamente también se puede indicar cuándo el mensaje es para crear el objeto (va dirigido al rectángulo del objeto o etiquetado con new) o para destruirlo (va dirigido a la línea del objeto pero el final de la flecha es una cruz)
  • 23. Diagrama de secuencia Normalmente no es necesario indicar el retorno del control, cuando el envío es síncrono: a b E l retorno se considera im plíc ito cuando el envío es síncrono
  • 24. Diagrama de secuencia En el caso asíncrono el retorno, si existe, se debe representar: a : aa b : aa La flecha discontinua indica retorno del control Media punta de flecha indica mensaje asíncrono (desde UML 1.3; en UML 1.5 ya no se distingue, aunque se acepta)
  • 25. Tipos de Control El Diagrama de Secuencia refleja de manera indirecta las opciones de control Un control centralizado tiene una forma como esta:
  • 26. Tipos de control Un control descentralizado tiene una forma como ésta:
  • 27. Estructuras de control Podemos representar iteraciones en el envío de mensajes mientras, p.e., se cumpla una condición: W hile X Loop end Loop
  • 28. Estructuras de control La iteración puede expresarse también como parte del mensaje: *[c ondic ión] M ens aje
  • 29. Estructuras de control Las bifurcaciones condicionales pueden representarse de esta forma: If condición else end if
  • 30. Diagrama de secuencia Diagrama de Secuencia c:Comprador :Transaccion p:ServidorWeb <<create>> asignarrAcciones asignarValores exito <<destroy>> asignarValorestiempo Línea de vida del objeto Foco de control La flecha discontínua indica un retorno del control Foco de control:Muestra el periodo de tiempo que un objeto está realizando una acción (períodos de actividad del objeto). La parte superior indica cuándo se inicia la acción y la inferior cuándo se termina (puede estar marcada con un mensaje de respuesta -return-, indicando que se devuelve el control al objeto destino -se indica con flecha discontinua-)
  • 31. 31 Diagrama de Colaboración c:Cliente :Transac cion p:Proxy ODBC 1: <<create>> 2: establecerAcciones 3: establecerValores 5: exito 4: establecerValores 6: <<destroy>>
  • 33. 33 Diagrama de Colaboración a:Ay uda Planificacion c:Cliente :A gente Billetes 3: calcularRuta 1: <<create>> 2: establecerItinerario(i) 5: <<destroy>> 4: ruta 6: notific ar
  • 34. 34 Diagramas de Secuencia PedidoItem :Interface Entrada Pedido :Pedido :LineaDe Pedido :Item ItemEntregado preparar *preparar hayStock:=comprobar [hayStock] eliminar pedir?:=necesarioPedir [pedir?]<<create>> [hayStock] <<create>>
  • 35. 35 Diagramas de Colaboración :Interface Entrada Pedido :Pedido :LineaDe Pedido :Item Pedido Item Item Entregado 5: pedir?:=necesarioPedir 1: preparar 2: *preparar 3: hayStock:=comprobar 4: [hayStock] eliminar 7: 8: [hayStock] <<create>> 6: [pedir?]<<create>>
  • 36. 36 Uso de los diagramas de interacción • Modelado del aspecto dinámico. • Modelado del flujo de control que caracteriza el comportamiento de un sistema: – casos de uso – colaboraciones – patrones – frameworks – operaciones
  • 37. 37 Diagrama de Secuencia (Caso de uso) : Interfaz Compra: Cliente : CarroCompra : Producto iniciarCompra() nuevoCarroCompra(cliente) decremStock(cantidad) seleccProducto(cantidad) cargarProd(cliente,prod,cantidad) obtenerDescripcionDe(prod) confirmarCompra() confirmarCompraDe(cliente) Realizar para cada producto incluido en el carro de compra
  • 38. 38 Diagrama de Colaboración Caso de Uso) : Interfaz Compra : Cliente : Carro Compra : Producto 4: obtenerDescripcionDe(prod) 2: nuevoCarroCompra(cliente) 5: cargarProd(cliente,prod,c antidad) 7: confirmarCompraDe(cliente) 1: iniciarCompra() 3: seleccProducto(cantidad) 6: confirmarCompra() 8: decremS toc k(c antidad)
  • 39. 39 :OrderManager: Technical Responsible : Launch Manufacturing GUI :EvaluatedOrders o : Order : Product : WorkOrder: OrderLine selectOrder() selectOrder(cod) o:=find(cod) launchManufacturing() launchManufacturing(cod) launch manufacturing() *generateWO() tpl:=getTemplate() createWO(tpl) Diagrama de Secuencia
  • 40. 40 Escenario de un proceso de negocio traveler : Employee authorizer : Employee bookkeeper : Employee paymaster : Employee travelPermissionRequest() travelPermission() sendExpenseReport(anExpRep) expenseReportOk(anE xpRep) pay Reques t(aTraveler)
  • 41. 41 Escenario de un proceso de negocio : JefeTecnico: Cliente : Comercial : JefeProduccion darCursoPedido() estudiarPedido() * analizarFabricacionProducto() informarAnalisisPedido() planificarFabricacion() acceptarPedido()
  • 43. 43 Patrón Observer : Subject one : Observer Update( ) SetState( ) Notify( ) GetState( ) another : Observer Update( ) GetState( )
  • 44. 44 Patrón Observer : Subject one : Observer 2: Notify( ) another : Observer 1: SetState( ) 4: GetS tate( ) 3: Update( ) 5: Update( )6: GetS tate( )
  • 46. 46 Colaboración : ClienteDeGestor : Gestor : FabricaDeEditor : ObjetoInformacion : Editor obtenerEditorPara(objInfo) obtenerInterfazSoportada() s oportaInterfaz (nombreInterfaz) crearEditorCon(objInfo) Crear&IniciarCon(objInfo)
  • 47. 47 Caso de Uso (Nivel alto de abstracción) :ReceptorPedido : Cliente :RealizacionPedido enviarPedido tramitarP edido confirmarPedido
  • 48. 48 Caso de Uso (Nivel más bajo de abstracción) : Cliente :ReceptorPedidos :AgenteTarjeta Credito :RealizacionPedido :A genteFac turacion enviarPedido procesarTarjeta tramitarPedido confirmarPedido emitirFactura
  • 49. 49 Casos de Uso y Escenarios Caso de Uso Buscar Pedido 1. Se inicia al seleccionar el usuario la opción “Buscar Pedido”. 2. El sistema presenta la ventana “Buscar Pedido”. 3. El usuario introduce un ID de un pedido 4. El usuario arranca la búsqueda 5. El sistema realiza una búsqueda en la BD de pedidos. 6. El sistema visualiza datos pedido.
  • 50. :Interfaz Cancelar Pedido :Interfaz Buscar Pedido : Base Datos: Usuario Encontrar Pedido () visualizar () setIDPedido (IDPedido) buscarPedido () p:=getPedido (IDPedido) visualizarPedido (p)
  • 52. 52 Diagramas de Secuencia vs. Diagramas de Colaboración • Equivalencia semántica • Simples para comportamientos simples. • Si hay mucho comportamiento condicional, usar diferentes escenarios. • Diagramas de secuencia muestran mejor el orden en que se ejecutan los mensajes • Diagramas de colaboración muestran claramente los objetos con que interactúa un determinado objeto.
  • 53. 53 Diagramas de Actividades • Muestran un flujo de actividades. • Es un caso especial de máquina de estados. • Incluye: – estados actividad y estados acción – transiciones – objetos • Una actividad realiza alguna acción que produce algún cambio en el sistema o retorna un valor.
  • 54. 54 Estados Acción y Estados Actividad • Un estado acción no se puede descomponer, representa una computación atómica. • Un estado actividad no es atómico, se compone de otros estados acción y actividad. • Al entrar se ejecuta la acción o actividad, al terminar el flujo de control pasa a la siguiente acción o actividad. • Misma notación Procesar Pedido
  • 55. 55 Transiciones Planificar proceso Asignar tareas estado final estado inicial transiciones
  • 56. 56 Bifurcación Planificar proceso Asignar tareas [materiales disponibles] Volver a planificar [materiales no disponibles]
  • 57. 57 División y Unión Preparar conversación Limpieza Emitir audio Gesticular Descomprimir Mover boca división unión
  • 58. Solicitar Producto Procesar Pedido Extraer Articulos Enviar Pedido Recibir Producto Facturar al cliente Pagar Factura Cerrar Pedido
  • 59. Cliente Ventas Almacen Solicitar Producto Procesar Pedido Extraer Articulos Enviar Pedido Recibir Producto Facturar al cliente Pagar Factura Cerrar Pedido Calles
  • 60. Cliente Ventas Almacen Solicitar Producto Procesar Pedido Extraer Articulos Enviar Pedido Recibir Producto Facturar al cliente Pagar Factura Cerrar Pedido o: Pedido [en progreso] o: Pedido [completado] b: Factura [impagada]
  • 61. 61 Emitir billete Pasajero Vendedor Airline Ejemplo Solicitar pago Reservar plazas Confirmar plaza reservadaPagar pasaje Informar alternativas y precios Verificar existencia vuelo Dar detalles vuelo Solicitar pasaje Seleccionar vuelo
  • 62. Rellenar Pedido Cursar pedido Notificar aceptacion de pedido Fin OK Notificar rechazo de pedido Fin KO Analizar viabilidad ¿Viable ?[ NO ] Planificar produccion [ SI ] : JefeProduccion: JefeTecnico: Comercial: Cliente p:Pedido [propuesto] p:Pedido [rechazado] p:Pedido [aceptado] :Orden de Trabajo [pendiente] :Plantilla de Produccion :Catalogo :Producto Especial p:Pedido [en_evaluacion] p:Pedido [evaluado] :Plantilla de Produccion Ordenar fabricacion
  • 63. 63 Utilidad de los diagramas de actividades • Modelado de flujos de trabajo (workflow) como son los procesos de negocio (business processes). • Se puede asociar a cualquier elemento de modelado, pero lo más normal es asociarlo a una operación: diagrama de flujo de las acciones.
  • 64. Diagramas de Estados (Statecharts) • Los statecharts representan máquinas de estados (autómatas de estados finitos), con estados y transiciones • Los Statecharts de UML son básicamente los de David Harel, extendidos con características OO • Puede ser visto como un grafo de estados conectados por transiciones etiquetadas
  • 65. Statecharts Modelan los aspectos dinámicos del sistema Cada objeto sigue el comportamiento descrito en el Statechart asociado a su clase Cada objeto está en un estado en cierto instante El estado está caracterizado parcialmente por los valores de los atributos del objeto Los Statecharts de UML son deterministas La transición entre estados es instantánea y se debe a la ocurrencia de eventos La suposición básica es que una máquina de estados procesa un evento cada vez y termina con todas las consecuencias del evento antes de procesar otro. Si ocurren dos eventos simultáneamente se procesan como si se hubieran producido en cualquier orden, sin pérdida de generalidad
  • 66. 66 Eventos • Un evento es un acontecimiento que ocupa un lugar en el tiempo y espacio. • Un evento es un estímulo que dispara una transición en una máquina de estados. • Eventos externos vs. Eventos internos. • Tipos de eventos: – Señales (excepciones) – Llamadas – Paso de tiempo – Cambio de estado
  • 67. Tipos de eventos llamada: la recepción de una petición para invocar una operación. Normalmente un evento de llamada es modelado como una operación del objeto receptor, manejado por un método del receptor y se implementa como una acción o transición de la máquina de estados señal: la recepción de una señal, que es una entidad a la que se ha dado nombre explícitamente (clase estereotipada), prevista para la comunicación explícita - y asíncrona- entre objetos. Es enviada por un objeto a otro objeto o conjunto de objetos. Las señales con nombre que puede recibir un objeto se modelan designándolas en un compartimento extra de la clase de ese objeto. Normalmente una señal es manejada por la máquina de estados del objeto receptor y puede disparar una transición en la máquina de estados tiempo: representa el paso del tiempo (ocurrencia de un tiempo absoluto respecto de un reloj real o virtual o el paso de una cantidad de tiempo dada desde que un objeto entra en un estado). Palabra clave after: after (2 segundos); after 1 ms desde la salida de devInactivo cambio: evento que representa un cambio en el estado o el cumplimiento de alguna condición. Palabra clave when, seguida de una expresión booleana, que puede ser de tiempo o de otra clase: when (hora = 11:30); when ( altitud < 1000)
  • 68. Tipos de eventos Manual Automático iniciarPilotoAutomático (normal) • Evento de llamada (se representa igual que el de señal) evento parámetro • Eventos de tiempo y de cambio Inactivo Activo after (2 segundos) / cortarConexión() when (11:30PM) / autoTest() evento de cambio evento de tiempo
  • 70. 70 Estados • Un estado es una situación en la vida de un objeto en la que satisface cierta condición, realiza alguna actividad o espera algún evento. • Elementos de un estado – Nombre – Acciones entrada/salida – Transiciones internas – Subestados – Eventos diferidos
  • 71. 71 Estados Rastreando entry/ activarModo(enRastreo) exit / activarModo(noRastreo) nuevoObjetivo/rastreador.adquirir do / seguirObjetivo autotest / defer acción entrada acción salida transición interna evento diferido acción entrada actividad
  • 72. Estado inicial • Se trata de un pseudoestado que indica el punto de partida por defecto para una transición cuyo destino es el límite de un estado compuesto • El estado inicial del estado de nivel más alto representa la creación de una nueva instancia de la clase • Sólo puede haber un estado inicial (directamente) dentro de cada estado compuesto Y entry/b X Z estado inicial Transición al estado inicial e/a f/d /c No se permiten disparadores de evento, sí acciones Si estando en X se produce e, la transición pasa al estado Y. Se ejecuta la acción de entrada b y el estado inicial queda activado. La transición saliente se dispara inmediatamente, ejecutando la acción c y pasando al estado Z. Si estando en X se produce f, se ejecuta d, se ejecuta b, al entrar a Y, y se pasa a Z, sin ejecutar c, pues el estado inicial ya no está implicado Primer estado propiamente dicho Dueño del estado inicial Transición directa a un estado interior
  • 73. Estado final • Estado especial dentro de un estado compuesto que, cuando está activo, indica que la ejecución del estado compuesto ha terminado y que una transición de finalización que sale del estado compuesto está activada. • Un estado final no es un pseudoestado. Puede ser activado por un periodo de tiempo, a diferencia del inicial que transita inmediatamente a su sucesor, p.ej., mientras espera la terminación de otros subestados concurrentes en el mismo estado compuesto • Las transiciones entrantes son transiciones normales X eY Z estado final El evento e causa la transición al estado final, que causa la transición de finalización hacia Z
  • 74. Estado final • Sólo puede ocurrir un estado final (directamente) dentro de un estado compuesto. El símbolo de estado final puede repetirse dentro de un estado, pero cada copia representa el mismo estado final. • Si un objeto alcanza su estado final de nivel superior, la máquina de estados termina y se destruye el objeto • Es posible que no haya estado final, indicando una actividad continua (común por ejemplo en sistemas empotrados)
  • 75. 75 Transiciones • Una transición de un estado A a un estado B, se produce cuando se origina el evento asociado y se satisface la condición especificada, en cuyo caso se ejecuta la acción de salida de A, la acción de entrada a B y la acción asociada a la transición. • Elementos de una transición: – Estados origen y destino – Evento de disparo – Condición de guarda – Acción
  • 76. Elementos de una transición estado origen • la transición se disparará si, estando en el estado origen, se produce el evento de disparo y si la condición de guarda, si la hay, se satisface estado destino • estado activo tras completarse la transición evento de disparo. • cuando se produce un evento, afecta a todas las transiciones que lo contienen en su etiqueta. Todas las apariciones de un evento en la misma máquina de estados deben tener la misma signatura condición de guarda • expresión booleana. Si es falsa, la transición no se dispara, y si no hay otra transición etiquetada con el mismo evento que pueda dispararse, éste se pierde acción • computación atómica ejecutable. Puede incluir llamadas a operaciones sobre el objeto que contiene la máquina de estados (o sobre otros visibles), creación o destrucción de objetos, o envío de una señal a otro objeto
  • 77. Las condiciones o guardas permiten condicionar la transición: a b Eve nto[ condición ] Guardas en una transición
  • 78. Acciones en una transición Podemos especificar la ejecución de una acción como consecuencia de la transición: a b Evento[ condición ] / acción Dicha acción también se considera instantánea Acción: computación atómica ejecutable que produce un cambio en el estado del modelo o que devuelve un valor. Puede ser realizada mediante el envío de un mensaje a un objeto provocando la modificación de un enlace o del valor de un atributo en un objeto. Puede incluir llamadas a operaciones (sobre el objeto que contiene la máquina de estados, así como sobre otros objetos visibles), creación o destrucción de objetos, o el envío de una señal a un objeto
  • 79. Podemos especificar el envío de un evento a otro objeto como consecuencia de la transición: a b Evento( arg1, arg2 )[ condición ] / ^otro_objeto.evento(arg2) Acciones en una transición
  • 80. 80 Máquina de estados • Especifica la secuencia de estados por las que pasa un objeto a lo largo de su vida en respuesta a eventos, junto con sus respuestas a esos eventos. • Útil si las instancias de una clase tienen un comportamiento que depende de su historia o que deben responder a eventos externos: objetos reactivos. • Se representa mediante un diagrama de estados.
  • 81. Asociado a la clase Persona: en el paro en activo jubilado contratar perder empleo jubilarse jubilarse Ejemplo de Statechart transición estado estado final estado inicial
  • 82. Ejemplo de Statechart Transiciones simples y complejas Close Open Background Selected ReadyFor Writing Disabled Enabled Position Visualisation
  • 83. autotransición Buscando Rastreando Configuración Acoplamiento ruido evento de disparo transición sin disparador: (denota una transición final: que se dispara automática-mente cuando el estado origen termina su actividad) contactar after(2 segundos) / send c.estaActivo envío de señalevento de tiempo objetivoEn(p) [representaAmenaza] / t.añadirObjetivo(p) evento de disparo con parámetros condición de guarda acción Inactivo
  • 84. Pendiente de aceptación No aceptada Pendiente de envío a factoría En realización Realizada Finaliza S.A.D. Modificar hoja Administrador rechaza hoja Administrador acepta hoja Modificación por pedido urgente Envío a factoría Hojar rutas realizada
  • 85. Inicio Pendiente de envío a Bualgas Pendiente de análisis Viable AprobadoAsignado a Hoja de Rutas Pendiente de realización Realizado Rechazado Pendiente de aprobación No realizado Envío a Bualgas Factible[ Analizado ] Modificar hoja Administrador rechaza hoja Finaliza S.A.D Modificar hoja Envío a factoría Realizado[ Hoja Rutas realizada ] No factible[ Analizado ] Comunicacion de Rechazo a Central Envío a jefe Aprobado[ Estudiado ] No aprobado[ Estudiado ] No realizado[ Hoja Rutas realizada ] Aprobado
  • 87. 87 Subestados secuenciales Activo Chequeando Do/chequeo Esperando Enviando Do/Iniciar_ entrega Siguiente_item [No todo items chequeado] [Todo item chequeado y disponible] Item Recibido [todo item disponible] [Todo item chequeado y alguno no disponible] Item Recibido [algún item no disponible] Cancelado Entregado cancelado
  • 89. 89 Componentes • Un componente es una parte física y reemplazable de un sistema, que conforma con un conjunto de interfaces y proporciona su implementación. • Modela artefactos tales como: ejecutables, bibliotecas, tablas, ficheros, documentos,.. • Representa el empaquetamiento físico de elementos lógicos tales como clases, interfaces,.. • Residirán en los nodos del sistema
  • 91. 91 Componentes explorador.java arbol.java El componente arbol.java puede ser reemplazado por otro que proporcione la interfaz JerarquíaElementos. JerarquíaElementos Estereotipos: executable, library, file, table, document
  • 92. 92 Tipos de componentes • Despliegue – Necesarios y suficientes para formar un sistema ejecutable: librerías dinámicas(dll), ejecutables (exe),.. • Productos del trabajo – Permanecen al final del proceso de desarrollo: archivos código fuentes, ficheros de datos,.. – Con ellos se crean los componentes de despliegue • De ejecución – Se crean durante la ejecución: objeto COM, instanciado a partir de una dll.
  • 93. 93 Diagrama de Componentes • Modelado de ejecutables y bibliotecas • Modelado de código fuente • Modelado de una API
  • 95. 95 Ejemplo Control y Análisis Comm Acceso a BD Comm Rutinas de Coneccion Comm Interfaz de Terminal Comm Gestión de Cuentas Comm
  • 96. 96 Nodos • Un nodo es un elemento físico que existe en tiempo de ejecución y representa un recurso computacional que puede tener memoria y capacidad de procesamiento. • Los componentes se ejecutan en nodos • Los nodos representan el despliegue físico de los componentes.
  • 97. 97 Diagramas de Despliegue • Muestra la configuración de los nodos que participan en la ejecución y de los componentes que residen en los nodos. • Incluye nodos y arcos que representan conexiones físicas entre nodos. • Modelado de sistemas empotrados, sistemas cliente- servidor, sistemas distribuidos.
  • 98. 98 Diagrama de Despliegue servidor Unidad RAID Consola <<RS-232>> terminal <<10-T-Ethernet>>
  • 100. 100 Colaboraciones • Sociedad de clases, interfaces y otros elementos que colaboran para proporcionar un comportamiento cooperativo mayor que la suma de los comportamientos de los elementos. • Parte estructural (diagrama de clases) y parte de comportamiento (diagrama de interacción).
  • 101. 101 Colaboraciones • El núcleo de la arquitectura de un sistema está formado por un conjunto de colaboraciones que representan las decisiones de diseño más importantes. • Un sistema orientado a objetos bien estructurado se compone de un conjunto relativamente pequeño de colaboraciones. • Modelado de un caso de uso, operación o mecanismo (patrón o framework)
  • 102. 102 Casos de uso y Colaboraciones Hacer Pedido Gestión Pedidos caso de uso colaboración realización
  • 103. 103 Gestor Documentos (Parte estática) FabricaDeEditor Editor 1..1 1..1 1..1 1..1 especifica Gestor 1..*1..1 1..*1..1 ObjetoInformacion 1..*1..* 1..*1..* editado con ClienteDeGestor 1..11..* 1..11..* 1..* 0..* 1..* 0..* necesita editar
  • 104. 104 Gestor Documentos (Comportamiento) Crear&IniciarCon(objInfo) : ClienteDeGestor : Gestor : FabricaDeEditor : ObjetoInformacion : Editor obtenerEditorPara(objInfo) obtenerInterfazSoportada() soportaInterfaz(nombreInterfaz) crearEditorCon(objInfo)
  • 106. 106 Patrón de diseño (Parte Estática) Observer Update() Subject subjectState Attach() Detach() Notify() 1..*1..1 1..* +observers 1..1 ConcreteSubject subjectState getState() setState() ConcreteObserver observerState update() +subject observerState= subject->getState() for all o in observers {o->update}
  • 107. 107 Patrón de diseño (Parte dinámica) : Subject one : Observer Update( ) SetState( ) Notify( ) GetState( ) another : Observer Update( ) GetState( )
  • 108. OCL (Object Constraint Language) • OCL puede ser usado por UML y otros lenguajes para especificar restricciones, expresiones de navegación, expresiones booleanas, consultas y otras expresiones incluidas en sus modelos. • Lenguaje “formal” (más bien “semiformal”) para expresar restricciones libres de efectos colaterales. • Las expresiones OCL no cambian el estado del sistema. No está destinado a escribir acciones o código ejecutable • OCL es un lenguaje tipado. • Desarrollado por Joe Warmer dentro de IBM.
  • 109. Uso de OCL • OCL puede ser usado con distintos fines: – Para especificar invariantes sobre clases y tipos en el modelo de clases. – Para especificar pre y post-condiciones sobre operaciones y métodos. – Para describir guardas (en statecharts y otros elementos). – Como lenguaje de navegación. – Para especificar restricciones sobre operaciones. • OCL es utilizado también para especificar la semántica de UML.
  • 110. (tomado de la documentación de UML v1.4) 1
  • 111. OCL. Self y context; Invariantes • Cada expresión OCL se escribe en el contexto de una instancia de un tipo específico. Se usa self para referirse a la instancia contextual. Por ejemplo, si el contexto es Company, self se refiere a una instancia de Company. • Ejemplo: context Company inv: self.numberOfEmployees > 50 Si el contexto es claro, se puede suprimir self. También se puede representar de forma alternativa con un nombre distinto como en: context c : Company inv:c.numberOfEmployees > 50
  • 112. OCL. Pre-, Post- condiciones de una operación • Se usan las etiquetas ‘pre’ y ‘post’ antes de especificar las pre-y post-condiciones, que además pueden tener un nombre (resultOK). La declaración de operación, con sus parámetros, sigue a context y al tipo al que pertenece. • self se referirá al objeto sobre el que se llama la operación • result denota el resultado de la operación, si lo hay. • Se pueden usar los nombres de los parámetros (param1…). context Typename::operationName(param1 : Type1, ... ): ReturnType pre parameterOk: param1 > ... post resultOk: result = ...
  • 113. Tipos básicos y predefinidos • Tipos básicos: • Boolean, Integer, Real y String. • Se complementan con: Collection, Set, Bag y Sequence así como los de Enumeration, OclExpression, OclType, OclState y OclAny
  • 114. Tipos predefinidos • Tipos Básicos: Existen una serie de tipos básicos predefinidos (y operaciones sobre ellos) en OCL, que son: Boolean, Integer, Real, String. • Collection, Set, Bag y Sequence se consideran también tipos básicos
  • 115. Propiedades: Atributos Ejemplo: la edad de una Persona se escribe como self.age: context Person inv: self.age > 0 El valor de la subexpresión self.age es el valor del atributo age sobre el objeto self. El tipo de esta subexpresión es el tipo del atributo age (en este caso tipo básico Integer) El invariante de arriba está expresando que “la edad de una persona es siempre mayor que cero”
  • 116. Propiedades: Operaciones Ejemplo: un objeto persona tiene una operación income que es función de fecha (Date). Para un persona aPerson y una fecha aDate, esta operación sería accedida como: aPerson.income(aDate) La operación puede ser definida con una postcondición. El objeto devuelto por ésta (el resultado) se denomina result: context Person::income (d: Date) : Integer post: result = age * 1000 Se ponen paréntesis aunque la operación o método no tenga argumentos: context Company inv: self.stockPrice() > 0
  • 117. Propiedades: Extremos de asociación y navegación Ejemplo: context Company inv: self.manager.isUnemployed = false inv: self.employee->notEmpty En el primer invariante, self.manager es una persona (la multiplicidad de la asociación es 1) En el segundo, self.employee se evaluará a un conjunto de personas. La expresión completa es un valor booleano que vale true cuando la colección a la izquierda es no vacía. Si la asociación en el Diagrama de Clases está adornada con {ordered}, en lugar de un conjunto (valor por defecto de la navegación) obtendríamos una secuencia como resultado
  • 118. Propiedades: Extremos de asociación y navegabilidad • Se puede acceder a las propiedades de los tipos colección (Sets, Bags, Sequences ) mediante una flecha ‘->’ seguida por el nombre de la propiedad: context Person inv: self.employer->size < 3 Aplica la propiedad size sobre el conjunto (Set) self.employer, que resulta en el número de “empleadores” de la persona self. context Person inv: self.employer->isEmpty Aplica la propiedad isEmpty sobre el conjunto self.employer. Se evalúa a true si el conjunto de empleadores es vacío o false en caso contrario.
  • 119. OCL. Más ejemplos Atributos: context Persona inv: self.edad>0 context Banco inv límEmpleados: self.empleados < 100 Opcionalmente, la restricción puede tener un nombre, en este caso “límEmpleados” Extremos de asociación y Navegación: context Persona inv: self.esposa->notEmpty implies self.esposa.sexo=femenino PERSONA esCasado: Booleano fechaNacimiento:Fecha edad:Integer nombre: String sexo: enum{mas,fem} ingreso(fecha):Integer MATRIMONIO lugar: String fecha: Fecha BANCO Empleados:Integer 0..1 Cliente 0..* Esposo 0..1 Esposa 0..1 implies es una operación definida sobre el tipo de datos predefinido de OCL, Boolean
  • 120. OCL. Más ejemplos Operaciones: context Persona::ingreso(fecha):Integer post: result > 1000 context Person::birthdayHappens() post: age = age@pre + 1 El valor de una propiedad en una postcondición es el valor después de haberse completado la operación. Para referirse al valor de la propiedad al principio de la operación, se usa el postfijo ‘@pre’, detrás del nombre de la propiedad.
  • 121. OCL. Colecciones • Operaciones de las Colecciones. – Seleccionar y Descartar (Select, Reject) context Banco inv: self.cliente->select(edad>50) --cto de personas --mayores de 50 – Recolectar (Collect) context Banco inv: self.cliente->collect(fechaNacimiento) -- bolsa con --las fechas de nacimiento de los empleados
  • 122. OCL. Colecciones – ParaTodos (ForAll) context Banco inv: self.cliente->forAll(Nombre=‘Juan’) -- verdadero si --todos los clientes se llaman Juan – Existe (Exists) context Company inv: self.employee->exists( forename = 'Jack' ) context Company inv: self.employee->exists( p | p.forename = 'Jack' ) context Company inv: self.employee->exists( p : Person | p.forename = 'Jack' ) Estas expresiones se evaluan a true si la característica forename de al menos un empleado es igual a ‘Jack.’