DIAGRAMAS DE CASO DE USO

Jacobson (1994), además de introducir los casos de uso como elementos primarios del desarrollo del software, también diseñó un diagrama para la representación gráfica de los casos de uso. El diagrama de casos de uso es ya también parte del UML.

Actores

Empleamos el término actor para llamar así al usuario, cuando desempeña ese papel con respecta al sistema.el gerente de comercial, el comerciante, el agente de ventas y el sistema de contabilidad.

En la mencionada organización, probablemente habrá diversos comerciantes. Además, un usuario puede desempeñar varios papeles. Por ejemplo, un comerciante de edad madura podría desempeñar el papel de gerente de comercio y además ser un comerciante normal. Por otra parte, un comerciante puede ser también agente de ventas. Cuando se trata con actores, conviene pensar en los papeles, no en las personas ni en los títulos de sus puestas.

Los actores llevan a cabo casos de uso. Un mismo actor puede realizar muchos casos de uso; A la inversa, un caso de uso puede ser realizado Por varios actores.

En la práctica, los actores son muy útiles cuando se trata de definir los casos de uso. Al enfrentarse con un sistema grande, puede ser difícil obtener una lista de casos de uso. Es más fácil en tales situaciones definir la lista de los actores y después tratar de determinar los casos de uso de cada actor.

Obsérvese que no es necesario que los actores sean seres humanos, a pesar de que los actores estén representados por figuras humanas en el diagrama del caso de uso. El actor puede ser también un sistema externo que necesite cierta información del sistema actual. En la figura 3-1 se puede apreciar la necesidad de actualizar las cifras del sistema de contabilidad.

El tema de las interacciones con sistemas externos produce mucha confusión y variaciones de estilo entre los usuarios de los diagramas de casos de uso. .

Algunos sienten que todas las interacciones con sistemas remotas deben aparecer en el diagrama. Por ejemplo, si se necesita acceder a Reuters con el fin de cotizar un contrato, se deberá mostrar el vínculo entre el caso Negocia precio y Reuters.

Algunas personas consideran que sólo se deben mostrar los casos de uso con interacción externa, cuando quien inicia el contacto es otro sistema. Según esta regla, sólo se mostraría el caso de uso del sistema de contabilidad si dicho sistema invocara algún proceso que le dijera al sistema fuente que la hiciera.

Algunas personas consideran que sólo se deben mostrar los actores del sistema cuando ellas sean las que necesiten el caso de uso. Por tanto, si el sistema genera cada noche un archivo que después es recogido por el sistema de contabilidad, entonces éste es el actor que corresponde, debido a que es quien necesita el archivo generado.

Otros más sienten que constituye un enfoque equivocado considerar que un sistema es un actor. Por el contrario, consideran que un actor es un usuario que desea algo del sistema (Por ejemplo, un archivo en particular). En el caso de nuestro ejemplo de sistema, los actores serían los auditores internos de la compañía.

Tomando en cuenta todos los factores, me inclino por la opción 3.

Todos los casos de uso tratan sobre funcionalidad requerida externamente. Si el sistema de contabilidad necesita un archivo, entonces ése es un requerimiento que debe satisfacerse.

El acceso a Reuters es importante, pero no una necesidad del usuario. Si sigue la opción 4, se termina por analizar el sistema de contabilidad, cosa que probablemente usted no quisiera hacer. Dicho lo anterior, siempre se deben cuestionar los casos de uso con los actores del sistema, descubrir los objetivos reales del usuario y considerar formas alternas para lograrlos.

Cuando trabaje con actores y casos de uso, no se preocupe mucho por la relación exacta entre ellos. Lo que le interesa casi siempre son los casos de uso; los actores son sólo un modo de llegar a ellos. Siempre y cuando obtenga todos los casos de uso, no se preocupe por los detalles acerca de los actores.

Sin embargo, una situación en la que los actores sí desempeñan un papel es en la configuración del sistema para varios tipos de usuarios. Si el sistema tiene casos de uso que corresponden a funciones de usuario de alto nivel, usted puede emplear los vínculos entre casos de uso y actores para hacer los perfiles de los usuarios. Cada usuario tendría una lista asociada de nombres de actores con la que se determinarían los casos de uso que puede ejecutar cada uno.

Otra buena razón para rastrear a los actores es la necesidad de saber cuáles son los casos de uso que quiere cada uno. Esto puede ser importante cuando usted esté evaluando las necesidades que compiten entre ellos. La comprensión de los actores puede servir para negociar entre demandas de desarrollo que compiten entre sí. También pueden ser útiles para especificar una política de seguridad.

Algunos casos de uso no tienen vínculos claros con actores específicos. Considérese una compañía de servicios públicos. Por supuesto, uno de sus casos de uso es "envío de factura". No es tan fácil, sin embargo, identificar un actor asociado. No existe un papel de usuario en particular que solicite una factura. La factura se envía al cliente, pero el cliente no protestaría si esto no se llevara a cabo. Lo que más se parece a un actor es el Departamento de facturación, en el sentido de que obtiene un valor del caso de uso. Pero la facturación generalmente no interviene en la ejecución del caso de uso.

Los actores pueden tener varios papeles con respecto a un caso de uso. Pueden ser los que obtienen un valor del caso de uso, o tal vez sólo participen en él. Dependiendo de cómo se utilice la relación entre los actores será la importancia de los papeles que desempeñen los actores. Por mi parte, suelo preocuparme más por controlar el desarrollo del sistema. Así, en general, siento un mayor interés por quién quiere que se construya un caso de uso (por lo general, quienes obtienen un valor del caso de uso).

