Captura de los Requisitos como casos de Uso

Semana 9-10 Lic. Espinoza Robles.

Introduccin
El esfuerzo principal en la fase de requisitos es desarrollar un modelo del sistema que se va ha construir, y la utilizacin de los caso de uso es una forma de crear ese modelo. Esto es porque los requisitos funcionales se estructuran de manera natural mediante casos de uso. Los requisitos no funcionales restantes se mantienen en un documento aparte y se denomina requisitos adicionales.

 Los casos de uso proporcionan un medio intuitivo y sistemtico para capturar los requisitos funcionales. Los analistas se ven obligados a pensar en trminos de quien son los usuarios y que necesidades u objetivos de la empresa pueden cumplir. Pero el papel clave de los casos de uso es su direccin del resto del trabajo de desarrollo, lo que ha contribuido para su aceptacin general.

 El flujo de trabajo de los requisitos se describe en tres pasos

Los artefactos creados en el flujo de trabajo de los requisitos. Los trabajadores participantes en el flujo de trabajo de los requisitos. El flujo de trabajo de captura de requisitos, incluyendo cada actividad en mas detalle.

Artefactos
Analista de Sistemas Especificar Casos de uso

Mod.C.Uso

Glosario

Casos de Uso

Diseador De Interfaz de Usuario

Arquitecto

Prot. Interfaz de Usuario

Descripcin de la Arquit

 Los Artefactos que se utilizan en la captura de requisitos son el modelo de casos de uso, que incluye los casos de uso y actores. Tambin pueden haber otros tipos de artefactos como prototipos de Interfaz. Estos artefactos son importantes:
Para la descripcin formal de los casos de uso Facilita la identificacin de los casos de uso y su descripcin. Es importante para poder explicar los actores y casos de uso en relacin con otras construcciones de UML.

Artefacto: modelo de Casos de Uso.

El modelo de casos de uso permite que los desarrolladores de software y los clientes lleguen a un acuerdo sobre requisitos, y proporciona la entrada fundamental para el anlisis, diseo y prueba. Un modelo de casos de uso contiene actores, casos de uso y sus relaciones. Puede hacerse grande y difcil, de modo que es necesario algn medio de abordarlo en trozos mas pequeos.

 Artefacto: Actor
El modelo de casos de uso describe lo que hace que el sistema para cada tipo de usuario. Cada uno de estos se representa mediante uno o mas actores. Tambin se representan mediante actores uno o mas sistemas con el que interacta, incluyendo dispositivos externos. Por tanto los actores representan terceros fuera del sistema que colaboran con el.

 Los actores suelen corresponder con trabajadores (o actores del negocio). Cada rol define lo que hace el trabajador en un proceso de negocio. Los roles que desempea un trabajador pueden emplearse para obtener los roles que cumple un actor del sistema. Ej.. Actor: El sistema de pagos y facturacin interactan con un tipo de usuario que empleara el sistema para pedir bienes, confirmar pedidos, pagar facturas y dems, este tipo de usuario se representa mediante el Actor Comprador.

 Un actor juega un papel por cada caso de uso con el que colabora. Cada vez que un usuario interacta con el sistema, la instancia correspondiente del actor esta desarrollando ese papel. Una instancia de un actor es por tanto un usuario concreto que interacta con el sistema.

 Caso de Uso. Cada forma en que los actores usan el sistema se representan con un caso de uso . Los casos de uso son un fragmento de funcionalidad que el sistema ofrece para aportar un resultado de valor para sus actores. Es decir un caso de uso especifica una secuencia de acciones que el sistema puede llevar a cabo interactuando con sus actores.

 Ej.. El caso de uso Sacar Dinero. Permite a la instancia del actor cliente de banco el sacar dinero mediante un CA. Especifica las posibles instancias de ese caso de uso, es decir las diferentes formas validas de llevar a cabo el caso de uso y la interaccin con los actores implicados.

 Segn UML un caso de uso es un clasificador, lo cual quiere decir que tiene operaciones y atributos, por tanto su descripcin puede incluir diagramas de estados, diagramas de actividad, colaboracin y diagramas de secuencia. Los diagramas de estados especifican el ciclo de vida de las instancias de los casos de uso en terminos de estado y transiciones entre los estados.

 Una instancia de caso de uso es la realizacion (ejecucion) de un caso de uso, que interacta con instancias de actores, y ejecuta una secuencia de acciones. Esta secuencia se especifica en un diagrama de estados o un diagrama de actividades: es un camino a lo largo del caso de uso, parecido a lo siguiente:
