Sesión 07- Modelado de Requerimientos

44
INGENIERÍA DE SOFTWARE Ing. Antonio Arqque Pantigozo MODELADO DE REQUERIMIENTOS

description

Modelado de Requerimientos

Transcript of Sesión 07- Modelado de Requerimientos

Page 1: Sesión 07- Modelado de Requerimientos

INGENIERÍA DE SOFTWARE

Ing. Antonio Arqque Pantigozo

MODELADO DE REQUERIMIENTOS

Page 2: Sesión 07- Modelado de Requerimientos

2

MODELO DE CASOS DE USO

El Modelo de Casos de uso es un modelo que describe

los requerimientos funcionales del sistema en forma

de Casos de uso

Page 3: Sesión 07- Modelado de Requerimientos

REQUERIMIENTOS FUNCIONALES

Un requerimiento es: una condición o

capacidad a la que debe ajustarse el sistema que

se construye.

Requerimiento funcional: es un requerimiento

que describe que debe hacer el sistema respecto a

su entorno

Entorno: los usuarios u otros sistemas

3

Page 4: Sesión 07- Modelado de Requerimientos

¿DIFERENCIAS? REQUERIMIENTO VS.

CASOS DE USO

Hay una correspondencia directa de requerimiento funcional hacia Caso de uso

Mas bien la diferencia está en la forma de la descripción.

Los requerimientos funcionales se registran en un documento denominado “Software Requeriments Specifications”, conocido por sus siglas SRS.

Los Casos de uso se documentan en un modelo de Casos de uso.

4

Page 5: Sesión 07- Modelado de Requerimientos

DIAGRAMA DE CASOS DE USO

Semántica Un diagrama de casos de uso muestra los actores,

los casos de uso y sus relaciones.

Notación Es un grafo de actores, casos de usos y relaciones.

Las relaciones son asociaciones entre los actores y

los casos de uso, generalizaciones entre los actores,

generalizaciones, extensiones e inclusiones entre

los casos de uso

5

Page 6: Sesión 07- Modelado de Requerimientos

BENEFICIOS

El modelo de Casos de usos

Es usado para comunicarse con el usuario final y el experto del dominio Proporciona credibilidad en una etapa inicial del desarrollo

del sistema

Asegura una comprensión mutua de los requisitos

Es usado para identificar Quién interactuará con el sistema y qué deberá hacer el

sistema

Qué interfaz deberá tener el sistema

Es usado para verificar que: Se capturan todos los requisitos

Que los desarrolladores hayan entendido los requisitos

Es usado como base para la pruebas.

Es usado como base para la planificación del proyecto.6

Page 7: Sesión 07- Modelado de Requerimientos

DIAGRAMA DE CASOS DE USO

Un Diagrama de Casos de uso muestra los Actores,

los Casos de uso y las Relaciones entre ellos:

<Actor Name>

(f rom Actors)

<Use Case Name>

(from <Use Case Name>)

<<communicate>>

7

Page 8: Sesión 07- Modelado de Requerimientos

ACTOR

Un actor es :

un rol que un grupo de usuarios de un sistema cumplen cuando interactúan con este

Define un conjunto de instancias de actores, donde cada uno juegael mismo rol en relación al sistema.

Una instancia de un actor es algo (otro sistema o equipo) o alguien (persona) que interactúa con el sistema. 8

Page 9: Sesión 07- Modelado de Requerimientos

Qué grupos de usuarios necesitan apoyo del

sistema para realizar sus tareas?

Qué grupos de usuarios son responsables de

ejecutar las funciones relevantes del sistema

Qué usuarios realizan labores secundarias

de mantenimiento y administración?

Interactuará el sistema con algún dispositivo

o sistema externo?

IDENTIFICAR ACTORES

9

Page 10: Sesión 07- Modelado de Requerimientos

LOS ACTORES AYUDAN A DEFINIR LA

FRONTERA DEL SISTEMA

Sistema de

aerolínea

pasajero agente de viajes

Situación 1:

Sistema de

aerolínea

pasajero (www.enPista.com)

Situación 2:

10

Page 11: Sesión 07- Modelado de Requerimientos

RELACIONES ENTRE ACTORES

Si dos o más actores utilizan el sistema de la

misma forma entonces es posible establecer una

