S08-2021 -II Requisitos 2da Parte

Vista previa del material en texto

Requisitos
¿En qué disciplina nos encontramos?
2
3
1. Repaso Previo
1.1. MODELO DE CASO DE USO
•Define el alcance (contexto) del
sistema de software.
•Un diagrama de casos de uso (DCU)
muestra los casos que pueden usarse
en el sistema de software.
•Un DCU muestra las relaciones de los
casos de uso entre sí.
•Un DCU muestra las relaciones del
sistema con su entorno (Actores).
4
1.2. ACTOR: Algo o alguien qué:
• Intercambia activamente información
con el sistema.
• Proporciona entradas al sistema.
• Recibe información desde el sistema.
• Puede ser un humano basado en un ROL
(usuario, ingeniero, contador).
• Un sistema de software (Contabilidad,
Compras, Registro Académico).
• Un dispositivo de hardware controlador
(lectora, sensor, etc.).
5
Caso de Uso del Software
1.3. CASO DE USO
En UML los requerimientos
funcionales son conocidos como
Casos de Uso.
Define QUÉ [se] hace [con] el
sistema de software.
Funcionalidad desarrollada por el
sistema ante los estímulos del Actor.
Pre Requisitos
Tener documentados los 
casos de uso :
Flujo de Eventos.
6
Tres Razones para Estructurar el 
Modelo de Caso de Uso
 Hacer que los casos de uso sean fáciles de
entender.
 Permite extraer el comportamiento común
encontrado en varios casos de uso.
 Hacer que el Modelo de Casos de Uso sea
fácil de mantener.
7
Tipos de Relaciones
Existen 3 tipos de relaciones para 
estructurar los casos de uso:
Include
Extend
Generalización
8
Relación Include
 Conecta un CU Base a un CU Incluido.
 El CU Incluido es abstracto.
 La inclusión es encapsulada y representa el
comportamiento que es reutilizado por
varios CU.
 Se factoriza el comportamiento que es
común en un nuevo CU.
9
Relación Include
Propositos :
 El CU Base necesita incluir obligatoriamente
la secuencia de acciones descritas por el
CU Incluido.
 El CU Incluido es de obligatoria ejecución
durante el evento respectivo dentro del CU
Base.
 Es de dependencia entre dos CU.
 El comportamiento del CU Incluido está
explícitamente insertado dentro del
comportamiento definido por el CU Base.
10
11
Se tiene el siguiente diagrama
12
13
14
Los pasos del 2 al 5 se repiten en los 
flujos de eventos de los dos casos de usos. 
Es decir, se está llevando a cabo el mismo 
comportamiento en ambos casos de uso.
Este comportamiento se extrae 
en un nuevo caso de uso: Buscar 
Alumnos
15
El nuevo diagrama con Include
Relación Extend
 Conecta un caso de uso extendido a un
caso de uso base.
 En el caso de uso base están referenciados
los puntos de extensión.
 El caso de uso extendido es a menudo
abstracto, pero no necesariamente tiene
que serlo.
16
Relación Extend
Propósitos:
a) Para demostrar que una parte del caso de uso
es opcional,. También se le conoce como
comportamiento añadido.
b) Para demostrar que un subflujo es
ejecutado sólo bajo ciertas
condiciones.
17
Relación Extend
18
c) Los segmentos de comportamiento
que son insertados como puntos de
extensión en el CU Base, dependerán
de la interacción con los actores
durante la ejecución del CU Base.
d)La extensión es condicional, su
ejecución es dependiente de lo que
suceda con el CU Base.
19
El Diagrama con Extend
Relación de Generalización
 Se utiliza cuando el CU Padre debe ser
subclasificado en uno o más CU Hijos.
 El CU Hijo hereda la estructura,
comportamiento y las relaciones del CU
Padre.
20
21
22
TIPS
Los actores no son
personas sino ROLES
En la siguiente situación:
Los padres de familia, profesores y el jefe de
Dpto. Académico pueden consultar notas.
Los profesores y las secretarias del Dpto.
Académico registran notas.
23
TIPS
Ud está imaginando lo siguiente:
24
Registrar notas
Consultar notas
Padre de Familia
Profesor
Jefe Académico
Secretaria
TIPS
 La solución sería:
