INGENIERIA DE SOFTWARE III

INGENIERIA DE REQUERIMIENTOS CASOS DE USO

Identificacin de actores y casos de uso

Objetivos Delimitar el sistema y su entorno. Esbozar quin y qu (actores) interactuarn con el sistema, y qu funcionalidad (casos de uso) se espera del sistema. Capturar y definir un glosario de trminos comunes esenciales para poder describir detalladamente los casos de uso del sistema. Es la actividad ms decisiva para obtener adecuadamente los requisitos. Responsabilidad del analista de sistemas

Identificacin de actores y casos de uso

Actividades Establecer el lmite del sistema: solo software, hardware y software como un todo, lo utiliza una persona, una organizacin,... Encontrar actores principales: los que tienen objetivos de usuario que se satisfacen mediante el uso de los servicios del sistema. Para cada actor, identificar sus objetivos de usuario Definir los casos de uso que satisfagan los objetivos de usuario. Nombrarlos de acuerdo con sus objetivos. Normalmente los casos de uso del nivel de objetivo de usuario se correspondern uno a uno con los objetivos de usuario. Describir brevemente (descripcin informal) cada caso de uso

Identificar Actores
Identificar actores principales y objetivos adems de actores principales y objetivos obvios, se pueden utilizar diferentes preguntas para identificar otros menos evidentes: quin arranca y detiene el sistema? quin administra el sistema? quin gestiona los usuarios y la seguridad? es un actor el tiempo porque el sistema hace algo como respuesta a un evento de tiempo? quin evala la actividad o el rendimiento del sistema?

Identificar Actores
Tipos de actores actor principal: tiene objetivos de usuario que se satisfacen mediante el uso de los servicios del sistema (por ejemplo, el cajero) se identifica para encontrar los objetivos de usuario, que dirigen los casos de uso actor de apoyo: proporciona un servicio (por ejemplo, informacin) al sistema en desarrollo. Por ejemplo, el servicio de autorizacin de pago). Normalmente es un sistema informtico, pero puede ser una organizacin o una persona se identifica para clarificar las interfaces externas y los protocolos actor pasivo: est interesado en el comportamiento del caso de uso, pero no es principal ni de apoyo. Por ejemplo, la Agencia Tributaria. se identifica para asegurar que todos los intereses necesarios se han identificado y satisfecho

Identificar Casos de Uso

Escenario (o instancia de caso de uso) Es una descripcin narrativa de lo que la gente hace y experimenta cuando trata de utilizar una aplicacin informtica, es decir, una secuencia especfica de acciones e interacciones entre los actores y el sistema objeto de estudio. Descripcin concreta e informal de una sola caracterstica del sistema, desde el punto de vista de un solo actor. Los analistas y los usuarios escriben y refinan diversos escenarios para comprender mejor lo que debe hacer el sistema.

Identificar Casos de Uso

Identificacin de escenarios qu tareas necesita el actor que realice el sistema? qu informacin consulta el actor? quin crea esos datos? se pueden modificar? quin puede hacerlo? qu cambios externos necesita informar el actor al sistema? cundo y con qu frecuencia? de qu eventos necesita el actor que le informe el sistema? cundo y con qu frecuencia?

Identificar Casos de Uso

Caso de uso Especifica todos los escenarios posibles para una determinada funcionalidad. Es iniciado por un actor. Puede interactuar con otros actores. Representa un flujo de eventos completo a travs del sistema, es decir, describe una serie de interacciones relacionadas que resultan de la inicializacin del caso de uso.

Identificar Casos de Uso

Preguntas clave: Cules son las tareas del actor? Qu informacin 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?

Cada uno de estas cosas que el actor desee hacer con el sistema se convierte en un Caso de Uso. Ejemplo: Actor: Vendedor Tareas: Ingresar Orden de Venta Revisar Crdito del Cliente

Diagrama de Casos de Uso

Representa el contexto del sistema:
Lmites del sistema. Qu permanece fuera del sistema. Cmo se utiliza el sistema. Resume el comportamiento de un sistema y sus actores.

Sugerencias en la realizacin de diagramas de casos de uso