relación de Generalización entre ellos, con el

objetivo de simplificar el modelo de Casos de uso

11

Page 12: Sesión 07- Modelado de Requerimientos

RELACIONES ENTRE ACTORES

Estudiante Profesor

Usuario

12

Page 13: Sesión 07- Modelado de Requerimientos

CASO DE USO

Un Caso de uso define un conjunto de instancias de

Casos de uso.

Un escenario o instancia de un caso de uso es una secuencia especifica de acciones e interacciones entre los actores y el sistema objeto de estudio que proporciona valor a un actor en particular.

En otras palabras: “es una descripción de la secuencias de acciones que un sistema ejecuta para proporcionar un resultado observable de un valor a un actor en particular”

13

Page 14: Sesión 07- Modelado de Requerimientos

ENCONTRAR CASOS DE USO

¿cuáles son las tareas del actor?

¿qué información crea, guarda, modifica,

destruye o lee el actor?

¿debe el actor notificar al sistema los

cambios externos?

¿debe el sistema informar al actor de los

cambios internos?

Necesita el actor realizar operaciones de mantenimiento, auditoria y/o soporte?

14

Page 15: Sesión 07- Modelado de Requerimientos

RELACIONES ENTRE CASOS DE USO

Relaciones de inclusión / uso (<<include>>)

Relación de extensión (<<extend>>)

Relación de generalización

15

Page 16: Sesión 07- Modelado de Requerimientos

… CASOS DE USO: RELACIONES

Inclusión : una instancia del Caso de Uso origen incluye también el comportamiento descrito por el Caso de Uso destino

<<include>> reemplazó al denominado <<uses>>

Caso de Uso Origen Caso de Uso Destino

<<include>>

16

Page 17: Sesión 07- Modelado de Requerimientos

17

… CASOS DE USO: RELACIONES

Caso de uso origen

Caso de uso destino

De Inclusión:El caso de uso origen incorpora explícitamente el comportamiento de otro caso de uso como fragmentos de su propio comportamiento.

El caso de uso destino no es un caso especial del caso de uso original y no se puede sustituir por él.

<<includes>>

Page 18: Sesión 07- Modelado de Requerimientos

18

… CASOS DE USO: RELACIONES

Extensión : el Caso de Uso origen extiende el comportamiento del Caso de Uso destino

Caso de Uso Origen Caso de Uso Destino

<<extend>>

Caso de uso destino Caso de uso origen

Page 19: Sesión 07- Modelado de Requerimientos

… CASOS DE USO: RELACIONES

De Extensión: Se amplia el comportamiento del caso de uso origen con

otro comportamiento adicional

Caso de uso origen

Caso de uso destino

<<extends>>

Modela parte del caso de uso que representa comportamiento opcional del sistema

19

Page 20: Sesión 07- Modelado de Requerimientos

… CASOS DE USO: RELACIONES

Generalización : el Caso de Uso origen hereda la especificación del Caso de Uso destino y posiblemente la modifica y/o amplía

Caso de Uso Hijo Caso de Uso Padre

20

Page 21: Sesión 07- Modelado de Requerimientos

… CASOS DE USO: RELACIONES

Ejemplo:

Identificación

Transferencia en Internet

ClienteTransferencia

<<include>>

<<extend>>

21

Page 22: Sesión 07- Modelado de Requerimientos

EJEMPLO DE <<INCLUDE>>

Validar operación

Reintegro cuenta corriente

Cliente

Reintegro cuenta crédito

<<include>>

<<include>>

22

Page 23: Sesión 07- Modelado de Requerimientos

23

EJEMPLO DE <<EXTENDS>>

Solicitar nueva tarjeta

Socio

Realizar préstamo

tarjeta caducada

<<extends>>

Encargado

Page 24: Sesión 07- Modelado de Requerimientos

CASOS DE USO – EJEMPLO1

Identificación

Giro por Internet

Cliente

Giro

<<extends>>

<<includes>>

24

Page 25: Sesión 07- Modelado de Requerimientos

25

CASOS DE USO - EJEMPLO2

Cliente

pedir saldo

retirar

cargar

Supervisor

Cajero Electrónico

validar

usuario

<include>

<include>

Retiro con

sobregiro

<extend>Comprobar

huella

