Creación de casos de usoUn caso de uso es una descripción de un sistema en términos de una secuencia de acciones. Se debe producir un resultado observable o el valor para el actor que interactúa con el sistema.Características de casos de uso:• Son iniciados por un actor.• Los modelos de una interacción entre un actor y el sistema.• Describen una secuencia de acciones.• Capturan requerimientos funcionales.• Se debe proporcionar un valor para un actor.• Representan un flujo completo y significativo de los acontecimientos.

Según (Peter Zielczynski, 2008, pág. 129) “el propósito de un caso de uso es para facilitar el acuerdo entre los desarrolladores, clientes y los usuarios acerca de lo que debería hacer el sistema. Un caso de uso puede ser utilizado como un contrato entre los desarrolladores y los clientes. También es una base para las realizaciones de casos de uso, las cuales juegan un papel importante en el diseño. Por otra parte, usted puede obtener la documentación de usuario de casos de uso. Los casos de uso también pueden ser útiles en la planificación del contenido técnico de iteraciones y dar a los desarrolladores un mejor entendimiento del objetivo del sistema”.Durante la creación de casos de uso, también debe definir los escenarios específicos de las rutas a través un caso de uso. Usted puede producir los diagramas de secuencia, diagramas de comunicación, y los diagramas de clases de escenarios. También se utilizan como insumo para los casos de prueba.

Identificar Actores

Un actor es alguien o algo que interactúa con el sistema. Puede ser una persona, sino que tambiénpuede ser otro sistema. He aquí algunos ejemplos:• Los usuarios del sistema.• Los administradores.• Gestión.• Las personas que proveen información para el sistema.• Los sistemas externos de suministro de datos.• Sistemas externos que se hayan notificado.Todas las partes interesadas del sistema también son candidatos a ser actores:•Dueño de la Agencia de Viajes.• El usuario 1 (de los EE.UU.)• El usuario 2 (de Francia)

• Desarrollador.• Administrador de contenido.• Representante de Servicio al Cliente.

La identificación de casos de uso Preguntas que pueden ayudar a identificar casos de uso:• ¿Qué función puede esperar cada actor del sistema?• Los actores deben ser informados sobre los acontecimientos que ocurren en el sistema?• ¿Qué información necesitan los agentes de suministro para el sistema?• ¿Qué información se necesita para recibir los actores del sistema?• Acerca de los eventos fuera del sistema ¿hace que el sistema necesite ser notificado?

Los casos de uso pueden ser identificados en un taller de requisitos.Pautas para la creación de casos de uso:• Cada caso de uso deberá interactuar con por lo menos un actor.• Cada caso de uso deberá ser iniciado por un actor.• Los nombres de los casos de uso serán significativos. Use búsqueda de reservación y búsqueda de viaje en lugar de la búsqueda 1 y de la búsqueda 2. Nunca se tienen dos casos de uso con el mismo nombre. Los nombres se entienden no sólo por el equipo de desarrollo, sino también por los clientes y los usuarios.• Los casos de uso describen la funcionalidad, no la ejecución.• Deberá ser claro que inicia el caso de uso.

También hay que tener en cuenta que los casos de uso no pueden ser demasiado pequeños o demasiado grandes. Por ejemplo, envíe información de la tarjeta de crédito no es un caso de uso correcto, ya que no representan un flujo completo de los eventos y no proporciona ningún valor para el actor.

Los diagramas de casos Los diagramas de casos representan actores, casos de uso, y las relaciones entre ellos.Los diagramas de casos de uso ilustran las relaciones en el modelo de casos de uso. Para sistemas pequeños, todo el modelo de casos de uso se puede presentar en un diagrama. Para grandes sistemas, es necesario dividir el todo el sistema en muchos diagramas. No hay reglas estrictas sobre cómo el modelo debe ser dividido.

Algunas opciones para lo que se pueden agrupar en un diagrama:

• Todos los casos de uso iniciados por el mismo actor o grupo de actores.• Los casos de uso que se ejecutan normalmente en una oración.• Los casos de uso relacionados con el mismo tipo de tareas (tales como tareas administrativas).

La estructuración del modelo de Casos de Uso

Después de que el modelo de casos de uso inicial se hace, podemos estructurar. El objetivo principal de la estructuración del modelo es eliminar cualquier redundancia, por lo que los casos de uso son más fáciles de entender y mantener.En primer lugar, tenemos que analizar los casos de uso y encontrar las piezas de los flujos que contienen medidas similares. Entonces podemos aplicar algunos de los tres tipos de relaciones entre casos de uso:• Incluir.• Ampliar.• Generalización.Podemos aplicar la generalización de los casos de uso, así como a los actores.Si dos casos de uso siempre se activan en la misma secuencia, se puede considerar la combinación de ellos. Por ejemplo, como caso de uso Comprar un billete de avión se produce después de reservar un vuelo, se ha decidido fusionarlos.Si el caso de uso es muy complicado, podemos considerar su división. Una técnica para decidir cuándo un caso de uso debe ser dividido es buscar alternativas. Cuando hay un camino alternativo para un camino alternativo, por lo general esto significa que el caso de uso se está volviendo demasiado complejo. Esta es una señal de que el caso de uso es un candidato para ser dividido en dos diferentes casos de uso, una ampliación del caso de uso base.Sin embargo, si el caso de uso tiene muchos pasos que se realizan siempre juntos en la misma secuencia, no debe ser dividido en dos casos de uso.

Incluir Relaciones Si una parte importante del flujo se utiliza en más de un caso de uso, es un buen candidato para ser extraído como un caso de uso separado que está conectado con una relación incluida. La instancia del caso de uso contendrá un caso de uso base, así como el que se incluye. El caso de uso incluido debe ser autónomo y no puede hacer ninguna suposición sobre cual caso de uso es incluido.