25
Crear 2 ROLES. 
Recuerden no son 
personas.
La lectura sería la 
siguiente:
•El rol visualizador se 
asigna a profesores, 
padres de familia y Jefe 
Académico.
•El rol registrador se 
asigna a profesores y 
secretarias.
TIPS
No confunda un extend con 
un escenario
Si bien es cierto ambos proceden
de una condición, el escenario es
programable en unas cuantas
líneas de código. En cambio el
extend invoca a otra funcionalidad
completa que contiene sus propias
clases para GUI, lógica y sus tablas.
26
TIPS
Ejm:
Si el caso de uso base es Registrar Venta.
Generar descuento qué es ????
27
Llenar el formulario de viaje premiado
qué es ???
* Generar descuento es un escenario.
* Llenar el formulario de viaje 
premiado es un caso extendido.
TIPS
Nunca coloque un actor Sistema
en su diagrama de casos de uso.
Sólo colocará un actor sistema si se
tratara de un Sistema Existente.
En las plantillas de casos de uso
cuando utilice la palabra datos,
mencione qué datos son. Esto
permitirá ver cuantas cajas de texto
crear o cuantos campos debe haber
en la tabla de la base de datos para el
desarrollador.
28
Estructurar el MCU del Caso Ventas
 Aplicación en el RSA