1. La instancia del caso de uso se inicia y pasa al estado de comienzo. 2. El caso de uso es invocado por un mensaje externo de un actor.

 3. Transita a otro estado realizando una secuencia de acciones. Contiene clculos internos, seleccin de caminos, mensajes etc. 4. Queda a la espera (en un nuevo estado) de otro mensaje externo. 5. Es invocado otra vez por un nuevo mensaje, esto puede continuar sobre muchos estados.

La mayora de las veces es una instancia de actor la que invoca a la instancia del caso de uso. Los casos de uso tienen atributos, que son valores que una instancia de caso de uso manipula, por ejemplo el c.u. Sacar dinero posee atrib. Contrasea, la cuenta, cantidad a retirar.

 Las instancias de caso de uso no interactan con otras instancias de caso de uso, la nica interaccin que hay es entre instan. de actor e instancia, de casos de uso. Esto pues se busca que el modelo de casos de uso sea simple e intuitivo, para permitir fructferas discusiones con usuarios finales y evitar tratar con interfaces entre casos de uso, concurrencias y otros conflictos. Cada instancia de casos de uso es atmica es decir se ejecuta por completo. Por lo que su comportamiento puede interpretarse independiente del resto de casos de uso.

 Flujo de Sucesos Es la descripcin textual de la secuencia de acciones del caso de uso. Por tanto el flujo de sucesos especifica lo que el sistema hace cuando se lleva a cabo el caso de uso especificado. Tambin especifica como interacta el sistema con los actores cuando se lleva a cabo el caso de uso.

 Desde la perspectiva de la gestin, incluye un conjunto de secuencias de acciones que pueden ser modificadas, revisadas, diseadas, implementadas y probadas juntas y que pueden ser descritas como una seccin o subseccion del manual del usuario.

 Requisitos especiales.
Llamamos requisitos espaciales a una descripcin textual que agrupa todos los requisitos del tipo de los requisitos no funcionales sobre el caso de uso. Son fundamentalmente requisitos no funcionales relacionados con el caso de uso y que deben tratarse en flujo de trabajo posterior como anlisis, diseo, o implementacin.

Artefacto: descripcin de la arquitectura

La descripcin de la arquitectura contiene una vista de la arquitectura del modelo de caso de uso, que representa los casos de uso significativos para la arquitectura. Deber incluir los casos de uso que describa alguna funcionalidad importante y critica o implique algn requisito importante.

 Esta vista de arquitectura se utiliza como entrada cuando se priorizan los caso de uso para su desarrollo dentro de cada iteracin. Normalmente las realizaciones de casos de uso correspondiente pueden encontrarse en las vistas arquitectnicas de los modelos de anlisis y diseo.

Descripcin de la arquitectura

Vista de la arquitectura

Modelo de casos de uso

 Artefacto: Glosario
Podemos usar un glosario para definir trminos comunes importantes que los analistas y otros desarrolladores utilizan al describir el sistema. En muy til para alcanzar un consenso entre desarrolladores. Podemos obtener un glosario a partir de un modelo del negocio o un modelo del dominio, pero debido a que es menos formal es fcil de mantener, mas intuitivo para su uso y puede estar mas centrado en el sistema en lugar del contexto.

 Artefacto : Prototipo de Interfaz de Usuario No ayudan a comprender y especificar las iteraciones entre actores humanos y el sistema durante la captura de requisitos. No solo ayudan a desarrollar una interfaz grafica mejor, sino a comprender mejor los casos de uso. A la hora de especificar la interfaz de usuario tambin puede utilizarse otros artefactos como modelos de interfaz grafica y los esquemas de pantalla.

 Trabajadores
