Diagrama de Casos de Uso (DCU)

Transcripción

1 Diagrama de Casos de Uso (DCU) Escen a 1 Imágenes Diagrama de Casos de Uso Textos ideas fuerza Características del DCU Audio (locución) El Diagrama de Casos de Uso, es un modelo desarrollado por Ivar Jacobson a partir de los años 60, y finalmente divulgado en 1992 e incluido en la primera versión de UML en 1997 Este diagrama asume una descomposición del sistema centrada en actores externos, y responde a preguntas tales como: o cuáles son los requerimientos funcionales del sistema? o qué funciones debe proveer al entorno? o qué debe hacer el sistema para sus usuarios? Música de fondo Además, indica qué hace el sistema sin explicitar cómo lo hace, y describe las posibles modalidades de utilización" o casos de uso (CU) del sistema por parte de actores externos. Este es un modelo que puede entenderse como el establecimiento de un contrato entre el sistema y los actores. Cada Caso de Uso del Diagrama entrega un valor específico para un actor individual del sistema

2 2 Componentes de un DCU El Diagrama de Casos de Uso presenta los siguientes componentes: sistema actor Casos de uso 3 Sistema (System Boundary) El sistema o la frontera del sistema, es el conjunto explícitamente delimitado de Caso de Uso internos, proveídos a los actores externos. Representa el límite entre lo que forma parte del sistema, los Casos de Uso, y lo que es externo al mismo los actores. Frecuentemente se omite por su obviedad.

3 4 5 Actor Clasificación de Actores El Actor en un Diagrama de Caso de Uso, representa un papel o rol que algo o alguien del entorno desempeña con relación al sistema. Corresponde a una clase o conjunto de actores reales (instancias) que viven fuera del sistema e interactúan con él. Interactúa de alguna forma con el sistema, pudiendo originar o no la interacción. Puede ser desempeñado por: una persona o cargo (ej. operador, supervisor) un sistema informático (ej. sistema de monitoreo, sistema transaccional) una sección o departamento (ej. contabilidad, producción) un dispositivo externo de hardware (ej. impresora, sensor) Los actores pueden clasificarse en un Caso de Uso según la iniciación de la interacción en : activo: actor que inicia la interacción o pasivo: cualquier otro actor que interactúe Según el objetivo de la interacción, en :, actor primario o principal: actor beneficiario del valor del Caso de Uso actor secundario: cualquier otro actor que interactúe recuerde que un actor puede ser principal o activo con respecto a un Caso de Uso, y puede ser secundario o pasivo con respecto a otro. Otras personalidades usadas para los actores son: iniciador: es el actor que inicia el Caso de Uso. servidor: actor que provee un servicio al sistema en el Caso de Uso

4 receptor: actor que recibe información del Caso de Uso facilitador: actor que apoya la interacción de otro actor con el sistema las personalidades también son por Caso de Uso: un actor puede comportarse como servidor/facilitador en un Caso de Uso, y comportarse como iniciador/facilitador en otro Un actor pasivo principal (o receptor) ocurre cuando el actor activo (iniciador/facilitador) relacionado es: un representante del actor principal (ej. vendedor en representación del cliente), o un instante del tiempo (ej. último día hábil del mes), o un evento cualquiera (ej. alarma de estado crítico). Según la categoría de la interacción, los actores pueden clasificarse en: general: abstracción de actores especializados en un rol general común especializado: rol particular de un actor general el Actor especializado, hereda los Caso de Uso del actor general, pudiendo agregar otros Caso de Uso. El Conjunto de actores general y especializado(s) configuran,.lo que se conoce como una jerarquía de actores.

5 6 uc Actors Caso de Uso (CU) Un Caso de Uso (Use Case), es un cconjunto de actividades de un sistema que proporciona un valor identificable a un actor principal. Use Case1 El valor que se ofrece motiva al actor principal a usar el sistema por medio del Caso de Uso: explica por qué el actor principal desearía usar el Caso de Uso, Existiendo una dependencia mutua entre el Caso de U y actor principal. La forma ocupada para su representación es la forma verbo + objeto: uc Actors El Caso de uso, representa una porción de la funcionalidad que el sistema entrega al entorno. Corresponde a una visión externa del sistema en la forma de una caja negra. Realizar Pagos Un escenario es una realización de un Caso de Uso, donde instancias de actores intercambian datos y eventos específicos con el sistema. Un escenario es entonces una instancia de un Caso de Uso: un Caso de Uso se dice que es instanciado cada vez que un actor activo inicia la interacción, creándose así un escenario. Con respecto a los escenarios, un Caso de Uso es un conjunto de escenarios posibles que tienen un objetivo común para un actor principal.

6 7 Relaciones entre los componentes del DCU Existen las siguientes relaciones entre: actores: llamada jerarquía de actores actores y Caso de Uso: llamada asociación de comunicación Caso de Uso: dependencias de inclusión y extensión y jerarquías de Caso de Uso (generalización) Asociación de comunicación entre actor y Caso de Uso: muestra una vía de comunicación entre el Caso de Uso y el(los) actor(es) permite el intercambio de datos y eventos 8 Relaciones entre Las relaciones entre los actores y los casos de uso, es

