ANALISIS Y DISEO DE SISTEMAS I GUIA LABORATORIO 07: MODELO DE REQUERIMIENTOS DOCENTE:

SEMESTRE: ING. LUIS ALBERTO SOTA ORELLANA ING. MONICA MARCA AIMA ING. NOVA ACUA 2011 II

1. MARCO TEORICO Del modelo de negocios al modelo de requerimientos Los actores del negocio son candidatos a ser actores en ste modelo. Los trabajadores del negocio tambin son candidatos a ser actores en ste modelo. Cul es el Propsito de la captura de requerimientos? El esfuerzo principal de este flujo es desarrollar un modelo del sistema que se va a construir y la utilizacin 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 lmites del sistema. Ayuda a entender al diseador 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 caractersticas de los casos de uso, y tambin realiza el diagrama de clases de anlisis. El arquitecto identifica los casos de uso relevantes arquitectnicamente hablando, para proporcionar entradas a la priorizacin de los casos de uso. Los especificadores de casos de uso describen todos los casos de uso priorizados. Los diseadores sugieren interfaces de usuario adecuadas para cada actor basndose en los casos de uso. Pasos para realizar ste modelo Definir a los actores candidatos: Sern extrados del modelo de negocio. Debe ser creado en Use Case Model como paquete. Definir los casos de uso candidatos: Sern extrados del modelo de negocio. Debe ser creado en Use Case Model como paquete. Obtener una lista de requerimientos candidatos llamada tambin lista de caractersticas: son los requerimientos candidatos que podemos elegir implementar en la versin actual o ha desarrollar en una versin futura.

La lista de caractersticas debe indicar: a. El nombre del requerimiento que no es otra cosa que los CASOS DE USO funcionales, b. Una explicacin o descripcin breve de dicho requerimiento, c. La prioridad (crtica, importante o accesoria), d. El nivel de riesgo asociado a la implementacin (crtico, significativo u ordinario), e. El estado (declarado, aprobado, incorporado o validado), f. El costo estimado de implementacin (en trminos 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 comn del sistema, y es importante definir con claridad los trminos utilizados en el sistema de manera propia. Por ejemplo a lo mismo le pueden llamar de diferentes modos: item o producto o mercadera o artculo se pueden referir a lo mismo como no. Realizar la descripcin 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 inters de los usuarios. Los diseadores de interfaz de usuario sugieren interfaces de usuario adecuadas para cada actor basndose 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 arquitectnicamente hablando, para proporcionar entradas a la priorizacin 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 Case) Es una secuencia de acciones realizadas por el sistema que producen un 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 relacin permitida entre los actores es la Relacin de Generalizacin.

El actor A hereda el comportamiento de B Relaciones entre un actor y un caso de uso La nica relacin permitida es una Asociacin y se le conoce como Relacin de Comunicacin o <<comunicates>>.
<<communicate>>

Caso de uso

El actor A participa en el caso de uso Relaciones entre casos de uso: Pueden ser de tres tipos: a. Relacin de generalizacin: El Caso de Uso de A hereda la especificacin del Caso de Uso B.

b. Relacin <<include>>: El caso de uso A siempre incluye (o usa) el comportamiento de B.

<<include>>

c. Relacin <<extend>>: El caso de uso B, extiende al caso de uso A. B ocurre en casos especiales para extender A.
<<extend>>

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 tambin son candidatos a ser actores en ste modelo. SEGUNDO PASO: DEFINIR LOS CASOS DE USO CANDIDATOS Segn 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. Ntese que, de acuerdo con la definicin de caso de uso, no todas las actividades del diagrama de proceso sern consideradas como casos de uso, sino solamente aquellas que sean de valor para algn actor. TERCER PASO: OBTENER UNA LISTA DE REQUERIMIENTOS CANDIDATOS. Son los requerimientos candidatos que podemos elegir implementar en la versin actual o ha desarrollar en una versin futura. La lista de caractersticas debe indicar: El nombre del requerimiento que no es otra cosa que los CASOS DE USO. Una explicacin o descripcin breve de dicho requerimiento. La prioridad (crtica, importante o accesoria). El nivel de riesgo asociado a la implementacin (crtico, significativo u ordinario). El estado (declarado, aprobado, incorporado o validado). El costo estimado de implementacin (en trminos 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: Propsito: Resumen: La prioridad: Nivel de riesgo: Estado: crtica, importante o accesoria crtico, significativo u ordinario declarado, aprobado, incorporado o validado

CASO DE USO EXTENDIDO

Nombre: Actores: Propsito: Resumen: Curso normal de los eventos Accin 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 inters de los usuarios. Los diseadores de interfaz de usuario sugieren interfaces de usuario adecuadas para cada actor basndose en los casos de uso. SEXTO PASO: SIGNIFICATIVOS. OBETENER 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)arquitectnicamente hablando, para proporcionar entradas a la priorizacin 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 ITERACIN 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.