Diagrama de casos de uso

En el Lenguaje de Modelado Unificado, un diagrama de casos de uso es una especie de diagrama de comportamiento UML mejorado. El Lenguaje de Modelado Unificado (UML), define una notacin grfica para representar casos de uso llamada modelo de casos de uso. UML no define estndares para que el formato escrito describa los casos de uso, y as mucha gente no entiende que esta notacin grfica define la naturaleza de un caso de uso; sin embargo una notacin grfica puede solo dar una vista general simple de un caso de uso o un conjunto de casos de uso. Los diagramas de casos de uso son a menudo confundidos con los casos de uso. Mientras los dos conceptos estn relacionados, los casos de uso son mucho ms detallados que los diagramas de casos de uso.

La descripcin escrita del comportamiento del sistema al afrontar una tarea de negocio o un requisito de negocio. Esta descripcin se enfoca en el valor suministrado por el sistema a entidades externas tales como usuarios humanos u otros sistemas. La posicin o contexto del caso de uso entre otros casos de uso. Dado que es un mecanismo de organizacin, un conjunto de casos de uso coherentes y consistentes promueven una imagen fcil de comprender del comportamiento del sistema, un entendimiento comn entre el cliente/propietario/usuario y el equipo de desarrollo.

En esta prctica es comn crear especificaciones suplementarias para capturar detalles de requisitos que caen fuera del mbito de las descripciones de los casos de uso. Ejemplos de esos temas incluyen restricciones de diseo como: rendimiento, temas de escalabilidad/gestin, o cumplimiento de estndares.

El diagrama de la derecha describe la funcionalidad de un Sistema Restaurante muy simple. Los casos de uso estn representados por elipses y los actores estn, por ejemplo, los casos de uso se muestran como parte del sistema que est siendo modelado, los actores no. La interaccin entre actores no se ve en el diagrama de casos de uso. Si esta interaccin es esencial para una descripcin coherente del comportamiento deseado, quizs los lmites del sistema o del caso de uso deban de ser re-examinados. Alternativamente, la interaccin entre actores puede ser parte de suposiciones usadas en el caso de uso. Sin embargo, los actores son una especie de rol, un usuario humano u otra entidad externa puede jugar varios papeles o roles. As el Chef y el Cajero podran ser realmente la misma persona.

ndice

1 Relaciones de Casos de Uso o 1.1 Inclusin (include o use) o 1.2 Extensin (extend) o 1.3 Generalizacin 2 Vase tambin 3 Enlaces externos

Relaciones de Casos de Uso

Las tres relaciones principales entre los casos de uso son soportadas por el estndar UML, el cual describe notacin grfica para esas relaciones. Veamos una revisin de ellas a continuacin:

Inclusin (include o use)

Es una forma de interaccin o creacin, un caso de uso dado puede "incluir" otro caso de uso. El primer caso de uso a menudo depende del resultado del caso de uso incluido. Esto es til para extraer comportamientos verdaderamente comunes desde mltiples casos de uso a una descripcin individual(si el actor realiza el caso de uso base tendra que realizar tambien el caso de uso incluido), desde el caso de uso. El estndar de Lenguaje de Modelado Unificado de OMG define una notacin grfica para realizar diagramas de casos de uso, pero no el formato para describir casos de uso. Mucha gente sufre la equivocacin pensando que un caso de uso es una notacin grfica (o es su descripcin). Mientras la notacin grfica y las descripciones esto no sirve.
Extensin (extend)

Es otra forma de interaccin, un caso de uso dado (la extensin) puede extender a otro. Esta relacin indica que el comportamiento del caso de la extensin se utiliza en casos de uso, un caso de uso a otro caso siempre debe tener extensin o inclusin. El caso de uso extensin puede ser insertado en el caso de uso extendido bajo ciertas condiciones. La notacin, es una flecha de punta abierta con lnea discontinua, desde el caso de uso extensin al caso de uso extendido, con la etiqueta extend. Esto puede ser til para lidiar con casos especiales, o para acomodar nuevos requisitos durante el mantenimiento del sistema y su extensin . "La extensin, es el conjunto de objetos a los que se aplica un concepto. Los objetos de la extensin son los ejemplos o instancias de los conceptos." documentan el comportamiento de un sistema desde el punto de vista de un usuario En otras palabras ser utilizado cuando un caso de uso sea similar a otro pero con ciertas variaciones, un ejemplo claro es que se necesite comprar azucar y podemos seleccionar de entre azucar rubia,blanca o su unidad de medida bolsa , kilo.
Generalizacin

