4/15/2010. Requerimientos de Software UARG.UNPA Requerimientos de Software. Requerimientos de Software

Transcripción

1 UARG.UNPA 2009 Un caso de uso es una interacción típica entre un usuario y un sistema computacional.(fowler) Un caso de uso especifica el comportamiento deseado del sistema (objetivos del usuario). (Jacobson) Describe qué hace un sistema, pero no especifica cómo lo hace. (Booch) Un caso de uso da lugar a un conjunto de posibles escenarios. 2 Los CU se emplean para capturar el comportamiento deseado del sistema en desarrollo, sin tener que especificar cómo se va a implementar. Modelan el comportamiento de un elemento que puede ser un sistema, subsistema ouna clase, desde el punto de vista del usuario Pueden representarse a diferentes niveles de abstracción. 3 1

2 Se crean con la captura de requerimientos, evolucionan y se usan durante todo el proceso: guían el proceso en desarrollo. Objetivos: Definir los requisitos funcionales del sistema, diseñando un escenario de uso acordado entre el usuario final y el equipo de desarrollo. Proporcionar una descripción clara y sin ambigüedades para el diseño. Proporcionar la base para la validación de las pruebas. 4 UML provee el Modelo de Casos de Uso para representar la vista del sistema que se corresponde con la vista del usuario. En UML larepresentación visual delos casos deusoes eldiagramadecasosdeuso. Las últimas tendencias de ingeniería de Software orientadas a objetos hablan del Proceso Unificado, dirigido por casos de uso, centrado en la arquitectura, iterativo e incremental. 5 Jacobson define el RUP dirigido por CU, porque éstos se pueden emplear para: Capturar el comportamiento general deseado del sistema. Comprender el sistema(desarrolladores, clientes) Validary crear la arquitectura Obtener los requisitos del sistema(escenarios) Identificar inicialmente las clases (abstracciones): análisis Tras la implementación, validación de los casos de usos identificados(pruebas) Crear el GUI del sistema 6 2

3 Trabajador: Representa una posición que se puede asignar a una persona o equipo en una organización de desarrollo de software. Para cada trabajador se especifican las responsabilidades y habilidades requeridas. Artefacto: Es un término general para cualquier clase de descripción o información creada, producida, cambiada o usada por los trabajadores cuando trabajan con el sistema. Por ejemplo, un modelo, un elemento del modelo, etc. El principal artefacto usado en la captura de requerimientoses el modelo de casos de uso(mcu). 7 8 El modelo de casos de uso utiliza tres elementos básicos: Actores, para modelar los diferentes roles que los elementos externos al sistema pueden representar. Casos de uso, para representar todo aquello que el actor hadepoderrealizarenelsistema. Relaciones, que asocian a los elementos anteriores. El modelo se completa con la descripción de casos de uso, esto es, la especificación de los comportamientos deloscasosdeuso. 9 3

4 El MCU describe lo que hace el sistema para cada tipo de usuario. Cada uno de éstos se representa mediante unoomásactores. Un actor puede representar a una persona física, otro sistema, un dispositivo. Representan a terceros fuera del sistema que colaboran con él. Un actor es como una clase, que se define por la descripción de su comportamiento. Un usuario puede desempeñar varios papeles (roles), esto es, puede actuar como diferentes actores. 10 La definición de actores, sirve para definir el contexto externo del sistema, esto es, delimitar los elementos que se encuentran fuera y dentro del sistema. Unactorjuegaunrolparacadacaso de uso en el que colabora. Cada vez que un usuario concreto interactúa con el sistema, la instancia correspondiente de ese actor está jugando ese rol. Una instancia de un actor es un usuario específico interactuando con el sistema. 11 Actores de un sistema bancario: Cajero, cliente, gerente, sistema de tarjetas electrónicas, etc. Actores de un sistema de bibliotecas: Socio, empleado de atención al público, empleado catalogadordel material, etc. Actores de un sistema de facturación: Cajero, sistema de stock, sistema de tarjetas, etc. 12 4

5 Representan las formas en las que los actores interactúan con el sistema. Los CU son trozos de funcionalidad que el sistema ofrece para agregar un resultado de valores a sus actores. Un CU constituye una secuencia completa de mensajes, y que especifica la interacción que tiene lugarentreunactoryelsistema. 13 El diagrama de casos de uso se acompaña con la especificación o descripción de los CU, incluye: La descripción de la secuencia básica o comportamiento normal, a través de la secuencia de mensajes más importantes. Las variantes o secuencias alternativas de mensajes (por ejemplo los posibles errores) Normalmente, un CU tiene una única secuencia básica y una o más secuencias alternativas. 14 DESCRIPCIÓN INFORMAL: CU Enviar Mail Secuencia Básica armar el mensaje y enviarlo al servidor de correo para que lo distribuya a los destinatarios. Algunos caminos o secuencias alternativas podrían ser: No existe el destinatario. El mensaje debe ser enviado con alta prioridad. El remitente decide cancelar el procedimiento antes de enviar el mensaje. 15 5

