MODELO DE REQUISITOSIngeniería de SoftwareL.I. Natividad Juárez González

UNIDAD 2. INGENIERÍA DE REQUISITOS 1

PROCESO DE DESARROLLO DE SOFTWARE

Requisitos

Requerimientos del usuario.

Análisis

La funcionalidad especificada por el modelo de casos de uso se estructura en el modelo de análisis, que es estable con respecto a cambios, lo que lo hace un modelo lógico independiente de la implementación.

UNIDAD 2. INGENIERÍA DE REQUISITOS 2

PROCESO DE DESARROLLO DE SOFTWARE

Diseño

La funcionalidad de los casos de uso, ya estructurada por el análisis, la realiza el diseño, adaptándose al ambiente de implementación real.

Implementación

Código Fuente.

Pruebas

Pruebas de unitarias y de integración.

UNIDAD 2. INGENIERÍA DE REQUISITOS 3

PROCESO DE DESARROLLO DE SOFTWARE

Modelo de Requisitos Modelo de Análisis

Modelo de Diseño

class...

Modelo de Implementación

UNIDAD 2. INGENIERÍA DE REQUISITOS 4

OK

OK

falla

Modelo de Pruebas

MODELO DE REQUISITOS

El modelo de requisitos tiene como objetivo delimitar el sistema y capturar la funcionalidad que ofrecerá desde la perspectiva del usuario.

El modelo de requisitos es el primer modelo en desarrollarse y es la base para formar todos los demás modelos en el desarrollo de software.

UNIDAD 2. INGENIERÍA DE REQUISITOS 5

MODELO DE REQUISITOS

En la metodología Objectory(Jacobson), el modelo de requisitos consta de tresmodelos:

Comportamiento

(Casos de Uso)

Información

(Dominio del Problema)

Presentación

(Interfaces)

UNIDAD 2. INGENIERÍA DE REQUISITOS 6

MODELO DE COMPORTAMIENTO

El modelo de comportamiento, especifica la funcionalidadque ofrece el sistema desde el punto de vista del usuario.

Este modelo está basado directamente en el Modelo de Casos de Uso.

UNIDAD 2. INGENIERÍA DE REQUISITOS 7

MODELO DE COMPORTAMIENTO:MODELO DE CASOS DE USO

El Modelo de Casos de Uso describe las funcionalidades del sistema a partir de las interacciones del usuario.

Hacer Reservación

Consultar

Información

Usuario

Base de Datos de Usuarios

Registrar Usuario

Sistema

Base de Datos de Reservaciones

UNIDAD 2. INGENIERÍA DE REQUISITOS 8

MODELO DE CASOS DE USO

Actores:

•Primaros: Son la razón principal de existencia del problema y rigen la secuencia lógica de ejecución del sistema.

•Secundarios: Actores que supervisan y apoyan al sistema y por lo general son máquinas o sistemas externos.

UNIDAD 2. INGENIERÍA DE REQUISITOS 9

MODELO DE CASOS DE USO

Delimitación del sistema según los Actores: (Ejemplo)

Usuario

Base de Datos Reservaciones

Base de Datos de Registros

Sistema de

Reservaciones

de Vuelos

UNIDAD 2. INGENIERÍA DE REQUISITOS 10

Usuario

Base de Datos ReservacionesBase de Datos de Registros

Sistema de

Reservaciones

de Vuelos

Base de Datos

Cuando diferentes actores

realizan roles similares, pueden

heredar de un actor abstracto

común.

MODELO DE CASOS DE USO

Actores:

Actor Nombre del Actor.

Casos de Uso Nombre de los casos de usos en los

cuales participa.

Tipo Primario o secundario.

Descripción Breve descripción del actor.

UNIDAD 2. INGENIERÍA DE REQUISITOS 11

MODELO DE CASOS DE USO

Actores:

Actor Usuario.

Casos de Uso Validar Usuario, Registrar Usuario,

Consultar Información, Hacer

Reservación, Pagar Reservación.

Tipo Primario.

Descripción Es el actor principal y representa

cualquier persona que desee utilizar el

sistema.

UNIDAD 2. INGENIERÍA DE REQUISITOS 12

MODELO DE CASOS DE USO

Casos de Uso:

Los casos de uso representan las funcionalidades del sistema.

Cada caso de uso define una forma particular de usar el sistema.

Un caso de uso constituye un flujo completo de eventos que especifican la interacción entre el actor y el sistema.

Las diferentes instancias de los casos de uso se denomina escenario.

UNIDAD 2. INGENIERÍA DE REQUISITOS 13

MODELO DE CASOS DE USO

Para identificar los casos de uso:

Se parte de la descripción del problema.

Surgen preguntas como:

¿Cuáles son las tareas principales de cada actor?

¿Tendrá el actor que consultar y modificar información del sistema?

¿Deberá el actor informar al sistema sobre cambios externos?

¿Desea el actor ser informado sobre cambios inesperados?

UNIDAD 2. INGENIERÍA DE REQUISITOS 14

MODELO DE CASOS DE USO

Relaciones entre casos de uso: include, extend.

Validar Usuario

Pagar ReservaciónHacer Reservación

Consultar

Información

Registrar Usuario

<<include>>