Relación Extendida Si alguna parte del caso de uso es opcional o condicional, para que el modelo sea más claro, podemos extraer como un caso de uso separado que está conectado con una relación de extensión.

Generalización de la relación entre casos de uso

Si dos o más casos de uso son similares, se puede extraer similitudes en el caso de uso base. Derivados los casos de uso se puede agregar el comportamiento y modificar el comportamiento definido en el caso de uso base. El caso de uso padre no tiene por qué saber que los niños son especializaciones de la misma. Sin embargo, ya que esta técnica puede ser difícil de comprender para las partes interesadas, IBM Rational sugiere evitar el uso de la generalización de casos de uso.

Generalización de relaciones entre los actores

La generalización también puede ser utilizada entre los actores. Es especialmente útil si un conjunto de actores inician los mismos casos de uso.

Documento de especificación de casos de uso

1. Breve descripción.La descripción deberá explicar claramente su propósito. También se menciona a todos los actores que interactúan con el caso de uso.

2. Flujo básico.El flujo básico contiene la secuencia más popular de las acciones, los pasos que ocurren cuando todo va bien. 3. Flujos alternativos.Representan las variaciones del flujo, incluyendo los casos menos habituales y las condiciones de error.Las siguientes preguntas pueden ayudar a encontrar flujos alternativos:• ¿Qué otras medidas se pueden tomar en cada paso del flujo básico?

• ¿Qué errores pueden ocurrir en cada paso (datos erróneos, los datos faltantes, problemas de conexión)?• ¿Existe un comportamiento que puede ocurrir en cualquier momento (por ejemplo, salir, imprimir, ayuda)?• ¿Alguna condición (por ejemplo, una combinación específica de los datos introducidos) cambia significativamente el flujo? 4. Requisitos especiales.La sección de requisitos especiales contiene todos los requisitos relacionados con este caso de uso que no fueron cubiertos por los flujos de eventos. Por lo general, estos son los requisitos no funcionales. Sin embargo, si un requisito es genérico y se aplica en muchos casos de uso, se describe en la especificación complementaria. 5. Condiciones previas.Una condición previa es el estado del sistema antes de que el caso de uso se pueda iniciar. 6. Postcondiciones.Una postcondición es el estado del sistema después de que el caso de uso termina. A menos que sea específicamente mencionada, la postcondición será válida para cualquier flujo alternativo, no sólo para el flujo básico. 7. Puntos de extensión.Un punto de extensión es un lugar desde el cual puede ser invocado un caso de uso extendido. 8. Diagrama de contexto.Un diagrama de contexto es parte de un diagrama de casos de uso que muestra las relaciones de este caso en particular a los actores y otros casos de uso. Todos los casos de uso son incluidos, extendidos o generalizados con las relaciones, el caso de uso también debe ser mostrado en el diagrama de contexto. 9. Diagrama de actividad.Un diagrama de actividad es similar a un diagrama de flujo. Puede ser utilizado para representar gráficamente los flujos en el caso de uso. Las cajas con esquinas redondeadas representan estados de actividad, las flechas representan transiciones, y las ramas se modelan como diamantes. Un diagrama de actividades deberá contener el flujo básico y todos los flujos alternativos. Las medidas que no tienen ramas en el medio pueden ser combinadas. 10. Diagramas de estado de la máquina.A veces es posible que necesitemos describir el comportamiento de los objetos que actúan de forma diferente dependiendo de su estado. En este caso podemos utilizar diagramas

UML 2 máquina de estados [AMB04]. En las versiones anteriores de UML, estos diagramas fueron llamados diagramas de estado gráfico, y en otros lenguajes de modelado, se les llaman diagramas de transición de estado o simplemente diagramas de estado. 11. Escenarios.

Un escenario es una instancia de un caso de uso. En él se describe una ruta específica a través del flujo de los acontecimientos.Es importante identificar todos los escenarios válidos para todos los casos de uso. Que serán utilizados para el análisis y diseño, así como para derivar casos de prueba a partir de los casos de uso.

Escenarios Para encontrar todos los escenarios, tenemos que identificar todos los caminos a través del caso de uso dado.¿Qué debe hacer si usted tiene bucles infinitos (loops hacia atrás)? En teoría, estopodría generar un número infinito de escenarios.El enfoque razonable es hacer el flujo básico una vez, hacer un bucle de una vez, y luego hacer un bucle por segunda vez. Si el programa funciona tanto para las instancias del ciclo, se puede asumir que funcionará para muchos bucles.

Casos de uso en RequisitePro El documento de especificación de casos de uso se crea a partir de una plantilla que contiene las partes discutidas en la sección anterior. Si usted no tiene acceso a RequisitePro, puede crear este documento en Microsoft Word. Utilizando RequisitePro, sin embargo, le da mucha más funcionalidad, como la creación de requisitos del tipo de caso de uso, el establecimiento de la trazabilidad, y la elaboración de informes relacionados.No es necesario para terminar todo el documento a la vez. Creación de un caso de uso es un proceso iterativo. Tan pronto como el caso de uso se identifica, puede crear un documento asociado con una breve descripción que indica su propósito. En la siguiente iteración un esquema se puede añadir, a continuación, todos los pasos y, finalmente, una descripción detallada de cada paso. Un análisis detallado de todas las etapas del ciclo de vida del caso de uso se presenta en el libro de modelado de casos de uso de Kurt Bittner y Ian Spence [Bit02].

Referencias:

Peter Zielczynski, P. (2008). Requeriments Management Using IBM Rational RequisitePro. USA: IBM Press.