7 actores y Caso de Uso una asociación de comunicación entre actor y Caso de Uso: muestra una vía de comunicación entre el Caso de Uso y el(los) actor(es) permite el intercambio de datos y eventos Con relación a un Caso de Uso tomado como base, la : inclusión: el Caso de Uso incluido muestra parte de la funcionalidad de uno o más Caso de Uso base extensión: Caso de Uso extensor agrega funcionalidad condicionada a un Caso de Uso base Generalización: el Caso de Uso especializado se considera como un caso particular de la funcionalidad de un Caso de Uso general. Estas relaciones son más evidentes analizando el Diagrama de Caso de Uso conjuntamente con su documentación.

8 9 Inclusión de Caso de Uso La Inclusión de Caso de Uso, tiene como objetivo evitar la representación («include» en inglés) redundante de funcionalidad. Existe cuando se extrae una porción de funcionalidad de un Caso de Uso base y se representa aparte en un Caso de Uso incluido. Se entiende que el Caso de Uso incluido forma parte u ocurre dentro del Caso de Uso base. El Caso de Uso incluido: siempre es realizado como parte de la realización del Caso de Uso base

9 no puede ser iniciado directamente puede tener asociado actores pasivos secundarios ( por qué?) En síntesis: el Caso de Uso base incorpora («incluye») al Caso de Uso incluido 10 Extensión de CU La extensión («extend» en inglés) de Caso de Uso, tiene como objetivo : agregar funcionalidad extra sin alterar el Caso de Uso base. Existe cuando se agrega una porción condicionada de funcionalidad, como un Caso de Uso extensor, a la funcionalidad de un Caso de Uso base. Se entiende que el Caso de Uso extensor se agrega como un extra a la funcionalidad normal del Caso de Uso base. Indica que el Caso de Uso extensor interrumpe al Caso de Uso base, cuando la condición es verdadera, para realizarse fuera de éste, retornando posteriormente al Caso de Uso base. La extensión separa explícitamente las funcionalidades: normal no condicionada en el Caso de Uso base extra condicionada en el Caso de Uso extensor Realización de un Caso de Uso extensor es independiente de quien la origina: un Caso de Uso base o un actor activo

10 El Caso de Uso extensor ocurre siempre en los puntos de extensión del Caso de Uso base. Un punto de extensión es el paso dentro de la funcionalidad del Caso de Uso base: donde es evaluada la condición que puede implicar la realización del Caso de Uso extensor, y al que se retorna después de haber sido realizado. Los puntos de extensión pueden indicarse explícitamente en la documentación de un Caso de Uso base. El Caso de Uso extensor: se realiza opcional y separadamente, cuando el Caso de Uso base se realiza puede ser iniciado directamente, independiente del Caso de Uso base puede tener asociado actores de todo tipo, incluso principales ( por qué?) En síntesis: el Caso de Uso extensor se agrega («extiende») al Caso de Uso base. 11 Generalización de Caso de Uso El objetivo de la Generalización de Caso de Uso: es separar funcionalidad general de casos particulares. Existe cuando es posible distinguir funcionalidad general, en un Caso de Uso general, de un caso particular de esta funcionalidad, en un Caso de Uso especializado. El Caso de Uso especializado hereda la funcionalidad y relaciones (con actores y otros Casos de Uso) del Caso de Uso general pudiendo extenderlas o modificarlas. La extensión y modificación de funcionalidad es visible en la documentación asociada.

11 El Conjunto de Caso de Uso general y especializado(s) configuran una jerarquía de Caso de Uso. Cada Caso de Uso especializado es entonces un caso particular del Caso de Uso general. La funcionalidad total de una jerarquía de Caso de Uso puede distribuirse de diferentes formas entre el Caso de Uso general y el(los) El Caso de Uso especializado(s) distintos grados de abstracción del Caso de Uso general El Caso de Uso especializado: siempre puede reemplazar al Caso de Uso general en un escenario puede ser iniciado directamente o a través del Caso de Uso general puede tener asociado cualquier tipo de actor En síntesis: el Caso de Uso especializado es un caso particular del Caso de Uso general.

12 12 Ejemplos de Diagrama de Caso de Uso Suponga un sistema para un cajero automático en que el cliente, previa identificación, selecciona una de las opciones para su cuenta: girar depositar transferir a otra cuenta consultar saldo el diagrama de caso de uso para este sistema es: 13 Ejemplo 2 de Diagrama de Caso de Uso Suponga un sistema de ventas donde, previa solicitud de datos de los clientes, estos pueden hacer pedidos de productos y consultar su estado. Los pedidos pueden incluir catálogos. Las formas de pago posibles son al contado o mediante un crédito acordado. el diagrama de caso de uso para este sistema es:

13