"Entonces la Generalizacin es la actividad de identificar elementos en comn entre conceptos y definir las relaciones de una superclase (concepto general) y subclase (concepto especializado). Es una manera de construir clasificaciones taxonmicas entre conceptos que entonces se representan en jerarquas de clases. Las subclases conceptuales son conformes con las superclases conceptuales en cuanto a la intencin y extensin." En la tercera forma de relaciones entre casos de uso, existe una relacin generalizacin/especializacin. Un caso de uso dado puede estar en una forma especializada de un caso de uso existente. La notacin es una lnea slida terminada en un tringulo dibujado desde el caso de uso especializado al caso de uso general. Esto se asemeja al concepto orientado a objetos de sub-clases, en la prctica puede ser til

factorizar comportamientos comunes, restricciones al caso de uso general, describirlos una vez, y enfrentarse a los detalles excepcionales en los casos de uso especializados...

Casos de Uso Avanzados: Relacin de Inclusin

El modelado de casos de uso persigue capturar la funcionalidad del sistema visto desde el punto de vista de sus operadores -actores- por lo que es fundamentalmente una construccin de elementos de modelado comprensibles por los clientes -stakeholders- y no solo por los analistas. Sin embargo, en ocasiones es conveniente introducir algunos pocos elementos que no sean directamente los conceptos que manejan los clientes. Por ejemplo, en aras de evitar la redundancia, es posible pensar en extraer algunos fragmentos que nos permita indicar en uno o ms casos de uso este fragmento repetido, por referencia en lugar de repetirlo en cada caso. A este proceso de extraccin del fragmento repetido lo modelamos por medio de la relacin de inclusin <<include>>, tal como se ve en el siguiente diagrama:

Fig. 1 - Relacin de inclusin entre casos de uso En la figura, el caso de uso A es un fragmento, que define un trozo de un flujo de eventos que es referido por el caso de uso B. En este tipo de relacin, el caso incluido (el A) debe ser un fragmento, nunca un caso concreto, en tanto que el caso que incluye (el B del ejemplo) si ha de ser un caso de uso completo. A diferencia de la relacin de extensin, aqu ninguno de los casos de uso involucrados puede ser entendidos por completo como piezas aisladas. Por un lado, el caso incluido es solo un fragmento, por lo que no es posible considerarlo un caso de uso pleno; en tanto que el caso que incluye al hacer referencia a un fragmento externo tiene necesariamente que ser entendido en presencia del fragmento. Formalmente, como para el glosario: Relacin de Inclusin <<include>> Un caso de uso concreto incluye a un fragmento de caso de uso, cuando como parte de su descripcin breve o su flujo de eventos, se hace referencia al texto del fragmento; de forma tal que lo dicho en el fragmento pasa a ser parte de la especificacin del caso de uso.

Para lograr que se entienda el concepto, nada mejor que un ejemplo. Supongamos que estamos hablando de un sistema de gestin de agenda de un empresas con gerentes y asistentes. En este sistema hemos identificado dos casos de uso: Cdigo: UC-0100. Nombre: Acepta cita. Actor: Gerente. Descripcin: El Gerente visualiza su calendario de citas y aprueba aquellas citas que desee aceptar. Cdigo: UC-0200. Nombre: Coordina cita. Actor: Asistente. Descripcin: El asistente busca un momento apropiado para las citas pendientes al visualizar el calendario de citas del Gerente. Indica para cada cita propuesta la descripcin, el da y la hora. Tabla 1 - Casos de uso del sistema Como se nota, en ambos casos se requiere de visualizar la agenda. Es posible imaginar que esta funcin abarca no solo la visualizacin del calendario, sino tambin ciertas funciones de bsqueda y filtrado por criterios. Para especificar esta funcionalidad pero evitar hacerlo en cada uno de los flujos de eventos de los casos de uso ya definidos, se opta por crear un fragmento que contenta esos detalles e incluirlo en los casos de uso originales. La situacin da lugar al siguiente diagrama:

Fig. 2 Modelo ejemplo de relacin de inclusin

de

casos

de

uso

con

un

De esta forma, evitamos tener que definir en mltiples lugares una misma funcionalidad. Sin embargo, el fragmento que se incluye ha de ser visto siempre como lo que es: un fragmento sin significado completo. En verdad es una lastima que de momento no tengamos una forma de marcar a los fragmentos de manera que se diferencien a simple vista de los casos de uso. Sugiero que al menos, en tanto surge un estereotipo estndar para esta tarea, tengamos una serie de numeracin particular para los fragmentos. O bien, tomar la iniciativa y definir un estereotipo de UML por nosotros mismos. Naturalmente que a la hora de hacer la especificacin detallada de los casos de uso, en particular en los flujos de eventos, debemos marcar muy claramente en que lugar se ha de realizar la inclusin de lo dicho en el fragmento. La relacin de inclusin es claramente diferente a la relacin de extensin y espero que haya quedado claro. La inclusin es una relacin entre un caso de uso concreto y un fragmento, en tanto que la extensin involucra casos de uso concretos.