<<include>>

<<include>><<extend>>

UNIDAD 2. INGENIERÍA DE REQUISITOS 15

MODELO DE CASOS DE USO

Casos de Uso:

Caso de Uso Nombre del caso de uso.

Actores Actores primarios y secundarios que

interaccionan con el caso de uso.

Tipo Tipo de flujo: Básico, inclusión,

extensión, generalización.

Propósito Razón de ser del caso de uso.

Resumen Resumen del caso de uso.

Precondiciones Condiciones que deben satisfacerse

para ejecutar el caso de uso.

UNIDAD 2. INGENIERÍA DE REQUISITOS 16

MODELO DE CASOS DE USO

Casos de Uso:

Flujo Principal El flujo de eventos más importante del

caso de usos, donde dependiendo de

las acciones de los actores, se

continuará con algún otro sub flujo.

Subflujos Los flujos secundarios de caso de uso,

numerados como (S-1), (S-2), etc.

Excepciones Excepciones que pueden ocurrir

durante el caso de uso, numerados (E-

1)…

UNIDAD 2. INGENIERÍA DE REQUISITOS 17

MODELO DE CASOS DE USO

Casos de Uso: (Ejemplo)

Caso de Uso Registrar Usuario.

Actores Usuario, Base de Datos de Usuarios.

Tipo Básico.

Propósito Permitir a un usuario registrarse en el

sistema.

Resumen El usuario inicia este caso de uso. Ofrece la

funcionalidad para crear, modificar y eliminar

el registro de un usuario.

Precondicione

s

Todos los sub flujos con excepción de Crear

Registro Usuario (S-1), requieren ejecutar

inicialmente el caso de uso Validar Usuario.

UNIDAD 2. INGENIERÍA DE REQUISITOS 18

MODELO DE CASOS DE USO

Casos de Uso:

Flujo Principal Se ejecuta el caso de uso Validar Usuario.

Dependiendo de las opciones seleccionadas

por el Usuario, se continuará con los diversos

sub flujos de este caso de uso.

Subflujos S-1 Crear Registro Usuario

Se presenta al usuario la pantalla de “Crear

usuario” que incluye nombre, apellido, cédula,

dirección, teléfono, login y password. El

usuario introduce sus datos y puede presionar

REGISTRAR O SALIR.

Si presiona REGISTRAR se crea el usuario

(E-1, E-2, E-3). Se continua con el sub flujo S-

3

UNIDAD 2. INGENIERÍA DE REQUISITOS 19

MODELO DE CASOS DE USO

Casos de Uso:

Subflujos Si presiona SALIR se saldrá del sistema.

--

S-2 Obtener Registro Usuario

El sistema obtiene el registro del usuario de la

Base de Datos de usuarios. Se continúa con S-

3.

--

S-3 Administrar Registro Usuario

Se muestran los datos del usuario, este podrá

seleccionar entre: ELIMINAR, ACTUALIZAR,

SALIR.

UNIDAD 2. INGENIERÍA DE REQUISITOS 20

MODELO DE CASOS DE USO

Casos de Uso:

Excepcion

es

E-1 Información Incompleta.

E-2 Registro ya existe.

E-3 Login incorrecto y/o password incorrecto.

UNIDAD 2. INGENIERÍA DE REQUISITOS 21

MODELO DE PRESENTACIÓN

El modelo de presentación o modelo de interfacesespecifica como interactúa el sistema con los actores externos al ejecutar los casos de uso.

UNIDAD 2. INGENIERÍA DE REQUISITOS 22

MODELO DE PRESENTACIÓN: MODELO DE INTERFACES

El modelo de interfaces describe la presentación de la información entre los actores y el sistema.

Se especifica en detalle como se verán las interfaces de usuario al ejecutar uno de los casos de uso.

Una estrategia interesante es un prototipo del sistema.

UNIDAD 2. INGENIERÍA DE REQUISITOS 23

MODELO DE INFORMACIÓN

El modelo de información o modelo del dominio del problema, especifica los aspectos estructurales de la aplicación en términos de objetos.

Este modelo permite identificar cuáles son los objetos relevantes del sistema, que permitirán guardar información de forma temporal o permanente.

Modelo de Diseño

UNIDAD 2. INGENIERÍA DE REQUISITOS 24

MODELO DE INFORMACIÓN:MODELO DEL DOMINIO DEL PROBLEMA

El modelo del dominio del problema define un modelo de clases del sistema.

El modelo de clases consiste en los objetos del dominio del problema.

El propósito principal del este modelo es formar una base común de entendimiento del desarrollo y no definir el sistema completo.

La inclusión de atributos y operaciones se colocan si es necesario para la mejor compresión del problema.

UNIDAD 2. INGENIERÍA DE REQUISITOS 25

MODELO DEL DOMINIO DEL PROBLEMA

-Fabricante

-Modelo

Avion

-Fila

-Letra

Asiento

-Numero

Vuelo

-Nombre

Aerolínea

-Clase

-Precio

-Impuestos

Tarifa

-Clave

Reservación

-Nombre

Pasajero

-Día

-Hora

Horario

Llegada Salida

*

*

*

*

*

*

UNIDAD 2. INGENIERÍA DE REQUISITOS 26