Page 26: Sesión 07- Modelado de Requerimientos

26

Realizar Pago

Acordar Crédito

Vendedor

Suministro de

datos clientes

Pedir Producto

Pagar al Contado

Solictar CatalogoHacer Pedido

<<include>>

<<include>>

<<include>>

<<extend>>

CASOS DE USO - EJEMPLO3

Page 27: Sesión 07- Modelado de Requerimientos

DESCRIPCIÓN DE LOS CASOS DE USO

Formato Breve

Descripción resumida de la funcionalidad

que representa el caso de uso (qué)

Formato Detallado

Contiene mayores detalles. Describe el curso

flujo de eventos o diálogo que se sucede entre

el actor y el sistema

27

Page 28: Sesión 07- Modelado de Requerimientos

Formato Breve

Caso de uso: Comprar Producto

Actores: Cliente, Cajero

Descripción:

Un cliente llega a la caja registradora

con los artículos que comprará. El cajero registra

los artículos y cobra el importe. Al terminar la

operación el cliente se marcha con los productos.

DESCRIPCIÓN DE LOS CASOS DE USO

28

Page 29: Sesión 07- Modelado de Requerimientos

Formato Detallado

Caso de uso :

Actores :

Precondición :

Poscondición :

Flujo Básico

Actor

1.El caso de uso comienza

cuando el actor …

2.

3

Sistema

1.

2.

3.

Flujos Alternativos

1.

2.

DESCRIPCIÓN DE LOS CASOS DE USO

29

Page 30: Sesión 07- Modelado de Requerimientos

EJEMPLO: SISTEMA ACADÉMICO

El sistema permitirá:

A los profesores:

Consultar los horarios de sus cursos

Consultar la programación de los exámenes

Actualizar y ver su información personal

Registrar y modificar las notas de los estudiantes a

su cargo

Cerrar un curso

Requerimientos

funcionales

30

Page 31: Sesión 07- Modelado de Requerimientos

A los estudiantes:

Consultar los horarios de sus cursos

Consultar la programación de los exámenes

Actualizar y ver su información personal

Consultar notas de un curso

Requerimientos

funcionales

31

Page 32: Sesión 07- Modelado de Requerimientos

CASOS DE USO DEL USUARIO

Consultar horarios de cursos

Consultar horario de exámenes

Validar accesoUsuario

(f rom Actors)

32

Page 33: Sesión 07- Modelado de Requerimientos

CASOS DE USO DEL ESTUDIANTE

Mantener información del estudiante

Estudiante

(f rom Actors)

Consultar notas de un curso

33

Page 34: Sesión 07- Modelado de Requerimientos

CASOS DE USO DEL PROFESOR

Mantener información del profesor

Registrar notas de un curso

Cerrar un curso

Profesor

(f rom Actors)

34

Page 35: Sesión 07- Modelado de Requerimientos

DESCRIPCIÓN DE UN REQUERIMIENTO

Registrar y modificar las notas de los estudiantes

a su cargo:

El profesor, que previamente se ha identificado en el

sistema, podrá ingresar las notas de los estudiantes.

Solo podrá acceder a sus grupos de clases. Una vez

cerrado un curso no podrá hacer cambios.

35

Page 36: Sesión 07- Modelado de Requerimientos

EL ACTOR PROFESOR Y SUS CASOS DE USO

Consultar horarios de cursos

(from Use Cases)

Consultar horarios de examenes

(from Use Cases)

Mantener información del profesor

(from Use Cases)

Registrar notas de un curso

(from Use Cases)

Validar acceso

(from Use Cases)

Profesor

(f rom Actors)

36

Page 37: Sesión 07- Modelado de Requerimientos

MODELO DE CASOS DE USO DEL

SISTEMA ACADÉMICO

Consultar notas de un curso

Estudiante

(f rom Actors)

Mantener información del estudiante

Cerrar un curso

Mantener información del profesor

Profesor

(f rom Actors)

Registrar notas de un curso

Consultar horario de exámenes

Validar acceso

Usuario

(f rom Actors)

Consultar horarios de cursos

37

Page 38: Sesión 07- Modelado de Requerimientos

38

La universidad quiere automatizar su sistema de

matrícula de cursos de verano.

Un Empleado inicializa la oferta de cursos ofrecidos

