ANALISIS Y DISEÑO DE SISTEMAS I GUIA LABORATORIO 07: MODELO DE REQUERIMIENTOS DOCENTE: SEMESTRE:
ING. LUIS ALBERTO SOTA ORELLANA ING. MONICA MARCA AIMA ING. NOVA ACUÑA 2011– II
1. MARCO ARCO TEOR EORICO ICO Del modelo de negocios al modelo de requerimientos
Los actores del negocio son candidatos a ser actores en éste modelo. Los trabajadores del negocio también son candidatos a ser actores en éste modelo.
¿Cuál es el Propósito de la captura de requerimientos?
El esfuerzo principal de este flujo es desarrollar un modelo del sistema que se va a construir y la utilización de los casos de uso en una forma adecuada para crear este modelo. Es establecer un acuerdo con el cliente y usuarios en lo que el sistema debe hacer. Permite definir los límites del sistema. Ayuda a entender al diseñador los requerimientos del sistema. Permite definir la interfaz de acuerdo a las necesidades y metas de los usuarios.
Trabajadores en la captura de requisitos El analista de sistemas ejecuta la actividad de desarrollar modelos de casos de uso capturando todos los requisitos que son entradas del flujo de trabajo, es decir: la lista de características de los casos de uso, y también realiza el diagrama de clases de análisis.
El arquitecto identifica los casos de uso relevantes arquitectónicamente hablando, para proporcionar proporcionar entradas entradas a la priorización priorización de los casos casos de uso. uso.
Los especificadores de casos de uso describen todos los casos de uso priorizados. Los diseñadores sugieren interfaces de usuario adecuadas para cada actor basándose en los casos de uso.
Pasos para realizar éste modelo Definir a los actores candidatos: Serán extraídos del modelo de negocio. Debe ser creado en Use Case Model como paquete. Definir los casos de uso candidatos: Serán extraídos del modelo de negocio. Debe ser creado en Use Case Model como paquete.
Obten Obtener er una list listaa de requeri requerimi mien ento toss candid candidat atos os llama llamada da tambié también n lista lista de características: son los requerimientos candidatos que podemos elegir implementar en la versión actual o ha desarrollar en una versión futura.
La lista de características debe indicar: a. El nombre del requerimiento que no es otra cosa que los CASOS DE USO funcionales, b. Una explicación o descripción breve de dicho requerimiento, c. La prioridad (crítica, importante o accesoria), d. El nivel de riesgo asociado a la implementación (crítico, significativo u ordinario), e. El estado (declarado, aprobado, incorporado o validado), f. El costo estimado de implementación (en términos de tipos de recursos y horas hombre)(antes 150 soles y demora 3 horas y con el software costara 100 soles y demora 1 hora).
El glosario: es la captura de vocabulario común del sistema, y es importante definir con claridad los términos utilizados en el sistema de manera propia. Por ejemplo a lo mismo le pueden llamar de diferentes modos: item o producto o mercadería o artículo se pueden referir a lo mismo como no.
Realizar la descripción a detalle de los casos de uso identificados como prioritarios: Los especificadores de requerimientos o de casos de uso describen todos los casos de uso priorizados a detalle.
Realizar el prototipo de la interfaz de usuario: de acuerdo a los requerimientos capturados y el interés de los usuarios. Los diseñadores de interfaz de usuario sugieren interfaces de usuario adecuadas para cada actor basándose en los casos de uso.
Obtener los casos de uso arquitecturalmente significativos: es un subconjunto de casos de uso que influyen fuertemente en la arquitectura. El arquitecto identifica los casos de uso relevantes arquitectónicamente hablando, para proporcionar entradas a la priorización de los casos de uso expresado en un diagrama de C.U
Revisar los requerimientos: El revisor de requerimientos es el encargado de revisar todos los artefactos producidos durante la captura de requisitos.
Diagrama de casos de uso Un Diagrama de Casos de Uso representa lo que hace el sistema y como se relaciona con su entorno. Representa los distintos requerimientos que hacen los usuarios de un sistema. Un diagrama de casos de uso esta compuesto por: • • •
Casos de uso. Actores. Relaciones entre ellos
Caso de Uso ( Use producen
un
Case)
Es una secuencia de acciones realizadas por el sistema que resultado observable y valioso para alguien en particular.
Nombre de caso de uso
Actor: Un actor es un conjunto externo uniforme de personas, sistemas, o cosas que solicita un servicio al sistema que estamos modelando.
Nombre
Relaciones entre los elementos Relaciones entre actores La única relación permitida entre los actores es la Relación de Generalización.
A
B
El actor A hereda el comportamiento de B
Relaciones entre un actor y un caso de uso La única relación permitida es una Asociación y se le conoce como Relación de Comunicación o <>. <>
Caso de uso
A
El actor A participa en el caso de uso
Relaciones entre casos de uso: Pueden ser de tres tipos: a. Relación de generalización: El Caso de Uso de A hereda la especificación del Caso de Uso B.
A
B
b. Relación <>: El caso de uso A siempre incluye (o usa) el comportamiento de B. <>
A
B
c. Relación <>: El caso de uso B, extiende al caso de uso A. B ocurre en casos especiales para extender A. <>
A
B
2. 2. FLUJO DE TRABAJO PRIMER PASO: DEFINIR LOS ACTORES CANDIDATOS
Los actores del negocio son candidatos a ser actores en éste modelo. Los trabajadores del negocio también son candidatos a ser actores en éste modelo.
SEGUNDO PASO: DEFINIR LOS CASOS DE USO CANDIDATOS Según el procedimiento, las actividades del diagrama de proceso tienen el nivel de granularidad adecuado para ser asociadas a un caso de uso del sistema. De esta manera, crearemos un caso de uso del sistema por cada actividad del diagrama de proceso que deba ser soportada por el sistema software. Por tanto, el rol que lleva a cabo la actividad será el actor principal del caso de uso. Nótese que, de acuerdo con la definición de caso de uso, no todas las actividades del diagrama de proceso serán consideradas como casos de uso, sino solamente aquellas que sean de valor para algún actor. TERCER PASO: OBTENER UNA LISTA DE REQUERIMIENTOS CANDIDATOS.
Son los requerimientos candidatos que podemos elegir implementar en la versión actual o ha desarrollar en una versión futura. La lista de características debe indicar: El nombre del requerimiento que no es otra cosa que los CASOS DE USO. Una explicación o descripción breve de dicho requerimiento. La prioridad (crítica, importante o accesoria). El nivel de riesgo asociado a la implementación (crítico, significativo u ordinario). El estado (declarado, aprobado, incorporado o validado). El costo estimado de implementación (en términos de tipos de recursos y horas hombre).
CUARTO PASO: REALIZAR LA DESCRIPCION A DETALLE DE LOS CASOS DE USOS IDENTIFICADOS COMO PRIORITARIOS – FORMATO EXTENDIDO. CASO DE USO DE ALTO NIVEL
Nombre: Actores: Propósito: Resumen: La prioridad:
crítica, importante o accesoria
Nivel de riesgo:
crítico, significativo u ordinario
Estado:
declarado, aprobado, incorporado o validado
CASO DE USO EXTENDIDO
Nombre: Actores: Propósito: Resumen: Curso normal de los eventos Acción de los actores
Respuesta del Sistema
Cursos Alternos
QUINTO PASO: REALIZAR EL PROTOTIPO DE LA INTERFAZ DEL USUARIO.
De acuerdo a los requerimientos capturados y el interés de los usuarios. Los diseñadores de interfaz de usuario sugieren interfaces de usuario adecuadas para cada actor basándose en los casos de uso.
SEXTO PASO: OBETENER SIGNIFICATIVOS.
LOS
CASOS
DE
USO
ARQUITECTURALMENTE
Es un subconjunto de casos de uso que influyen fuertemente en la arquitectura. El arquitecto identifica los casos de uso relevantes (FUNCIONALES)arquitectónicamente hablando, para proporcionar entradas a la priorización de los casos de uso expresado en un diagrama de Casos de Uso.
SETIMO PASO: REVISAR LOS REQUERIMIENTOS.
El revisor de requerimientos es el encargado de revisar todos los artefactos producidos durante la captura de requisitos. 3. DESARROLLO DE LA PRACTICA
a. I ITERACIÓN DE LA FASE DE INICIO i. DIAGRAMA DE CASOS DE USO DEL NEGOCIO DE LA FABRICA DE PRENDAS DEPORTIVAS WALON
ii. FORMATO DE DESCRIPCION DEL CASO DE USO DEL NEGOCIO
ii. DIAGRAMA DE ACTIVIDAD DEL CASO DE USO DEL NEGOCIO
iii. DIAGRAMA DE CASOS DE USO DE REQUERIMIENTOS
EJERCICIO: 1. MODELAR EL DIAGRAMA DE CASOS DE USO DE REQUERIMIENTOS DEL SISTEMA DE MATRICULAS DE LA UAC.