La clave es tener en cuenta que algunos casos de uso no saltarán a la vista como resultado de ponerse á pensar en los casos de uso de cada actor. Si esto sucede, no se preocupe demasiado. Lo importante es comprender los casos de uso y los objetivos del usuario que satisfacen.

Una buena fuente para identificar los casos de uso son los eventos externos. Piense en todos los eventos del mundo exterior ante los cuales usted quiera reaccionar. Un evento dado puede provocar una reacción en el sistema en la que no intervenga el usuario, o puede causar una reacción que provenga principalmente de los usuarios. La identificación de los eventos ante los que se necesitará reaccionar será de ayuda en la identificación de los casos de uso

Uses y extends

 Éstos representan las relaciones de uses (usa) y extends (extiende) entre los casos de uso. Con frecuencia, tales relaciones son fuente de confusión para quienes mezclan los significados de ambos conceptos, de modo que tómese el tiempo necesario para comprenderlos.

Se usa la relación extends cuando se tiene un caso de uso que es similar a otro, pero que hace un poco más.

En nuestro ejemplo, el caso de uso es Captura negociación. Éste es un caso en que todo sucede sin contratiempos. Sin embargo, hay situaciones que pueden estropear la captura de una negociación. Una de ellas surge cuando se excede algún límite, por ejemplo, la cantidad máxima que la organización de comercio ha establecido para un cliente en particular. En este ejemplo, dado que no efectuamos el comportamiento habitual asociado con dicho caso de uso, efectuamos una variación.

Podríamos poner esta variación dentro del caso de uso Captura negociación. Sin embargo, esto llenaría dicho caso de uso de una gran cantidad de lógica especial, la cual oscurecería el flujo "normal".

Otro modo de abordar la variación es poner la conducta normal en un caso y la conducta inusual en cualquier otro lado. A continuación describiremos la esencia de la relación extends.

Primero obtenga el caso de uso simple y normal.

En cada paso de ese caso de uso, pregúntese "¿Qué puede fallar aquí?", "¿Cómo podría funcionar esto de modo diferente?"

Dibuje 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.

Puede suceder que se tenga qué dividir un caso de uso tanto en la etapa de elaboración como en la de construcción. Durante la elaboración, suelo dividir los casos de uso que se estén volviendo muy complicados.

En la etapa de construcción del proyecto(Enlace con un H2 del capitulo 2), realizo la división cuando no puedo construir un caso de uso completo en una sola iteración. Divido los casos de uso complejos en un caso normal y unas cuantas extensiones, y luego construyo el caso normal en una sola iteración y las extensiones como partes de una o varias iteraciones posteriores. (Por supuesto, aquí sucederán cambios en el plan de compromisos, lo que deberá negociarse con los usuarios.)

Las relaciones uses ocurren cuando se tiene una porción de comportamiento que es similar en más de un caso de uso y no se quiere copiar la descripción de tal conducta. Por ejemplo, tanto Analiza riesgo como Negociación precio requieren valuar la negociación. La descripción de la valuación de la negociación requiere de bastante escritura, y yo odio las operaciones de copiar y pegar. Por tanto, elaboro un caso de uso separado, Negociación valor, para esta situación y me refiero a él desde los casos de uso originales.

Adviértanse las diferencias entre extends y uses. Ambos implican la factorización de comportamientos comunes de varios casos de uso, dejando un solo caso de uso común que es empleado, o extendido, por otros varios casos de uso. No obstante, la intención es la que cambia.

En sus vínculos con los actores, estos dos tipos de relación implican asuntos diferentes. Tratándose de la relación extends, los actores tienen que ver con los casos de uso que se están extendiendo. Se supone que un actor dado se encargará tanto del caso de uso base como de todas las extensiones. En cuanto a las relaciones uses, es frecuente que no haya un actor asociado con el caso de uso común. Incluso si lo hay, no se considera que esté llevando a cabo los demás casos de uso.

Aplique las siguientes reglas.

Utilice extends cuando describa una variación de conducta normal.

Emplee uses para repetir cuando se trate de uno o varios casos de uso y desee evitar repeticiones.

Es probable que oiga usted el término escenario en conexión con los casos de uso. Cabe aclarar que este término se emplea de manera inconsistente. Algunas veces, escenario se usa como sinónimo de caso de uso. En el contexto del UML, la palabra escenario se refiere a una sola ruta a través de un caso de uso, una ruta que muestra una particular combinación de condiciones dentro de dicho caso de uso. Por ejemplo, para ordenar algunas mercancías, tendremos un solo caso de uso con varios escenarios asociados: uno en el cual todo va bien; otro donde no hay suficientes mercancías; otro en el que nuestro crédito es rechazado, y así por el estilo.

Conforme vaya realizando sus tareas de modelado, encontrará modelos que expresen la manera de hacer sus casos de uso, ya sea entre el software o entre la gente. Es evidente que hay más de una manera de llevar a cabo un caso de uso. En la jerga del UML, decimos que un caso de uso puede tener muchas realizaciones.

Con frecuencia se realizan varios bosquejos sobre los distintas formas de resolver un caso de uso, con el fin de discutirlas y determinar con cuál va a trabajar. Si hace esto, recuerde guardar información acerca de las realizaciones descartadas, incluyendo las notas de por qué se descartaron. No quisiera contarles cuántas horas he desperdiciado en discusiones del estilo de "yo sé que existe una razón por la que no hicimos eso, pero..."