6 El comportamiento de un caso de uso se puede especificar describiendo un flujo de eventos en forma textual: descripción del caso de uso. La descripción debe ser clara para que alguien ajeno al equipo de desarrollo lo entienda. Se debe incluir: Cómo y cuándo empieza y termina el caso de uso Cuándo interactúa con actores y qué objetos se intercambian El flujo básico y los flujos alternativos 16 En UML, una descripción de CU puede incluir Diagramas de estados. Diagrama de actividades. Diagramas de colaboración y secuencia: Describe la interacción entre una instancia del actor y una instancia del caso de uso. 17 Una instancia de un CU, es la ejecución particular de un CU. Cuando se ejecuta una instancia de un CU, se ejecuta una secuencia de acciones, como se especifica en el CU y siguiendo uno de los posibles caminos del CU. Múltiples caminos son posibles, y pueden ser muy similares. Son las alternativasde secuencias de acción para el caso de uso. 18 6

7 Las instancias de los casos de uso no interactúan entre sí. Se piensa en las instancias de los CU como atómicas, es decir, que se ejecutan completamente o no, pero sin interferencias. Los conflictos entre la ejecución de distintos CU simultáneamente se resuelven en la etapa de diseño. 19 Las relacionesidentifican la comunicación que existe entre: Actores distintos Casos de uso distintos Actores Casos de uso Las relaciones pueden ser: Generalización Extensión Inclusión 20 Los actores se comunican con los casos de uso. Una asociación entre un actor y un caso de uso indica que ese actor usa el CU, sea ingresándole información o consumiendo los datos que provee el CU. La asociación entre actores y CU se representa en el diagrama de casos de uso mediante una línea llena. 21 7

8 Los CU se pueden organizar especificando relaciones de generalización, inclusión, y extensión entre ellos. Estas relaciones sirven para: Factorizar el comportamiento común, extrayendo ese comportamiento común de los CU en que se incluye. Factorizarvariantes, poniendo ese comportamiento en otros CU que lo extienden. 22 La generalizaciónpuede existir entre CU. Significa que el CU hijo hereda el comportamiento y el significado del CU padre. Tanto el padre como el hijo pueden tener instancias concretas. La generalización entre CU se representa por una línea continua con una punta de flecha vacía. 23 Ejemplo: Los CU Obtener Parámetros, Obtener parámetros desde Archivo, Obtener parámetros desde Pantalla. 24 8

9 La relación de inclusiónsignifica que un CU base incorpora el comportamiento de otro CU. Sirve para evitar describir el mismo flujo de eventos repetidas veces. Una relación de inclusión se representa como una dependencia estereotipada con la palabra <<include>> En la descripción del CU base se debe indicar el punto donde se realiza la inclusión. 25 Una relación de extensiónsignifica que un CU base incorpora el comportamiento de otro CU. La extensión puede verse como que el CU que extiende incorpora su comportamiento en el CU base. La relación de extensión se representa como una dependencia estereotipada con la palabra <<extend>> 26 La relación de extensión sirve para: Modelar la parte de comportamiento que se ve como opcional. Modelar un subflujoseparadoque se ejecuta sólo bajo determinadas condiciones. Modelar varios subflujos que se pueden insertar en un punto dado. 27 9

10 1.Obtenerelcasodeusosimpleynormal 2. En cada paso de ese caso de uso, preguntarse Qué puede fallar aquí? Cómo podría funcionar esto de modo diferente? 3. Dibujar todas las variaciones como extensiones del caso de uso dado. Con frecuencia habrá un buen número de extensiones. Si se listan por separado serán mucho más fáciles de entender El Lenguaje Unificado de Modelado. Booch, Rumbaugh, Jacobson El Lenguaje Unificado de Modelado. Manual de referencia. Rumbaugh, Jacobson, Booch El Proceso Unificado de Desarrollo de Software Jacobson, Booch, Rumbaugh Ingeniería de Software orientada a objetos con UML, Java e Internet.Weitzenfeld, Alfredo UML Gota a Gota.Fowler, Scott Programación UML2. Arlow

11 Trabajo Práctico 3 Plantillas para especificación de Casos de Uso 31 11