En diagramas de contexto, utilizar nicamente casos de uso de nivel de objetivos de usuario. Mostrar los actores que representen sistemas informticos con una notacin alternativa a los actores humanos. Situar los actores humanos a la izquierda y los de apoyo a la derecha. Lo realmente importante es la descripcin de los casos de uso, y no tanto los diagramas.

Diagrama de Casos de Uso

< <inic a>> i P rocesar V enta Cajero Servicio de Autorizacin de C rdito <<Actor>> Sis tema de Clculo de Impuestos notacin alternativa para un actor que repres enta a un s tema informtico is

<<inicia> >

Gestionar Devoluciones

< ctor> <A > Sis tema de Control de Ventas

Abrir C aja

< <Actor>> Sis tema de Contabilidad

Analizar Actividad <<Actor>> Sistema de Recurs os Humanos

Ges tionar Seguridad

Adminis trador del Sis tema Gestionar Usuarios

D tribuir cajeros en cajas is Jefe de C ajas

...

Casos de uso en el proceso unificado

Desarrollo dirigido por casos de uso Los requisitos se recogen principalmente en el Modelo de Casos de Uso. Los casos de uso son parte importante de la planificacin de las iteraciones. Las realizaciones de casos de uso dirigen el diseo, es decir, el equipo disea objetos y subsistemas que colaboran para ejecutar o realizar los casos de uso. El trabajo con los casos de uso se realiza a lo largo de las diversas iteraciones.

Casos de uso en el proceso unificado

Casos de uso en la elaboracin

Fase de mltiples iteraciones de duracin fija. Se construyen incrementalmente partes del sistema arriesgadas, de alto valor o significativas para la arquitectura. Se identifican y clarifican la mayora de los requisitos. Retroalimentacin de las fases de diseo e implementacin. Se pueden realizar talleres de requisitos en cada iteracin:
Se refinan los requisitos principales, que son inestables en las primeras iteraciones, estabilizndose en las ltimas.

No se estudian todos los casos de uso: se priorizan.

Escritura y reescritura de la mayora de los casos de uso, en formato completo.

Al final de la fase de elaboracin

Quedan descritos en detalle entre el 80 y el 90% de los casos de uso.

Priorizacin de casos de uso

Determinar cules son necesarios para el desarrollo en las primeras iteraciones y cules pueden dejarse para posteriores iteraciones. Cuestiones a tener en cuenta:
Casos de uso con dificultad de desarrollo. Casos de uso imprescindibles para la puesta en marcha del sistema. Organizacin del desarrollo incremental. Disponibilidad de equipo de desarrollo.

Se revisa la priorizacin con el jefe de proyecto y se utiliza como entrada para la planificacin de cada iteracin del proyecto.

Tipos de caso de uso

Primario: representan un proceso comn. Secundario: representa un proceso que ocurre raramente o en menor numero de ocasiones. Opcional: representa procesos que pueden o no ocurrir.

Detallar los casos de uso

Objetivo principal: describir su flujo de sucesos en detalle
Cmo comienza. Cmo termina. Cmo interactan con los actores.

Se detalla paso a paso la secuencia de acciones del caso de uso. Se trabaja estrechamente con los usuarios reales de los casos de uso. Resultado: descripcin detallada mediante
Texto Diagramas

Detallar los casos de uso

Caso de uso: Actores: Descripcin: Pre-Condicin: Post-Condicin: Flujo principal: Nombre del caso de uso. Actores que participan en el caso de uso Una breve descripcin del caso de uso. Descripcin de las condiciones que deben ser cumplidas antes del que el caso de uso sea invocado. Descripcin de que es lo que pasa cuando finaliza el caso de uso. Una lista de las interacciones del sistema que toman lugar en el ms comn escenario.

Flujo (s) Alternativos: Una descripcin de los posibles interacciones alternativas. Flujo (s) de Excepcin:Descripcin de los posibles escenarios donde ocurre un evento inesperado.

Plantilla para la documentacin de los casos de uso

Detallar los casos de uso

Nombre del caso de uso: Actores participantes: Pagar Factura Comprador (inicia) Vendedor Sistema de cuentas bancarias