Al comienzo se explico los artefactos que se producen durante el modelado de casos de uso. El paso siguiente es examinar los trabajadores responsables de esos artefactos. Un trabajador es un puesto al cual se puede asignar una persona real. En el trabajador tenemos una descripcin de las responsabilidades y su comportamiento esperado.

 Un trabajador no es lo mismo que un individuo : una misma persona puede estar asignada a diferentes trabajadores durante un proyecto. Tampoco corresponde a un puesto o cargo concreto en la empresa. Un trabajador representa una abstraccin de un ser humano con ciertas capacidades que se requieren en un caso de uso del negocio. cuando se asigna los recursos humanos a un proyecto, un trabajador representa el conocimiento y habilidad para hacerse cargo del trabajo como trabajador del proyecto..

 Podemos identificar tres trabajadores que participan en el modelado de casos de uso, cada uno con su propio conjunto de operaciones y responsabilidades:
Analista del sistema Especificador de casos de uso Diseador de interfaz de usuario.

En trminos generales se les llama analistas a todos estos trabajadores.

 Trabajador : Analista de Sistemas.

El analista es el responsable del conjunto de requisitos que estn modelados en los casos de uso, lo que incluye los requisitos funcionales y no funcionales. El analista es responsable de delimitar el sistema , encontrando los actores y los casos de uso y asegurando que el modelo este completo y consistente. Para la consistencia el analista usara un glosario para conseguir un acuerdo en trminos comunes nociones y conceptos.

Analista de Sistemas

Responsable de

Modelo de casos de uso

Actor

Glosario

Las responsabilidades del analista de sistemas durante la captura de casos de uso

 Trabajador: especificador de casos de uso

La captura de requisitos no es hecho por una sola persona de hecho el analista esta asistido por otros trabajadores que asumen la responsabilidad de la descripcin detallada de uno o mas casos de uso. Estos trabajadores se dominan especificadores de casos de uso. Que necesita trabajar estrechamente con los usuarios reales de sus casos de uso.

Especificador de casos de uso Responsable de

Caso de uso

 Diseador de interfaz de usuario

Dan forma visual a las interfaces de usuario. Esto puede implicar el desarrollo de prototipos de interfaces de usuarios para algunos casos de uso. Habitualmente un prototipo para cada actor. Por tanto es conveniente que cada diseador de interfaces de usuario de forma a las interfaces de usuarios de uno o mas actores.

Diseador de interfaces de usuario

Responsable de

Prototipo de interfaz de usuario

 Trabajador: Arquitecto
El arquitecto participa en el flujo de trabajo de los requisitos para describir la vista de la arquitectura del modelo de casos de uso La vista de la arquitectura del modelo de casos de uso es una entrada importante para planificar las iteraciones

Arquitecto

Responsable de

Vista de la arquitectura

Descripcin de la arquitectura

Modelo de casos de Uso

 Flujo de trabajo
Describe el comportamiento dinmico de la captura de requisitos a travs de un diagrama de actividades. El diagrama utiliza calles para mostrar que trabajadores ejecutan que actividades. Cada actividad representada por ruedas dentadas se sita en el mismo campo que el trabajador que la ejecuta. Cuando los trabajadores ejecutan actividades crean y modifican artefactos.

 Describimos los flujos de trabajos como una secuencia de actividades que estn ordenadas, as que una actividad produce una salida que sirve de entrada a la siguiente actividad. Los trabajos no son necesariamente en secuencia, de hecho se hacen en diferentes vas. Por ejemplo podemos empezar con la actividad Encontrar Actores y Casos de Uso despus disear la interfaz de usuario, para darnos cuenta la necesidad de aadir mas casos de uso, retrocediendo a la actividad encontrar casos de uso rompiendo la secuencia estricta.

 Una actividad puede ser retomada muchas veces. Por tanto los caminos de una actividad a otra actividad ilustran tan solo la secuencia lgica de actividades utilizando los resultados de la ejecucin de una actividad como entrada para ejecutar otra. Primero: el analista de sistemas ejecuta la actividad Encontrar Actores y Casos de Uso para preparar una primera versin del modelo de casos de uso.

 El Arquitecto identificara los caso de uso mas relevantes arquitectnicamente para proporcionar entradas a la priorizacion de los casos de uso que van a ser desarrollados en la iteracin actual. Los especificadores de casos de uso describen todos los casos de uso que se han priorizado. Los diseadores de interfaz de usuario sugieren las interfaces de usuario adecuadas para cada actor.

 El analista de sistemas reestructura el modelo de casos de uso definiendo generalizaciones entre los caso de uso para hacerlo mas comprensible. La primera iteracin a travs de este flujo de trabajo consiste en una primera versin del modelo de casos de uso. Los resultados de cualquier iteracin subsiguiente consistirn entonces en nuevas versiones de estos artefactos.

