CAPITULO 17

DIAGRAMAS DE CASOS DE USO

 

EN ESTE CAPÍTULO
 

 
 

Los diagramas de caso de uso son uno de los cinco tipos de diagramas en UML para modelar aspectos dinámicos de sistemas (diagramas de actividad, diagramas de estados, diagramas de secuencia y diagramas de colaboración son otros cuatro tipos de diagramas en UML para modelar los aspectos dinámicos de un sistema). Los diagramas de casos de uso son importantes para modelar el comportamiento de un sistema, un subsistema o una clase. Cada uno muestra un conjunto de casos de uso, actores y sus relaciones.

Se aplican los diagramas de casos de uso para modelar las vistas de casos de uso de un sistema. Para la mayor parte, esto involucra el modelado el contexto de un sistema, subsistema, o clase, o modelar las necesidades del comportamiento de esos elementos.

Los diagramas de casos de uso son importantes para visualizar, especificar, y documentar el comportamiento de un elemento. Ellos hacen sistemas, subsistemas, y clases entendibles para presentar una vista exterior de cómo estos elementos pueden ser usados dentro del contexto. Los diagramas de caso de uso son también importantes para probar sistemas ejecutables a través de ingeniería hacia adelante y para comprender sistemas ejecutables a través de ingeniería inversa.

 

 
INICIANDO
 

Supongamos que alguien nos entrega una caja. Sobre un lado de esta caja, hay algunos botones y un pequeño panel LCD. La caja no tiene descripción y no sabemos como se usa. Pudimos aleatoriamente presionar los botones, pero has estado presionando os botones para saber que hace la caja o como se usa apropiadamente; esto lo sabrás invirtiendo mucho tiempo en prueba y error.

Con UML, aplicas los diagramas de casos de uso para visualizar el comportamiento de un sistema, subsistema, o clase para que los usuarios puedan comprender como usar ese elemento, y por tanto que los desarrolladores puedan implementar esos elementos. Como muestra la figura 17-1, puedes proveer diagramas de casos de uso para modelar el comportamiento de esta caja la cual puede llamarse teléfono celular.
 
 

 
 FIGURA 17.1
 
 

 

TERMINOS Y CONCEPTOS

  Un diagrama de casos de uso es un diagrama que muestra un conjunto de casos de uso, actores y sus relaciones.

 

 
PROPIEDADES COMUNES
 

Un diagrama de casos de uso es simplemente un tipo especial de diagrama que comparten propiedades comunes con otros diagramas un nombre y un contenido gráfico que estan dentro de un modelo. Lo que distingue un diagrama de casos de uso de los otros tipos es su particular contenido.

 

 
CONTENIDO
 

Los diagramas de casos de uso comúnmente contienen:

 

Igual que todos los diagramas, los casos de uso pueden contener notas y restricciones.

 

 
USOS COMUNES
 
Se aplican los diagramas de casos de uso para modelar la vista estática de los casos de uso de un sistema. Esta primera vista soporta el comportamiento de un sistema el alejamiento de los servicios visibles que el sistema provee en el contexto del medio ambiente.

Cuando modelas la vista estática de un caso de uso de un sistema, podrás típicamente aplicar diagramas de casos de uso de dos maneras diferentes:

 

1. Modelar el contexto de un sistema.

Modelar el contexto de un sistema implica dibujar una línea alrededor del sistema completo y afirmando con actores fuera del sistema e interactuando con este. Aquí podrás aplicar los diagramas de casos de uso para especificar los actores y el manejo de sus roles.

 

2. Modelar las necesidades de un sistema.

Modelar los requerimientos de un sistema implica especificar que es lo que hará el sistema (desde un punto de vista fuera del sistema), independientemente de cómo el sistema lo hará. Pudimos aplicar diagramas de casos de uso para especificar el comportamiento deseado del sistema. De esta manera, un diagrama de casos de uso nos da una vista del sistema completo como una caja negra; puedes ver que hay fuera del sistema y puedes ver como el sistema reacciona a cosas de fuera, pero no puedes ver como el sistema trabaja en su interior.

 

 

 
TÉCNICAS COMUNES DE MODELADO
 
MODELANDO EL CONTEXTO DE UN SISTEMA
 

Dado un sistema cualquier sistema- algunas cosas pueden vivir dentro de este, y otras vivir fuera de este. Por ejemplo, en un sistema de validación de tarjeta de crédito, puedes encontrar algunas cosas como cuentas, transacciones, y agentes de detección de fraude dentro del sistema. Similarmente, podrás encontrar cosas como clientes de tarjeta de crédito e instituciones de venta fuera del sistema. Las cosas que viven dentro del sistema son responsables para llevar al exterior el comportamiento que suponen el sistema proporciona.

Todas estas cosas en el exterior que interactuan con el sistema constituye el contexto del sistema. Este contexto constituye el medio ambiente en el cual el sistema vive.

 En UML, puedes modelar el contexto de un sistema con un diagrama de casos de uso, enfatizando los actores que rodean el sistema.

 

Para modelar el contexto de un sistema,

 
 

FIGURA 17-2

 

 

