UNIVERSIDAD DE COSTA RICA

SEDE DEL ATLÁNTICO. RECINTO DE TURRIALBA. BACHILLERATO EN INFORMÁTICA EMPRESARIAL. IF-6100, ANÁLISIS Y DISEÑO DE SISTEMAS. PROFESOR: ÁLVARO MENA M.

RESUMEN LECTURA No.3
CREACIÓN DE CASOS DE USO
ESTUDIANTE: WILLIAM ULLOA ARAYA. CARNÉ: A86450

II-2011

CREACIÓN DE CASOS DE USO
Un 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 con el que el actor interactúa con el sistema. Las siguientes son algunas características de los casos de uso: y y y y y y 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.

El propósito de un caso de uso es para facilitar el acuerdo entre los desarrolladores, clientes y usuarios sobre lo que debe hacer el sistema. Un caso de uso puede ser utilizado como un contrato entre los desarrolladores y clientes. Durante la creación de casos de uso, también debe definir los escenarios específicos de las rutas a través de un caso de uso. Usted puede producir los diagramas de secuencia, diagramas de comunicación, y los diagramas de clases de los escenarios. También se utilizan como insumo para los casos de prueba. Los casos de uso son una buena manera de expresar los requerimientos funcionales del sistema.

IDENTIFICACIÓN DE LOS ACTORES.

Un actor es alguien o algo que interactúa con el sistema. Puede ser una persona, pero también puede ser otro sistema. Algunos ejemplos son los siguientes: y y y y y Los usuarios del sistema Los administradores Las personas que suministran información al sistema Los sistemas de suministro de datos externos Sistemas externos que se hayan notificado

IDENTIFICACIÓN DE CASOS DE USO. Estas son algunas 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? y ¿Qué información necesitan los agentes para suministrar al sistema? y ¿Qué información necesitan recibir los actores del sistema? y ¿Sobre qué eventos fuera del sistema hace que el sistema necesite ser notificado? Algunas pautas para la creación de casos de uso son las siguientes: y Cada caso de uso deberá interactuar con por lo menos un actor. y Cada caso de uso deberá ser iniciado por un actor. y Los nombres de los casos de uso serán significativos. y Use los casos en donde se describe la funcionalidad, no la ejecución. y Deberá ser claro quién inicia el caso de uso. y y También hay que tener en cuenta que los casos de uso no pueden ser demasiado pequeños o demasiado grandes. Se debe realizar sólo un paso en cada caso de uso. Si el caso de uso tiene dos pasos, probablemente no es un caso de uso correcto. Se encontraron los siguientes casos de uso para cada uno de los actores de nuestro proyecto: y Usuario ‡ Registrarse ‡ Conectarse Viajeros ‡ Reservar un vuelo ‡ Comprar un boleto ‡ Reservar una habitación de hotel

y

‡ Buscar lugares de interés ‡ Reservar un coche y Representante de Servicio al Cliente ‡ Conectarse ‡ Cambios en la reservación ‡ Eliminar reserva ‡ Búsqueda de reserva Administrador ‡ Registro de usuario ‡ Búsqueda de un usuario ‡ Actualizar la información del usuario ‡ Conectarse ‡ Ejecutar informe Administrador de contenido ‡ Conectarse ‡ Presentar la información Proveedores de Hotel ‡ Conectarse ‡ Presentar la información Proveedor de carros ‡ Conectarse ‡ Presentar la información Representante de aviones ‡ Conectarse ‡ Presentar la información

y

y

y

y

y

DIAGRAMAS DE CASOS DE USO. Los diagramas de casos representan actores, casos de uso, y las relaciones entre ellos. En el diagrama de casos de uso, que se muestra en la Figura 7.2, los actores se representan como figuras de palo, y los casos de uso están representados como óvalos. La flecha sólida indica una ruta de comunicación entre un actor y un caso de uso.

Figura 7.2 Un actor y un caso de uso. 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 sistema en muchos diagramas. No hay reglas estrictas sobre cómo debe ser dividido el modelo. Algunas opciones de cómo se pueden agrupar los diagramas: y Todos los casos de uso iniciados por el mismo actor o grupo de actores y Los casos de uso que se ejecutan normalmente en una sentencia y Los casos de uso relacionados con el mismo tipo de tareas (tales como tareas administrativas) Las figuras 7.3 a 7.5 presentan los diagramas de casos de uso inicial de la Agencia de Viajes Online del proyecto.

Figura 7.3 Casos de uso iniciados por los actores viajero y usuario.