Precondicin: el comprador ha recibido los bienes y servicios y al menos una factura del sistema. El comprador ahora planifica el pago de las facturas Flujo de eventos: Camino bsico

El comprador invoca al caso de uso para comenzar a hojear las facturas recibidas del sistema. El sistema verifica que el contenido de cada factura es consistente con las confirmaciones de pedido recibidas anteriormente (como parte del caso de uso Confirmar Pedido) y as indicrselo al comprador. La confirmacin de pedido describe qu elementos sern enviados, cundo, dnde y a qu precio. El comprador decide planificar una factura para pagarla por banco, y el sistema genera una peticin e pago para transferir el dinero a la cuenta del vendedor. Hay que tener en cuenta que un comprador no puede planificar el pago de la misma factura dos veces [A2]. Ms tarde, si hay suficiente dinero en la cuenta del comprador, se hace un pago mediante transaccin en la fecha planificada. Durante la transaccin, el dinero se transfiere de la cuenta del comprador a la del vendedor, como se describe en el caso de uso abstracto Realizar Transaccin (que es utilizado por Pagar Factura). Tanto el comprador como el vendedor tienen notificacin del resultado de la transaccin. El banco recoge unos cargos por la transaccin, que se retiran de la cuenta del comprador [A3]. La instancia del caso de uso finaliza.

Caminos alternativos

[A2] En el paso 2, el comprador puede, en cambio, pedir al sistema que devuelva un rechazo de factura al vendedor. [A3] En el paso 3, si no hay suficiente dinero en la cuenta, el caso de uso cancelar el pago y se lo notificar al comprador.

Postcondicin: la instancia del caso de uso termina cuando la factura ha sido pagada o cuando el pago de la factura ha sido cancelado y no se ha hecho ninguna transferencia.

Estructurar el modelo de casos de uso

Objetivos Extraer descripciones de funcionalidad (de casos de uso) generales y compartidas que pueden ser utilizadas por casos de uso ms especficos. Extraer descripciones de funcionalidad (de casos de uso) adicionales u opcionales que pueden extender casos de uso ms especficos (relaciones de extensin). Extraer descripciones de funcionalidad (de casos de uso) adicionales e incondicionales incluidas en la ejecucin de casos de uso especficos (relaciones de inclusin).

Estructurar el modelo de casos de uso

Generalizacin
Simplifica la forma de trabajo y la comprensin del modelo de casos de uso. Permite reutilizar casos de uso semifabricados cuando se renen casos de uso terminados requeridos por el usuario (caso de uso concreto). El caso de uso semifabricado existe solamente para que otros casos de uso lo reutilicen y se les llama casos de uso abstractos.

No pueden instanciarse por s mismos. Una instancia de un caso de uso concreto tambin exhibe el comportamiento especificado por un caso de uso abstracto que lo reutiliza.

Comprador

Pagar factura

Vendedor

Ejecutar transaccin

Estructurar el modelo de casos de uso

Relaciones de extensin entre casos de uso
Un caso de uso extiende otro caso de uso si ste puede incluir el comportamiento del primero bajo determinadas condiciones. Ventajas de separar el flujo excepcional y opcional con respecto al caso de uso bsico

El caso de uso bsico se hace ms pequeo y comprensible. Se distingue entre el caso comn y el excepcional, permitiendo que los desarrolladores los traten de forma diferente.

Ambos son casos de uso completos por s mismos, con condicin inicial y final, y comprensibles por el usuario. Regla general: utilizar relaciones de extensin para comportamientos excepcionales, opcionales o que rara vez ocurren.

Comprador

Pagar factura

Vendedor

<<extend>>

Ejecutar transaccin

Pagar cargos saldo deudor

Estructurar el modelo de casos de uso

Relaciones de inclusin entre casos de uso Permiten dividir las redundancias y reutilizar casos de uso. El comportamiento slo debe dividirse en casos de uso separados cuando es compartido por dos o ms casos de uso. No conviene dividir en exceso (especificacin confusa). Regla general: utilizar relaciones de inclusin para comportamientos que se comparten entre dos o ms casos de uso.

Ampliar prstamo <<includ e>>

<<include>> Prestatari o Libro Comprobar reservas

Tomar li bro prestad o