Analista de Sistema

Encontrar actores y casos de uso

Estructurar el modelo de casos de uso

Arquitecto

Priorizar casos de uso

Especificador de casos de uso

Detallar un caso de uso

Diseador de casos de uso

Prototipar la interfaz de usuario

 Actividad: encontrar actores y casos de uso

Identificamos los actores y casos de uso para:
Delimitar el sistema de su entorno. Esbozar quien y que actores interactan con el sistema. Y que funcionalidad se espera del sistema. Capturar y definir un glosario de trminos comunes necesario par describir los casos de uso.

 La identificacin de actores y caso de uso es la actividad mas decisiva para obtener adecuadamente los requisitos y es responsabilidad del analista de sistemas. Para lo cual al analista requiere entradas de los clientes, usuarios y otros analistas. Algunas veces se parte de un modelo de negocios, y crear un borrador del modelo de casos de uso de manera rpida.

 Otras veces se parte de un modelo del dominio, o de una breve descripcin general o la especificacin detallada de requisitos. Tambin se puede tener como entrada los requisitos adicionales que no pueden ubicarse en los caso de uso individuales. La actividad consta de cuatro pasos:
Encontrar los actores Encontrar los caso de uso Describir brevemente los caso de uso Describir el modelo de caso de uso completo

 Estos pasos se ejecutan en cualquier orden o se hacen simultneamente. El resultado de esta actividad en una nueva versin del modelo de casos de uso con actores y casos de uso cambiados. El modelo puede iniciarse con un esbozo e ir depurando y madurando a lo largo de las iteraciones

Enviar aviso

Caso de uso en el sistema de pagos y facturacin: CU. Negocio. Venta: del pedido a la entrega.

 Encontrar los Actores

Esta tarea depende del punto de partida. Cuando tenemos un modelo del negocio del cual partir encontrar los actores resulta sencillo. El analista de sistemas puede asignar un actor a cada trabajador del negocio y un actor a cada actor del negocio En otro caso, con o sin un modelo del domino, al analista del sistema, junto con el cliente identifica los usuarios e intenta organizarlos en categoras representadas por actores.

 Hay dos criterios tiles ala hora de elegir los candidatos a actores:
1. Deber ser posible identificar al menos a un usuario que pueda representar al actor candidato. Esto elimina actores fantasmas 2. Deber existir una coincidencia mnima entre los roles que desempean las instancias de los diferentes actores en relacin con el sistema. No debe existir actores que tienen los mismos roles.

 El analista de sistemas da nombre a los actores y describe brevemente los papeles de cada actor. Encontrar nombres relevantes para cada actor es importante para comunicar la semntica deseada La descripcin breve de cada actor debe esbozar sus necesidades y responsabilidades.

 Ejem.: los actores Comprador, Vendedor y Sistema de Cuentas bancarias Comprador

Persona que es responsable de adquirir bienes o servicios como se describe en el caso de uso Ventas: del pedido a la entrega. Enva pedidos y paga facturas