Por ejemplo, la figura muestra el contexto de un sistema de validación de tarjeta de crédito, con un énfasis sobre los actores que rodean al sistema. Puedes encontrar Clientes, de los cuales hay dos tipos ( Clientes individuales y Clientes corporativos). Estos actores tienen los roles que lo humanos juegan cuando interactuan con el sistema. En este contexto, hay actores que representan otras instituciones, como son Institución de venta ( con el cual un Cliente ejecuta una transacción para comprar un artículo o un servicio) e Institución Financiera Patrocinadora. En el mundo real, estos últimos dos actores son parecidos a los sistemas de software-intensivo.

Esta misma técnica se aplica para modelar el contexto de un subsistema. Un sistema en un nivel de abstracción es frecuentemente un subsistema de un gran sistema en un alto nivel de abstracción. Modelando el contexto de un subsistema es útil cuando estas construyendo sistemas de sistemas interconectados.

 
 

MODELANDO LAS NECESIDADES DEL SISTEMA.
 

Un requerimiento es una característica de diseño, atributo, o comportamiento de un sistema. Con las necesidades de un sistema, se acuerda un pacto establecido entre las cosas fuera del sistema y el sistema por si mismo, cuando se declara que se espera que el sistema realice. En la mayor parte no se cuida como el sistema lo hace, solo se cuida que es lo que hace. Cuando se construye un sistema es importante iniciar con acuerdos acerca de que es lo que hará el sistema, aunque se podrá desarrollar el entendimiento de esos requerimientos conforme iterativa e incrementalemente se desarrolle el sistema.

Los requerimientos pueden ser expresados en varias formas, desde texto hasta expresiones en un lenguaje formal, y cualquier cosa entre ellos. Muchos si no todos, de los requerimientos funcionales de un sistema pueden ser expresados como casos de uso, y los diagramas de casos de uso UML son esenciales para manejar estos requerimientos.

 
Para modelar los requerimientos de un sistema.

 

La figura se expande sobre el diagrama de caso de uso anterior. El diagrama es valioso por que ofrece un inicio común para usuarios finales, expertos, y desarrolladores para visualizar, especificar, construir y documentar sus decisiones acerca de las necesidades funcionales del sistema. Por ejemplo, Detectar Fraude es un comportamiento importanete para ambos: una Institución Financiera e Institución de Ventas. Similarmente, Reporte del Estado de una Cuenta es un comportamiento requerido del sistema por varias Instituciones en su contexto.

Las necesidades modeladas por el caso de uso Administrador de Red es un poco diferente de todos porque representa un comportamiento secundario del sistema.

 

 
 
FIGURA 17.3
 
 

 

 
INGENIERÍA HACIA ADELANTE E INVERSA

La mayoría de los diagramas UML, incluyendo clases, componentes, y diagramas de estado, son claros candidatos para ingeniería hacia delante e inversa por que tienen una analogía en código ejecutable. Los diagramas de casos de uso describen como un elemento se comporta, no como es implementado, por esto no se le aplica directamente la ingeniería hacia delante o hacia atrás.

Ingeniería hacia delante. Proceso de transformar un modelo a código a través de un mapeo hacia un lenguaje de implementación. Un diagrama de casos de uso puede aplicársele ingeniería hacia delante para formas de prueba para el elemento para el cual aplica. Cada caso de uso en un diagrama de casos de uso especifica un flujo de eventos ( y variantes de esos flujos ), y estos flujos especifican como se espera se comporte el elemento. Un caso de uso bien estructurado podrá especificar pre y post condiciones que pueden ser usadas para definir un estado inicial para la prueba y las post-condiciones pueden ser usadas para definir un criterio exitoso. Para cada caso de uso en un diagrama, se pueden crear pruebas que puedes ejecutar cada vez que se libera una nueva versión del elemento, de este modo se confirma que el elemento trabaja como se necesita antes de confiar otros elementos a él.

 

Para aplicar ingeniería hacia delante en un diagrama de casos de uso

 

Ingeniería Inversa. Es el proceso de transformar código hacia un modelo a través de un mapeo desde un lenguaje específico de implementación. Automáticamente la ingeniería inversa en un diagrama de caso de uso esta mucho más allá del esto del arte. Simplemente por que hay una pérdida de información cuando se cambia de una especificación de cómo un elemento se comporta hacia como es implementado. Sin embargo, se puede estudiar el sistema existente y entender el comportamiento a mano; esto será lo que se colocará en forma de diagrama de casos de uso.

 
Para aplicar ingeniería inversa

 

 
SUGERENCIAS
 

Cuando se crea un diagrama de casos de uso en UML, recuerda que cada diagrama de caso de uso es solo una presentación gráfica de la vista estática de un caso de uso de un sistema. No un simple diagrama de casos de uso necesita capturar cada cosa en la vista de casos de uso de un sistema. Colectivamente, todos los diagramas de casos de uso de un sistema representan la vista estática del sistema completo; individualmente , representan solo un aspecto.

  Para una buena estructura de diagramas de casos de uso.

 

 

Cuando se dibuja un diagrama de casos de uso.