para el verano. Un mismo curso tiene varias ofertas

(secciones).

Durante un cierto período de tiempo, después de que

se haya definido la oferta de cursos, los estudiantes

pueden utilizar el sistema para añadir o eliminar cursos

a matricular. Los alumnos seleccionan 4 cursos

obligatorios y 2 cursos electivos.

Los profesores pueden utilizar el sistema para obtener

las listas de alumnos matriculados en su curso.

Los usuarios del sistema de matrícula acceden a él

mediante un login y una password que le es asignada.

EJEMPLO: SISTEMA DE MATRICULA

Page 39: Sesión 07- Modelado de Requerimientos

•Actores :

• Empleado

• Estudiante

• Profesor

•Casos de uso

• Ingresar Oferta de cursos

• Añadir o Eliminar Curso

• Obtener Listado de Alumnos

EJEMPLO: SISTEMA DE MATRICULA

39

Page 40: Sesión 07- Modelado de Requerimientos

EmpleadoRegistrar Curriculum

Registrar CursoAlumno

Profesor

Obtener Listado

Diagrama de casos de uso

EJEMPLO: SISTEMA DE MATRICULA

40

Page 41: Sesión 07- Modelado de Requerimientos

41

Caso de uso : Ingresar oferta de cursos

Actor : Empleado

Precondición : Empleado ha sido admitido como usuario

Poscondición : Se ha registrado la oferta de cursos

Flujo Básico

Actor1.El C.U. comienza cuando

Empleado Indica “Ingresar oferta”

2.Ingresa Código de Curso

3. Ingresa Sección, Horario y

Aula

4. Repite 2 a 3 por cada curso

5. Indica “Guardar”

Sistema1. El sistema muestra formulario

“Ingresar oferta”

2.Muestra nombre del curso

3.Verifica aula disponible y horario

sin cruce

4. Repite 2 a 3 por cada curso

5. Muestra mensaje de

confirmación y el C.U. termina.

Flujos Alternativos

1.

2.

EJEMPLO: SISTEMA DE MATRICULA

Descripción del Caso de uso: Ingresar Oferta de Cursos

Page 42: Sesión 07- Modelado de Requerimientos

42

CASO DE ESTUDIOSISTEMA DE BIBLIOTECA: Se trata de gestionar los préstamos de libros de una

biblioteca en la que se va a estudiar exclusivamente el funcionamiento de las

peticiones y devoluciones de libros.

Petición de libros

Un usuario puede realizar una petición de uno o más libros a la

biblioteca. Para ello, es necesario presentar, el carnet de usuario

de la biblioteca y una ficha en la que se detallan los libros

pedidos. Puede haber varios tipos de préstamo (de sala,

colaborador, proyecto fin carrera, doctorado) en función de los

cuales el usuario puede disponer de los ejemplares durante un

período de tiempo específico, (SALA :El día de la petición,

COLABORADOR: Una semana, PROYECTO FIN CARRERA;

Quince días y DOCTORADO: Un mes).

Una vez entregados el carnet y la ficha, el sistema comprobará y

aceptará la petición de los libros solicitados siempre que pueda

satisfacer la petición, es decir, cuando haya ejemplares

disponibles. Si se acepta la petición, se actualiza el número de

unidades de los libros de la biblioteca y se guarda la ficha de

préstamo.

Page 43: Sesión 07- Modelado de Requerimientos

43

...CASO DE ESTUDIO

Devoluciones de libros

Un usuario no puede realizar más peticiones hasta que no haya

efectuado todas las devoluciones de la petición anterior. El usuario,

para hacer la petición, necesita el carnet, que no se le entrega hasta

que no haya devuelto todos los libros. Sí puede hacer una devolución

parcial de los libros.

Cuando un usuario realice una devolución, el sistema actualizará el

stock de libros y comprobará la fecha de devolución de cada ejemplar

para estudiar, en el caso de que la devolución se haga fuera de

tiempo, la imposición de una sanción que tiene un coste de X ud.

monetarias por cada ejemplar y días de retraso en la devolución. En

este caso, la sanción se emite cuando el usuario entrega el último

ejemplar.

Page 44: Sesión 07- Modelado de Requerimientos

MUCHAS GRACIAS!!! 44