29
•Se describen QUE hacen el Actor y el
Sistema y NO COMO se implementa.
•Tanto el camino básico como los
alternativos deben describirse
textualmente en una sección de la
ECU.
¿QUÉ ES LA ECU?
1. NOMBRE
• Debe indicar el título del Caso de Uso.
2. BREVE DESCRIPCION
• Descripción pequeña de las actividades
o pasos principales que realiza el CU.
• Debe incluir el propósito del CU.
3.ACTOR(es)
• Nombre del rol o roles que interactúan
con el caso de uso.
PARTES DE UNA ECU
3. FLUJO DE EVENTOS
EVENTO DISPARADOR
Evento que demandan la ejecución
del CU del sistema.
Evento ante el cuál el sistema de
software debe reaccionar.
Indica que Actor inicia el CU: El
Caso de Uso se inicia “cuando” el
Actor solicita…..
Se coloca antes del Flujo Básico.
• Incluir el punto de inicio y de termino del
CU.
• Conjunto ordenado de acciones (enumerados)
realizados por el Actor y el Sistema, para
alcanzar el propósito
• La instancia del CU se inicia y pasa a un
estado de comienzo
• El CU es invocado por el mensaje de un actor
• Transita a otro estado realizando una
secuencia de acciones (cálculos, selección de
camino, mensajes de salida, etc.)
• Queda a la espera (en el nuevo estado) de
otro mensaje externo
3.1. FLUJO BASICO
•Es invocado (otra vez) por un nuevo mensaje
•Termina la instancia del CU
•El camino elegido como básico debe ser el
normal, el más habitual u obvio para el Actor
que actúa en la mayoría de los escenarios
• Incluir mensajes de confirmación.
1 2 3 9 10
3.1. FLUJO BASICO
•Activación mandatoria del CU incluido, en
algún evento del flujo de eventos del CU
principal (el que incluye).
•El sistema incluye el Caso de Uso <nombre
CU>
•Se grafica en la actividad “Estructurar el
MCU”.
36
1 2 3 9 10
1 n
Mandatorio
CASO INCLUIDO
Los caminos alternativos, desviaciones o
excepciones pueden ocurrir porque:
• El Actor puede elegir entre diferentes caminos
• Si está implicado más de un actor, las acciones
de uno de ellos pueden influenciar el camino
de las acciones de los otros
• El sistema puede detectar ingresos erróneos
de los actores
• Violación de Reglas del Negocio
• Alguna falla en el funcionamiento de alguno de
los recursos del sistema, por lo que éste no
puede efectuar su trabajo hasta el fin del CU.
4.FLUJO(S)ALTERNATIVO(S)
Incluir si el CU continua o termina,
además de los mensajes preventivos o
alertas.
1 2 3 9 10
3.1 3.n
Escenario
•Los subflujos se dan cuando el actor
elige otra opción dentro del CU.
•Por Ejemplo en Mantener Productos:
El Flujo Básico me lista los productos. los
Subflujos serían:
Ingresar Producto, Actualizar Producto,
Eliminar Producto, Consultar Producto.
•Los Subflujos también tienen Flujos
Alternativos.
5.SUBFLUJOS
6. PRE Y POST CONDICIONES
Son estados 
del sistema de 
los que el 
usuario puede 
darse cuenta.
Expresan condiciones o restricciones para
que elflujo de eventos del CU comience
(no es el evento inicial)
• Se expresan en términos de:
✓Estado interno del sistema de software
✓Condiciones externas al sistema de
software (estado del contexto)
✓Una precondición de un CU no se
aplica a subflujos individuales, sino a
todo el CU.
✓Futuro (debe…).
41
6.1 PRE CONDICIONES
•Expresan las condiciones que
deben darse una vez realizado el
CU (resultados esperados en
forma exitosa).
•Se expresan en términos de:
✓ Estado interno del sistema de software
✓ Condiciones externas al sistema de
software (estado del contexto)
✓ Futuro (debe ...)
42
6.2 POST CONDICIONES
43
•Activación condicionada de un CU
extendido en algún paso del flujo de
eventos de CU principal
•El sistema se extiende al Caso de
Uso<nombre CU>
✓Se grafica en la actividad “Estructurar el
MCU”.
7.PUNTOS DE EXTENSION
1 2 3 9 10
1 n
Condición
44
•Definición de casos de usos de
propósito específicos a partir de
un caso de uso de propósito
general.
• El caso de uso general no es
ejecutado, en su lugar el sistema
se usa para el desarrollo de los
casos específicos.
7.1 
Generalización/Especialización
45
Una alternativa para la definición de
los requerimientos.
Consiste en capturar un conjunto
inicial de necesidades e
implementarlas rápidamente con la
intención de expandirlas y refinarlas
iterativamente, al ir aumentando la
compresión que tienen del sistema
los Usuarios y Desarrolladores.
8.PROTOTIPO (GUI)
• Escriba oraciones cortas, concisas y emplee
lenguaje simple y claro, evitando términos técnicos.
• Evite adverbios: muy, casi, mejor que, bastante,
etc.
• Emplee correctamente los signos de puntuación.
• Evite usar oraciones compuestas.
• Describa el flujo, no sólo el propósito del CU.
• Describa sólo el flujo del CU, evite mencionar
eventos de otros CU que pudieran ejecutarse en
paralelo.
• No mencione actores que no intervienen en el CU.
• Si el orden de los eventos no es fijo, esta
característica debe ser explícita.
4. TIPS PARA DETALLAR LAS ECU
• Clientes: aprueban lo que debe hacer el sistema
• Usuarios: obtienen comprensión del sistema
• Desarrolladores del Sistema: documentan el
comportamiento del sistema
• Revisores: examinan el flujo de eventos
• Analistas del Sistema / Diseñadores: proveen la
base para un análisis y diseño
• Testeadores del Sistema: usado como base para
casos de prueba
• Líder de Proyecto: provee entradas para el
planeamiento de proyectos
• Escritor Técnico: para el “Manual de Usuario”.
5. ¿QUIÉNES LEEN LAS ECU?
48
1. Nombre del Caso de Uso
1. Breve Descripción
2. Actor
2. Flujo de Eventos
Evento Disparador
2.1 Flujo Básico
1.
2. Incluir Casos de Uso <<nombre>>
3.
n….
2.2 Flujos Alternativos
3.2.1 < Primer Flujo Alternativo >
3.2.2 < Segundo Flujo Alternativo >
2.3 < Sub Flujos >
2.3.1 < Flujos Alernativos del Sub Flujo >
6. PLANTILLA
49
3. Requerimientos Especiales
3.1 < Primer Requerimiento Especial >
4. Pre Condiciones
4.1 < Precondición 1 >
5. Post Condiciones
5.1 < Post Condición 1 >
6. Puntos de Extension
6.1 << Nombre del Caso de Uso Extendido>>
7. Prototipo (GUI).
Ejemplo de Especificación de
Caso de Uso
50
Ejemplo de Caso de Uso
51
52
53
Llamado de Incluidos
54
Llamado de Extend
3
6
3
El CU Include se ejecuta de manera
obligatoria por el CU Base para que
cumpla con su objetivo.
El CU Extend nace de la excepción
o condición de un CU Base.
La Generalización de CU se da
cuando dos o mas CU Base poseen
un comportamiento y estructura
común.
55
Conclusiones