S08-2020I 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).
3
Tus comentarios:
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.
5
Tus comentarios:
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ónmandatoria 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
36
Tus comentarios:
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 el flujo 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
41
Tus comentarios:
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
42
Tus comentarios:
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
43
Tus comentarios:
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
44
Tus comentarios:
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)
Haga clic para modificar el estilo de texto del patrón
Segundo nivel
Tercer nivel
Cuarto nivel
Quinto nivel
45
Tus comentarios:
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
Nombre del Caso de Uso
Breve Descripción
Actor
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