Captura de los Requisitos como casos de Uso

Semana 9-10

Lic. Espinoza Robles.

Introducción• El esfuerzo principal en la fase de requisitos

es desarrollar un modelo del sistema que se va ha construir, y la utilización 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 sistemático para capturar los requisitos funcionales.

• Los analistas se ven obligados a pensar en términos 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 dirección del resto del trabajo de desarrollo, lo que ha contribuido para su aceptación 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.

ArtefactosEspecificar

Casos de uso

Diseñador De Interfaz de

Usuario

Arquitecto

Analista de

Sistemas

Mod.C.UsoGlosario

Casos de Uso

Prot. Interfaz de UsuarioDescripción 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.

• También pueden haber otros tipos de artefactos como prototipos de Interfaz.

• Estos artefactos son importantes:– Para la descripción formal de los casos de uso– Facilita la identificación de los casos de uso y

su descripción.– Es importante para poder explicar los actores y

casos de uso en relación 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 análisis, diseño y prueba.

• Un modelo de casos de uso contiene actores, casos de uso y sus relaciones. Puede hacerse grande y difícil, de modo que es necesario algún medio de abordarlo en trozos mas pequeños.

• 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. También se representan mediante actores uno o mas sistemas con el que interactúa, 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 desempeña un trabajador pueden emplearse para obtener los roles que cumple un actor del sistema.

• Ej.. Actor: El sistema de pagos y facturación interactúan con un tipo de usuario que empleara el sistema para pedir bienes, confirmar pedidos, pagar facturas y demás, 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 interactúa con el sistema, la instancia correspondiente del actor esta desarrollando ese papel.

• Una instancia de un actor es por tanto un usuario concreto que interactúa 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 interacción con los actores implicados.

• Según UML un caso de uso es un clasificador, lo cual quiere decir que tiene operaciones y atributos, por tanto su descripción puede incluir diagramas de estados, diagramas de actividad, colaboración 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 interactúa 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 cálculos internos, selección 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 mayoría 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. Contraseña, la cuenta, cantidad a retirar.

• Las instancias de caso de uso no interactúan con otras instancias de caso de uso, la única interacción 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 fructíferas discusiones con usuarios finales y evitar tratar con interfaces entre casos de uso, concurrencias y otros conflictos.

• Cada instancia de casos de uso es atómica 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 descripción 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.

• También especifica como interactúa el sistema con los actores cuando se lleva a cabo el caso de uso.

• Desde la perspectiva de la gestión, incluye un conjunto de secuencias de acciones que pueden ser modificadas, revisadas, diseñadas, implementadas y probadas juntas y que pueden ser descritas como una sección o subseccion del manual del usuario.

• Requisitos especiales.

• Llamamos requisitos espaciales a una descripción 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 análisis, diseño, o implementación.

Artefacto: descripción de la arquitectura

• La descripción 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 algún requisito importante.

• Esta vista de arquitectura se utiliza como entrada cuando se priorizan los caso de uso para su desarrollo dentro de cada iteración.

• Normalmente las realizaciones de casos de uso correspondiente pueden encontrarse en las vistas arquitectónicas de los modelos de análisis y diseño.

Descripción de la arquitectura

Vista de la arquitectura

Modelo de casos de uso

• Artefacto: Glosario• Podemos usar un glosario para definir

términos 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 fácil 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 también 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 descripción 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 abstracción 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– Diseñador de interfaz de usuario.

En términos generales se les llama analistas a todos estos trabajadores.

• Trabajador : Analista de Sistemas.• El analista es el responsable del conjunto de

requisitos que están 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 términos comunes nociones y conceptos.

Analista de Sistemas

Responsable de

Modelo de casos de uso

ActorGlosario

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 descripción 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

• Diseñador 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 diseñador de interfaces de usuario de forma a las interfaces de usuarios de uno o mas actores.

Diseñador 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

Descripción de la arquitectura Modelo de casos de Uso

• Flujo de trabajo• Describe el comportamiento dinámico de la

captura de requisitos a través de un diagrama de actividades.

• El diagrama utiliza calles para mostrar que trabajadores ejecutan que actividades.

• Cada actividad representada por ruedas dentadas se sitúa 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 están 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 vías.

• Por ejemplo podemos empezar con la actividad Encontrar Actores y Casos de Uso después diseñar la interfaz de usuario, para darnos cuenta la necesidad de añadir 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 lógica de actividades utilizando los resultados de la ejecución 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 versión del modelo de casos de uso.

• El Arquitecto identificara los caso de uso mas relevantes arquitectónicamente para proporcionar entradas a la priorizacion de los casos de uso que van a ser desarrollados en la iteración actual.

