Modelo de Requisitos
-
Upload
dario-cubillos -
Category
Documents
-
view
218 -
download
1
description
Transcript of Modelo de Requisitos
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