Figura 7.4 Casos de uso para los actores Representante de Servicio al Cliente y Administrador.

Figura 7.5 Casos de uso para los actores Proveedor de Servicio al Cliente y Administrador de contenido. ESTRUCTURACIÓN DEL MODELO DE CASOS DE USO. Después de que el modelo de casos de uso inicial se hace, podemos estructurarlo. 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: y Incluir

y y

Ampliar Generalización

INCLUYENDO LA RELACIÓN. Si una parte importante del flujo se utiliza en caso de utilizar más de una, es un buen candidato para ser extraído como un caso de uso separado que está conectado con una relación de inclusión. El caso de uso instanciado contendrá una base de caso de uso, así como el que se incluye. El caso de uso debe ser incluido autónomo y no puede hacer ninguna suposición sobre como es el caso de uso. Para demostrar esta relación en un diagrama de casos de uso, es necesario crear una dependencia entre los dos casos de uso (con una flecha punteada) y luego asignar un estereotipo a incluir a la dependencia, como se muestra en la Figura 7.6. La dirección de la flecha es el caso de uso base a los incluidos casos de uso.

RELACIÓN DE EXTENSIÓN.
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. La flecha indica el caso de uso de la base, como se muestra en la Figura 7.7.

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. El caso de uso padre no necesita saber si los hijos 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 casos de uso generalizados.

La figura 7.8 muestra cómo la generalización de casos de uso se presenta en los diagramas de casos de uso.

La Generalización también puede ser utilizada entre los actores. Es especialmente útil si un conjunto de actores inician el mismo caso de uso. La Figura 7.9 muestra cómo la generalización del actor se presenta en los diagramas de casos de uso.

ESPECIFICACIÓN DEL DOCUMENTO DE CASO DE USO. Este libro, utiliza el siguiente formato para un documento de Especificación de Casos de Uso: 1. Breve descripción 2. Flujo básico 3. Flujos alternativos 3.1 flujo de la Alternativa 1 3.2 flujo de la Alternativa 2 4. Requisitos especiales 5. Condiciones previas 6. Post-condiciones 7. Puntos de extensión 8. Diagrama de contexto 9. Diagrama de actividad 10. Diagramas de estado de la máquina 11. Escenarios En las secciones siguientes se tratan todas las partes de un caso de uso. Descripción breve 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. Flujo básico El flujo básico contiene la secuencia más popular de las acciones, los pasos que se producen cuando todo va bien. Flujos alternativos Flujos alternativos representan las variaciones del flujo, incluyendo los casos menos habituales y las condiciones de error. Requisitos especiales. Esta sección contienen todos los requerimientos relacionados con los casos de uso que no fueron cubiertos por los flujos de eventos. Usualmente estos son requisitos no funcionales. Sin embargo, si un requisito es genérico y se aplica en muchos casos de uso, estos se deben describir en las especificaciones suplementarias. Condiciones previas. Una condición previa es el estado del sistema antes de que el caso de uso inicie. Por ejemplo, una condición previa para la reservación puede ser que el administrador debe iniciar sesión en el sistema. 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. Puntos de extensión. Un punto de extensión es un lugar desde el cual un caso de uso extendido puede ser invocado. Por ejemplo, el caso de uso Eliminar una reservación puede tener las siguientes extensiones: Nombre: Proceso de devolución Ubicación: Después del paso B5 del flujo básico Diagrama de contexto. Un diagrama de contexto, que se muestra en la Figura 7.10, 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 que incluyen, extienden o generalizan las relaciones con el caso de uso dado, este también debe ser mostrado en el diagrama de contexto.

El diagrama de contexto y el diagrama de actividades no son necesarios, pero ayudan a visualizar el caso de uso y su posición en el proyecto. Diagrama de actividad Un diagrama de actividades, que se muestra en la Figura 7.11, es similar a un diagrama de flujo. Puede ser utilizado para representar gráficamente los flujos en el caso de uso. 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. Medidas que no tienen ramas en el medio se pueden combinar.

Diagramas de estado de la máquina A veces es posible que necesitemos para describir el comportamiento de los objetos que actúan de forma diferente en función de su estado. 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. ESCENARIOS Para encontrar todos los escenarios, tenemos que identificar todos los caminos a través del caso de uso dado. Hay un escenario para un flujo básico, un escenario para cada flujo alternativo, y un escenario para cada combinación de flujos alternativos. CASOS DE USO EN REQUISITEPRO. El documento de especificación de caso de uso se crea a partir de una plantilla que contiene las partes que se discuten 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.

Sign up to vote on this title
UsefulNot useful