Por otra parte, a diferencia de la relacin de extensin, la inclusin en cierta forma modifica al caso que incluye, por cuanto el fragmento define una parte de la funcionalidad del caso de uso completo. Esto significa que el caso de uso que incluye no puede ser entendido por completo en ausencia del fragmento que se incluye; algo muy diferente a la situacin en una relacin de extensin.

Casos de Uso Avanzados: Relacin de Extensin

En muchas ocasiones el uso de caractersticas avanzadas de los casos de uso generan dudas en los equipos de desarrollo. La razn bsica es que estos modelos deben ser claros antes que cualquier otra cosa, lo que lleva a evitar el uso de las relaciones de inclusin y extensin, entre otras caractersticas. Sin embargo, por muy de acuerdo que podamos estar con el deseo de claridad y sencillez, existen situaciones en que hacer uso de una relacin avanzada entre casos de uso mejora en lugar de reducir, la claridad del modelo de requisitos. De ah por tanto que todo analista de requisitos debe comprender perfectamente el significado de estas relaciones. En el presente post abordamos la relacin de extensin <<extend>>. Tcnicamente como para el glosario, la relacin de extensin <<extend>> se define como: Relacin <<extend>> Un caso de uso extiende a otro cuando sin alterar a este, se incorpora su funcionalidad como parte integral del primero. Se denota con una relacin que apunta del caso extendido al caso base y la conexin se hace o bien al principio del flujo de eventos principal del caso base o en alguno de los puntos de extensin que este haya definido. La notacin grfica es la siguiente:

Fig. 1 - Relacin de extensin <<extend>> La relacin del ejemplo significa que un caso de uso ya existente (el caso A) se aprovecha en la definicin de un segundo caso (el caso B). Dado que la reutilizacin que requerimos agrega funcionalidad pero no altera al caso base, se ha optado por la relacin de extensin. Dicha relacin se ha denotado grficamente con una flecha de dependencia desde el caso extendido (el caso B) al caso base (el caso A). La dependencia la hemos estereotipado con <<extend>> para que quede claro lo que pretendemos decir.

A nivel de los flujos de eventos, se podra decir que el flujo principal del caso base no se ve alterado, pero que en cambio, el flujo de eventos del caso extendido hace referencia al primero, de manera tal que no puede ser entendido en ausencia de los pasos del caso base. A fin de contar con un ejemplo completo, consideremos un sistema de compras electrnico. Digamos que este sistema va a atender tanto a clientes finales como a clientes corporativos, permitiendo que adquieran productos en nuestra tienda en lnea. La diferencia ser que los clientes corporativos hacen compras masivas, quizs programando la entrega a lo largo de un periodo de tiempo de lo que compraron. Esta visin la podemos expresar en el siguiente diagrama:

Fig. 2 Ejemplo de de tienda electrnica en Internet

relacin

<<extend>>

en

un

sistema

Ahora si vamos al caso de uso base Compra artculo (UC-0100) podramos tener la funcionalidad de escoger el artculo a comprar y el de pagar con tarjeta de crdito, por ejemplo. Esta funcionalidad esta disponible a los clientes finales, tal como se ve en el diagrama. Por su parte, los clientes corporativos pueden escoger el artculo a comprar y el modo de pago: digamos tarjetas de crdito. Adems el caso de uso captura tambin la funcionalidad de programar la entrega parcial de lo comprado a lo largo de un periodo de tiempo. Dado

que gran parte del caso de uso Compra masiva (UC-0200) es idntica a la encontrada en el caso del cliente final, optamos por reutilizar la especificacin por va de la relacin de extensin. Los criterios a aplicar para saber si la relacin de extensin es aplicable son los siguientes: 1. 2. 3. 4. Hay cuando menos un caso base y un caso extendido. El caso base no se ve modificado por la existencia del caso extendido. El caso base es un caso concreto atado a cuando menos un actor. El caso extendido incorpora al caso base por completo.

La relacin de extensin guarda relacin con todos los restantes tipos de reutilizacin que estn definidas para los casos de uso; en particular la relacin es muy intima con la relacin de inclusin <<include>> sin embargo la diferencia primordial entre <<extend>> e <<include>> es la modificacin del caso base. Extensin no implica cambio, en tanto que la inclusin aade funcionalidad al caso base. Otra relacin, la herencia, es similar tambin a la extensin. En este caso la diferencia es que la herencia cambia o puede cambiar, la naturaleza de lo dicho en el caso base. Por ejemplo, podemos decir que aquello que fue llamado artculo en el caso base es ahora referido ms detalladamente como libro o juguete. La herencia de casos de uso reutiliza al caso base s, pero nos permite alterar la semntica de los detalles; algo que la relacin de extensin (ni la de inclusin) pueden hacer. Por tanto concluyamos: la relacin de extensin permite reutilizar una especificacin pero sin modificar al caso base.