Vendedor
Persona que vende y distribuye bienes o servicios, consigue pedidos, entrega confirmaciones de pedidos facturas y avisos de pago

Sistema de cuentas bancarias

Enva verificaciones de transacciones al sistema de cuentas bancarias

 Encontrar los casos de uso.

Si contamos de punto de partida con el modelo de negocios, se propone un caso de uso para cada rol de cada trabajador que participa en la realizacin de casos de uso del negocio. En otros casos el analista identificara los casos de uso a travs de talleres con los clientes y los usuarios. El analista de sistemas repasa cada uno los actores y propone casos de uso para cada actor.

 El actor necesita casos de uso para soportar su trabajo de creacin, cambio, rastreo, eliminacin o estudio de los objetos. El actor tambin informa al sistema acerca de sucesos externos u otras formas de representacin. Elegimos un nombre para cada caso de uso de forma que nos haga pensar en la secuencia de acciones concreta que aade valor a un actor.

 Para determinar que un caso de uso debe pasar de candidato a elegido se considera:
El caso de uso debe ser completo Siempre se ejecuta como continuacin de otro Aaden valor a los actores entregando un valor observable al actor.

Observe que existe dos frases claves en estas directrices que constituyen criterios tiles para la identificacin de casos de uso: - Resultado de valor - Un actor en concreto

 Resultado de Valor: cada ejecucin satisfactoria de un caso de uso debe proporcionar algn valor al actor para alcanzar su objetivo. El criterio Un resultado de valor observable debe ser aplicado al actor Iniciador. Esto evita encontrar casos de uso muy pequeos. Un Actor en Concreto: identificando casos de uso que proporciones valores a usuarios individuales reales, nos aseguramos que el caso de uso no ser demasiado grande.

 Los casos de uso y la arquitectura del sistema se desarrolla mediante iteraciones Una ves que tengamos la arquitectura los nuevos casos de uso deben ser adaptados a la arquitectura existente, los que no se ajusten deben ser modificados , podemos tambin mejorar la arquitectura Describir brevemente cada caso de uso: a medida que identifiquemos los casos de uso algunas veces se garabatea una pocas palabras explicando el caso de uso.

 Despus se describe brevemente cada caso de uso, con frases que resuman las acciones. Y mas tarde con una descripcin paso a paso de los que el sistema necesita hacer cuando interacta con sus actores. Ejem. Descripcin inicial del caso de uso pagar factura:
Breve descripcin
El comprado utiliza el caso de uso pagar factura para planificar los pagos de la facturas. El caso de uso efecta el pago el da de vencimiento de la misma.

Descripcin paso a paso inicial Despus de que el caso de uso comience, el comprador ya ha recibido una factura y tambin ha recibido los bienes y servicios demandados: 1. El comprador estudia la factura a pagar y verifica que se corresponde con el pedido original 2. El Comprador planifica el pago de la factura por banco. 3. Cuando vence el da de pago, el sistema revisa si hay suficiente dinero en la cuenta del comprador. Si tiene suficiente dinero disponible, se hace la transaccin.

 Descripcin del modelo de casos de uso en su totalidad Preparamos diagramas y descripciones para explicar el modelo de casos de uso en su totalidad. Especialmente como se relacionan los casos de uso entre si y con los actores. No hay una regla estricta sobre lo que se debe incluir en el diagrama. Solo debe describir claramente el sistema. El modelo de casos de uso requiere ser un modelo plano. Tambin puede organizarse en conjuntos llamados paquetes.

 La salida de este paso es tambin una descripcin general del modelo de caso de uso. Esta descripcin explica el modelo de casos de uso como un todo. Describe como interactan los actores y los casos de uso y como se relacin entre si . Cuando la descripcin del modelo este preparado dejar que el visto bueno lo de la gente que no forma parte del equipo de desarrollo (clientes, usuarios) para :

 Se ha capturado como caso de uso todos los requisitos funcionales necesarios La secuencia de acciones es correcta, completa y comprensible para cada caso de uso Se identifica algn caso de uso que no proporcione valor. Si es as, ese caso de uso debera reconsiderarse.

 Actividad: priorizar casos de uso.