• Los especificadores de casos de uso describen todos los casos de uso que se han priorizado.

• Los diseñadores 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 iteración a través de este flujo de trabajo consiste en una primera versión del modelo de casos de uso. Los resultados de cualquier iteración subsiguiente consistirán entonces en nuevas versiones de estos artefactos.

Analista de SistemaEncontrar actores y casos de uso

Estructurar el modelo de casos de uso

Arquitecto Priorizar casos de uso

Detallar un caso de uso

Prototipar la interfaz de usuario

Especificador de casos de uso

Diseñador de casos de uso

• 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 interactúan con el

sistema. Y que funcionalidad se espera del sistema.

– Capturar y definir un glosario de términos comunes necesario par describir los casos de uso.

• La identificación 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 rápida.

• Otras veces se parte de un modelo del dominio, o de una breve descripción general o la especificación detallada de requisitos.

• También 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 simultáneamente.

• El resultado de esta actividad en una nueva versión 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 facturación: 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 categorías 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 mínima entre los roles que desempeñan las instancias de los diferentes actores en relación 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 semántica deseada

• La descripción 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. Envía 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– Envía 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 realización de casos de uso del negocio.

• En otros casos el analista identificara los casos de uso a través 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 creación, cambio, rastreo, eliminación o estudio de los objetos.

• El actor también informa al sistema acerca de sucesos externos u otras formas de representación.

• Elegimos un nombre para cada caso de uso de forma que nos haga pensar en la secuencia de acciones concreta que añade 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 continuación de otro– Añaden 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 identificación de casos de uso:

- Resultado de valor

- Un actor en concreto

• Resultado de Valor: cada ejecución satisfactoria de un caso de uso debe proporcionar algún 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 pequeños.

• 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 también 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.

• Después se describe brevemente cada caso de uso, con frases que resuman las acciones. Y mas tarde con una descripción paso a paso de los que el sistema necesita hacer cuando interactúa con sus actores.

• Ejem. Descripción inicial del caso de uso pagar factura:– Breve descripción

• El comprado utiliza el caso de uso pagar factura para planificar los pagos de la facturas. El caso de uso efectúa el pago el día de vencimiento de la misma.

Descripción paso a paso inicialDespués de que el caso de uso comience, el comprador ya ha recibido una factura y también 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 día de pago, el

sistema revisa si hay suficiente dinero en la cuenta del comprador. Si tiene suficiente dinero disponible, se hace la transacción.

• Descripción 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. También puede organizarse en conjuntos llamados paquetes.

• La salida de este paso es también una descripción general del modelo de caso de uso. Esta descripción explica el modelo de casos de uso como un todo.

• Describe como interactúan los actores y los casos de uso y como se relación entre si .

• Cuando la descripción 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 algún caso de uso que no proporcione valor. Si es así, ese caso de uso debería reconsiderarse.

• Actividad: priorizar casos de uso.• El propósito es determinar que caso de uso

son necesarios para el desarrollo es decir : análisis , diseño, implementación, 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 planificación de lo que se debe desarrollar dentro de una iteración.

• Para esta planificación debe considerarse también los aspectos económicos 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 interactúa 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 descripción 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 descripción de los casos de uso es en texto y diagramas.

• Estructuración de la descripción 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 técnica probada es elegir un camino básico completo del inicio al final, y describir este camino en una sección.

– Luego podemos describir en secciones separadas el resto de caminos alternativos. De tal forma que sean fácil 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 acción de uno puede influir en el otro.

• El sistema puede detectar entradas erróneas de los actores.

• Mal funcionamiento de recursos del sistema.

• El camino básico 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.

• Precondición: 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 Básico

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í indicárselo al comprador. La confirmación del pedido describe que elementos serán enviados, cuando, donde, y a que precio.

2. El comprador decide planificar una factura para pagarla por banco y el sistema genera una petición de pago para transferir el dinero a la cuenta del vendedor nótese 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 transacción en la fecha planificada. Durante la transacción, el dinero se transfiere de la cuenta del comprador a la del vendedor. Tanto el comprador como el vendedor tienen notificación de resultado de la transacción. El banco recoge unos cargos por la transacción, que se retiran de la cuenta del comprador.

4. La instancia del caso de uso finaliza.Caminos AlternativosEn 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 descripción de casos de uso– Debe definir el estado inicial como

precondición– 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 ejecución que no están permitidos.

– La descripción de caminos alternativos que están incluidos junto con la descripción del camino básico

– Cominos alternativos que han sido extraídos de la descripción del camino básico

– La iteración del sistema con los actores y que cambios produce.

– La utilización de objetos, valores y recursos del sistema.

– Describir explícitamente 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 sección separada dentro de la descripción de casos de uso.