Modelo de Operaciones

Modelo de Operaciones
•  ¿Qué es?
•  ¿Relación con otros modelos?
•  Especificación usando:
–  Pre/Post condiciones
–  Casos de uso
Lo que vimos hasta ahora...
•  Introducción a la Ingeniería de Requerimientos
–  Definición, relevancia, actividades principales, ciclos de vida...
•  Fundamentos
–  Modelo de Jackson, 4V, contexto
–  Prescripción vs Descripción, Verificación y Validación,
Objetivos vs Requerimientos
•  Modelo de objetivos
–  Vínculo con los modelos de Jackson, 4V y de contexto
2
Modelo de Operaciones
•  ¿Qué operaciones/servicios debe proveer la máquina que vamos a
construir? ¿Cómo funcionan?
•  ¿Qué transformaciones pueden ocurrir en el mundo? ¿Cómo
funcionan?
•  Conceptos
–  Operación
–  Signatura : Datos de Entrada y Salida, Precondición, Poscondición,
Condiciones de “Trigger” o de gatillo
–  Agente o Rol o Actor usuario de la operación
–  Agente proveedor de la operación
•  Casos de Uso:
–  Una posible notación gráfica para el modelo de operaciones
3
Ejemplo de Operación
Operación: PlanificarReunión
Usuarios: Iniciador de reunión
Responsable: Software
Def: Fija fecha de reunión a partir de las restricciones informadas
por invitados
Entrada: r: reunión
Salida: r:reunión
Pre: Las restricciones de cada invitado han sido informadas (G223)
Post: La fecha de reunión no está dentro de las fechas excluidas
por cada invitado (G223)
Referencia a objetivo
Veremos más adelante como formalizar las
condiciones usando el modelo conceptual y OCL
4
Ejemplo de Operación
Operación: Abrir Puertas
Responsable: Software de control
Def: Controla apertura de puertas en un tren
Entrada: t: infoDeTren
Salida: t:infoDeTren
Pre: t.velocidad = 0 (G135)
Pre: t.posición corresponde a plataforma (G325)
Trig: t.velocidad = 0 y t.posición corresponde a
plataforma (G13)
5
Ejemplo de Operación
Operación: Movilizar Ambulancia
Responsable: Personal de ambulancia
Def: Llega a lugar de incidente
Entrada: i: incidente, a:ambulancia
Salida: r: reporte de estatus
Pre: i.ubicacion.valido, i.amb_asignada = a
Post: (a.ubicación = i.ubicacion y r.status = ok) o
(r.status = nok)
6
Vínculo con el Modelo de Objetivos
•  Los objetivos uni-agente introducen
operaciones
–  Requerimientos inducen operaciones del software
–  Expectativas inducen operaciones de agentes
•  En la práctica no es una relación uno a uno…
•  Veamos la conexión semántica
7
Semántica
8
Validación del Modelo de Operaciones
•  Problema:
–  Las operaciones asignadas al software son muchas…
–  Cómo las validamos? Correctitud? Completitud?
Pertinencia?
–  El modelo de objetivos admite análisis pero los
requerimientos (que inducen operaciones) están
dispersos.
–  Una lista de operaciones no tiene estructura…
•  Solución:
–  Estructurar las operaciones…. pero de qué manera?
9
Diagrama de Casos de Uso
•  Estructura el conjunto de operaciones atendiendo a la
categoría de usuarios que participan en el mismo.
•  Describen bajo la forma de acciones y reacciones las
operaciones provistas por una máquina desde el punto
de vista del usuario.
–  Facilitar validación con los usuarios.
•  Sólo se concentran en funcionalidad provista por la
máquina a construir
–  Facilitar validación del alcance.
•  Solo interesan interacciones directas Maquina-Agente
•  Son sólo una (pero muy popular) de las posibles
maneras de describir el modelo de operaciones
10
Diagrama de Casos de Uso
•  Conceptos fundamentales
–  Actores
–  Casos de Uso
–  Frontera de la máquina a construir
–  Vínculos Actor-Caso de Uso: “participa en”
•  Elementos estructuradores adicionales
–  Herencia
–  Vínculos entre casos de uso
11
Actores
Un Actor:
–  Representa un tipo de usuario
–  Abstrae el usuario real (personas, sistemas o dispositivo, es
decir, un agente)
–  El nombre del actor describe el rol desempeñado.
–  En términos de los modelos vistos anteriormente, un actor
es un agente.
•  Esto no quiere decir que existe una relación 1 a 1 con los agentes del modelo de agentes.
Informante
de Incidente
Equipo de
Atención al
Incidente
Usuario de
Biblioteca
Personal de
Biblioteca
12
Actores: Visión Semántica
•  Un Actor denota un conjunto de agentes concretos
•  No hay restricciones a priori sobre como enganchan
los conjuntos denotados por distintos actores.
•  Un agente concreto puede ser modelado por varios
actores distintos.
–  Puede jugar a estos roles simultáneamente, alternadamente
o con un protocolo complejo.
Agentes
denotados
por un actor
13
Casos de Uso
•  Un caso de uso especifica una o varias secuencias de acciones
que el sistema puede llevar a cabo interactuando con sus
actores, incluyendo alternativas dentro de la secuencia.
•  La máquina se representa con un rectángulo, dentro del cual se
ubican los casos de uso.
•  El nombre se suele expresar con un verbo en gerundio.
Máquina
14
Ejemplo
15
Ejemplo
“El sistema de un local de venta de electrodomésticos
es utilizado por los vendedores, los jefes de ventas, el
gerente y el administrador del sistema…”
16
Ejemplo
“…también el sistema deberá ser capaz de recibir
órdenes de compra enviadas por el sistema actual de
facturación llamado Facturator IV…”
17
Ejemplo
“… el sistema deberá permitir que los vendedores
puedan registrar las órdenes de compra. El jefe de
ventas será el encargado de autorizarlas o no según las
normativas de la empresa…”
18
Diagramas de Casos de Uso: Para qué?
•  Fundamentalmente sirven para:
–  Definir el alcance del software/máquina a construir
•  Qué está dentro de la caja.
–  Facilitar validación de funcionalidad con stakeholders
•  Organizan funcionalidad por actor.
•  Es un lenguaje que en la práctica se usa de manera
poco precisa, con semántica informal que prioriza
comunicación
–  Nosotros veremos una de las muchas versiónes semi-formales
que existen
19
Descripción Detallada de Casos de Uso
•  Las etiquetas que describen los casos de uso pueden
necesitar una ampliación más detallada o mas precisa.
–  Para explicar una interacción crítica necesaria ara lograr
objetivos
–  Para clarificar aspectos de la funcionalidad que caen
dentro y fuera del software a construir
–  Para clarificar el rol de los actores en el caso de uso
•  La descripción detallada puede darse utilizando
distintos lenguajes
–  Lenguaje natural
–  Tablas
–  Diagramas de secuencia, máquinas de estado, etc
•  Una buena práctica es incluir pre y post condición.
20
Casos de Uso: Descripción detallada
•  Lenguaje natural
–  Pre/Post
Condiciones
–  Secuencia de
operaciones
Caso de Uso: Ingresando Orden de Compra
Actor: Vendedor
PRE: Vendedor autenticado
POST: Orden de compra registrada
1. El vendedor ingresa el número de cliente en el sistema.
2. El sistema muestra información básica sobre el cliente.
3. El vendedor ingresa el código del producto que el
cliente quiere comprar, informando su cantidad.
4. El sistema muestra información del producto solicitado,
y confirma su disponibilidad.
5. Se repite el paso 3 hasta que el vendedor no ingresa
más productos.
6. El sistema notifica que la orden de compra ha sido
registrada.
7. Fin del caso de uso.
21
Caso de Uso: Descripción Detallada
•  Otra alternativa para documentar casos de uso
22
Caso de Uso: Descripción Detallada
•  Y…otra alternativa para documentar casos de uso
Pre: Vendedor Autenticado
Post: Orden de compra registrada
“El vendedor ingresa el numero de cliente, el software retorna
información del cliente ingresado. Luego, el vendedor podrá
ingresar el codigo de producto, recibiendo del sistema
información y disponibilidad del producto. Esto lo podrá hacer
repetidas veces. Finalmente, el sistema informará que la orden
quedó registrada”
23
Casos de Uso: Descripción
•  Durante la ejecución de un caso de uso, suelen
aparecer errores o excepciones. Las
desviaciones del curso normal del caso de uso
se llaman alternativas.
24
Casos de Uso: Descripción
Caso de Uso: Ingresando Orden de Compra
Actor: Vendedor
Pre: Vendedor autenticado
Curso Normal
Alternativas
1. El vendedor ingresa el número de cliente en el
sistema.
2. El sistema obtiene la información básica sobre el 2.1 Si el cliente no está registrado,
cliente.
el vendedor lo debe registrar.
3. El vendedor ingresa el código del producto que el
cliente quiere comprar, informando su cantidad.
4. El sistema obtiene información del producto
solicitado, y confirma su disponibilidad.
5. Se repite el paso 3 hasta que el vendedor no
ingresa más productos.
6. El sistema registra la orden de compra
POST: Orden de compra registrada
4.1 Si no hay disponibilidad del
producto, el sistema informa la
fecha de reposición.
Aqui cliente no hace
referencia a un agente
interactuando sino a un
concepto del dominio
25
Relación “Participa En”
•  Como dijimos, el diagrama de casos de uso se usa muy
informalmente
•  En esta materia formalizamos el uso de la relación
“Participa En” asi:
–  A participa en U si y solo si la descripción detallada de U hace
referencia explicita al actor A como participante de la
interacción
–  Es decir es una noción sintáctica.
–  Puede pensarse como el tipado de la burbuja.
26
Casos de Uso: La visión Semántica
•  Un caso de uso describe un conjunto de escenarios
–  Para toda elección de actores de acuerdo al tipado del caso de
uso
–  Para toda secuencia de interacciones que se ajusta a la
descripción detallada.
•  Vinculo semántico con la relación “participa en”
–  Pregunta: Si A participa en C y un escenario s pertenece al
conjunto denotado por C, podemos garantizar que una instancia
de A interactua con el sistema en s?
–  Respuesta: No. Porque?
Software
i:Actor
27
Ejemplo
•  El software permitirá a vendedores realizar operaciones de venta,
estas deberán ser aprobadas por el jefe de ventas cuando el
monto supere 1000 pesos
Vendiendo Producto
¿Cómo podríamos hacer más preciso este diagrama?
28
Diagramas de Casos de Uso
- Más Estructura •  Relaciones que podemos usar para
estructurar diagramas de casos de uso:
–  Participa en
•  Relación entre Actor y Caso de Uso (Ya visto)
–  Herencia
•  Relación entre Actores
•  Relación entre Casos de Uso
–  Extiende
•  Relación entre Casos de Uso
–  Incluye
•  Relación entre Casos de Uso
29
Herencia
•  Herencia es una relación que encontraremos en el
contexto de varios modelos.
•  La semántica mas abstracta de herencia es
X
“subconjunto”
Y
–  Si X hereda de Y entonces X ⊆ Y
•  Una intuición
–  Si X hereda de Y entonces X es un tipo especial de Y.
•  Terminología. Si X hereda de Y entonces
– 
– 
– 
– 
X es una especialización de Y
Y es una generalización de X
X es hijo de Y, Y es padre de X
X es sub-…. de Y, Y es super-… de X
Y
X
30
Relaciones: Herencia de Actores
•  Permite estructurar actores según la relación “es un tipo
especial de”
•  Un vendedor ambulante es un tipo de vendedor especial.
•  Casos de uso relevantes para vendedores lo son también para
vendedores ambulantes
•  Los vendedores ambulantes “heredan” los casos de
Vendedor
Vendedores
Ambulantes
Vendedor
Ambulante
Vendedores
Vendedor
31
Ejemplo de Herencia de Actores
…el jefe de ventas es un tipo de vendedor especial…
Vendedores
Ambulantes
En las referencias que hace ingresando
orden de compra a Vendedores, no
puedo usar jefe de ventas, pero una
persona que es jefe de ventas puede
tomar el rol de vendedor….
Vendedores
32
Estructurando con herencia…
“… el sistema deberá permitir que los vendedores puedan registrar
las órdenes de compra. El jefe de ventas será el encargado de
autorizarlas o no según las normativas de la empresa; El jefe de
ventas puede vender ya que es a todos los efectos prácticos un
vendedor (con la capacidad adicional de que puede autorizar
ventas)
33
Encuentre las diferencias (semánticas)
•  …vendedores ingresan…jefes autorizan…
34
Estructurando con Herencia
Este diagrama es más
abstracto. Por qué?
35
Herencia y Entes Abstractos
•  Supongamos Y con especializaciones X1, ...Xn.
•  Si todo elemento de Y pertenece a algunas de las especializaciones X1, ...,
Xn entonces decimos que Y es abstracto
•  Es decir que si una entidad es considerada abstracta, entonces cualquier
instancia de ella es a su vez una instancia de alguna entidad mas
especializada.
•  Para qué sirven?
– 
– 
Para introducir conceptos relevantes
Estructurar mejor (mas sintético, mas cerca del lenguaje del stakeholder)
36
Ejemplo
37
Relaciones: Inclusión o “Usa a”
•  Una escenario del caso de uso A incluye
también el comportamiento descrito por el
caso de uso B.
38
Ejemplos de Inclusión
39
Ejemplo
Caso de Uso: Ingresando Orden de Compra
Actor: Vendedor
Pre: Vendedor autenticado
Curso Normal
Alternativas
1. El vendedor ingresa el número de cliente en el
sistema.
2. El sistema obtiene la información básica sobre el 2.1 Si el cliente no está registrado,
cliente.
el vendedor lo debe registrar.
3. El vendedor ingresa el código del producto que el
cliente quiere comprar, informando su cantidad.
USA Caso de uso Buscando Producto.
4. El sistema obtiene información del producto
solicitado, y confirma su disponibilidad.
4.1 Si no hay disponibilidad del
producto, el sistema informa la
fecha de reposición.
5. Se repite el paso 3 hasta que el vendedor no
ingresa más productos.
6. El sistema registra la orden de compra
POST: Orden de compra registrada
40
Includes: Visión Semántica
•  Si un escenario s es denotado por A, entonces existe una porcion
de s que contiene un escenario denotado por B
•  Pueden existir escenarios denotados por B que no aparecen en
escenarios dentoados por A
Instancias de
caso de uso B
41
Estructurando con Inclusión
•  Algunos usos informales admiten
casos de uso “incluidos” por
otros sin actores directamente
asociados.
•  En esta materia NO.
•  Cada caso de uso involucra
participacion de actores
•  Participacion debe ser
explicada en la descripcion
detallada
•  Actores explicitados deben
estar en diagrama
42
Participación Explicita
•  Aquí queda claro que cliente
participa en la deficinición de
Consultando películas.
•  Además, Consultando Películas
es un caso de uso en si mismo.
43
Includes y Herencia
•  Muchas veces
debemos recurrir a
un super-actor para
tipar a un caso de
uso incluido en
muchos otros…
•  Es importante
tratar de que el
super-actor sea
relevante desde el
punto de vista del
problema
•  Veamos otro
ejemplo…
44
Ejemplo
45
Ejemplo
46
Ejemplo
47
Introducción de Elementos Foráneos
•  Es común en lenguajes formales que tengamos que introducir
elementos poco intuitivos para resolver restricciones sintácticas.
•  ¿Qué es un “buscador de productos”?
•  Es aconsejable tratar de evitar estas construcciones…
•  Otra alternativa: Vincular vendedor y gerente con Buscando
Producto. Desventajas?
48
Casos de Uso Auxiliares
- Azucar Sintáctica -
•  Para resolver algunas construcciones sintácticas toscas, los
lenguajes formales agregan a veces elementos que no agregan
expresividad, solo resumen algo ya expresable
•  Introducimos un elemento de azucar sintáctico
•  Un caso de uso U es auxiliar si
–  En el diagrama no hay actores que participan de el.
–  Las referencias a actores en ladescripción detallada de U son de un
tipo de actor abstracto A definido implicitamente
–  El Actor abstracto A es super-actor de todos los actores que
participan de casos de uso que usan a U y todos los casos de uso que
son extendidos por U
en el diagrama de casos de uso
49
Casos de Uso Auxiliares
<aux>
50
Relaciones: Extensiones
•  Una instancia del caso de uso A incluye, a veces, el
comportamiento descrito por el caso de uso B.
•  Representan una parte de la funcionalidad del caso que no
siempre ocurre.
•  Explicitan gráficamente un errores, excepciones y
comportamiento alternativo
51
Ejemplos de Extensiones
52
Extends: Visión Semántica
•  Existe al menos un escenario s denotado por A, que contiene un
escenario denotado por B
•  Pueden existir escenarios denotados por B que no aparecen en
escenarios dentoados por A
Instancias de
caso de uso B
53
Ejemplo
•  El software permitirá a vendedores realizar operaciones de
compra/venta, estas deberán ser aprobadas por el jefe de ventas
cuando el monto supere 1000 pesos
¿Cómo podríamos hacer más preciso este diagrama?
54
Ejemplo
•  El software permitirá a vendedores realizar operaciones de venta,
estas deberán ser aprobadas por el jefe de ventas cuando el
monto supere 1000 pesos
<<extends>>
55
Ejemplo
Caso de Uso: Ingresando Orden de Compra
Actor: Vendedor
Pre: Vendedor autenticado
Curso Normal
Alternativas
1. El vendedor ingresa el número de cliente en el
sistema.
2. El sistema obtiene la información básica sobre el
cliente.
2.1 Si el cliente no está registrado, el
vendedor lo debe registrar.
3. El vendedor ingresa el código del producto que el
cliente quiere comprar, informando su cantidad. USA
Caso de uso Buscando Producto.
4. El sistema obtiene información del producto
solicitado, y confirma su disponibilidad.
4.1 Si no hay disponibilidad del
producto, el sistema informa la fecha
de reposición.
5. Se repite el paso 3 hasta que el vendedor no ingresa
más productos.
6. El sistema registra la orden de compra. En caso de
que la venta supere 1000$, EXTIENDE Caso de uso
Autorizando Orden de Compra.
POST: Orden de compra registrada
56
Combinando relaciones…
<aux>
57
Diagramas de Casos de Uso: Para qué?
•  Fundamentalmente sirven para:
–  Definir el alcance del software a construir
•  Que está dentro de la caja.
–  Facilitar validación de funcionalidad con
stakeholders
•  Organizan funcionalidad por actor.
•  No buscan dar una descripción detallada de
toda la funcionalidad
–  Vale abstraer!
–  Cuanto detallar?
•  Hasta cubrir la funcionalidad mas relevante/critica
•  Hasta que ya no es efectivo (costo vs. beneficio)
58
Relación con otros Modelos
•  Casos de uso vs. Modelo de Agentes
–  Actores vs. Agentes
–  Interfaz del software vs. Monitoreabilidad y
Controlabilidad de la Máquina.
•  Casos de uso vs. Modelo de Objetivos
–  Requerimientos inducen operaciones
–  Casos de uso son o agrupan operaciones
–  Casos de uso operacionalizan expectativas
59
Modelo de Operaciones: Resumen
•  Modelado de operaciones a ser provistas por
agentes.
–  Aridades, Pre y Post condiciones, Agentes usuarios
•  Casos de Uso
–  Una forma particular de modelado de operaciones
–  Foco en interacciones “complejas” (los casos de uso)
y su descomposición en operaciones sencillas,
mostrando interacción maquina-actor
–  Modos de estructuración
•  Herencia, Entes abstractos
•  Otros...
60
Vínculo con Modelos Anteriores
•  Modelo de Jackson
–  Fenómenos en la interfaz vs. Operaciones
•  Diagrama de Contexto
–  Consistencia agentes y actores: interfaz, visibilidad de
fenómenos
•  Modelo de las 4 variables
–  Monitorabilidad/controlabilidad vs. Agente responsable/
entrada/salida
•  Modelo de Objetivos
–  Requerimientos y expectativas vs. Operaciones
•  Relación muchos a muchos
61