El propsito es determinar que caso de uso son necesarios para el desarrollo es decir : anlisis , diseo, implementacin, en la primeras iteraciones y cuales puden dejarse para mas tarde. Los resultados se recogen en las vistas de la arquitectura del modelo de casos de uso. La que se revisa con el jefe del proyecto y se usa para hacer la planificacin de lo que se debe desarrollar dentro de una iteracin.

 Para esta planificacin debe considerarse tambin los aspectos econmicos o de negocio . La vista de arquitectura del modelo debe mostrar los casos de uso significativos desde el punto de vista de la arquitectura.

 Actividad: detallar un caso de uso. El objetivo es describir su flujo de sucesos en detalle, incluyendo como comienza, termina e interacta con los actores. Como entrada se tiene el modelo de casos de uso y los diagramas de caso de uso asociados. La tarea la realiza el especificador, que detalla paso a paso la descripcin de cada caso de uso, en una secuencia precisa de acciones.

 Los especificadores de casos de uso trabajan estrechamente con los usuarios reales de los casos de uso. La descripcin de los casos de uso es en texto y diagramas. Estructuracin de la descripcin de casos de uso:
Un caso de uso puede imaginarse como si tuviera un estado de comienzo , estados intermedios, estados finales y transiciones de un estado a otro Debemos describir las posibles transiciones de manera simple y precisa

 Una tcnica probada es elegir un camino bsico completo del inicio al final, y describir este camino en una seccin. Luego podemos describir en secciones separadas el resto de caminos alternativos. De tal forma que sean fcil de leer y entender Se debe describir todas las alternativas, que pueden ocurrir por muchas razones.
El actor elige entre varios caminos del caso de uso Se esta implicado mas de un actor en el caso de uso, la accin de uno puede influir en el otro. El sistema puede detectar entradas errneas de los actores. Mal funcionamiento de recursos del sistema.

 El camino bsico elegido debe ser el camino normal esto es el que el usuario percibe como el que mas habitualmente va a seguir y proporciona valor mas obvio al actor. Ejem. Camino en el caso de uso pagar factura. 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 Sucesos Camino Bsico

1. El comprador invoca el 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 y as indicrselo al comprador. La confirmacin del pedido describe que elementos sern enviados, cuando, donde, y a que precio. 2. El comprador decide planificar una factura para pagarla por banco y el sistema genera una peticin de pago para transferir el dinero a la cuenta del vendedor ntese que un comprador no puede planificar el pago de la misma factura dos veces.

3. Mas 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. Tanto el comprador como el vendedor tienen notificacin de resultado de la transaccin. El banco recoge unos cargos por la transaccin, que se retiran de la cuenta del comprador. 4. La instancia del caso de uso finaliza.

Caminos Alternativos
En el paso 2 el comprador puede pedir al sistema que devuelva un rechazo de la factura al vendedor. En el paso 3, si no hay suficiente dinero en la cuenta, el caso de uso cancelara el pago y notificara al comprador.

 Poscondiciones: la instancia de 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.

Que incluir en una descripcin de casos de uso

Debe definir el estado inicial como precondicin Como u cuando comienza el caso de uso El orden requerido en el que las acciones se deban ejecutar Como y cuando terminar los casos de uso

 Definir los posibles estado finales como post condiciones Los caminos de ejecucin que no estn permitidos. La descripcin de caminos alternativos que estn incluidos junto con la descripcin del camino bsico Cominos alternativos que han sido extrados de la descripcin del camino bsico La iteracin del sistema con los actores y que cambios produce. La utilizacin de objetos, valores y recursos del sistema. Describir explcitamente lo que hace el sistema, separando las responsabilidad del sistema y los actores.

 Los requisitos no funcionales como especificar la velocidad, disponibilidad, exactitud, tiempo de respuesta uso de memoria que el sistema necesita para llevar a cabo un caso de uso debe registrase como requisitos especiales y documentarse en una seccin separada dentro de la descripcin de casos de uso.