Tareas: Análisis de Caso de Uso

Entiendo por análisis la habilidad de ver partes en aquello que se ha visto como un todo, en concreto, el análisis de casos de uso ha de visualizar instancias de objetos por ahora de clase indeterminada, que por medio de su colaboración dan lugar a la funcionalidad especificada en el caso de uso.

A esto se le llama también Realización de Caso de Uso al nivel de Modelo de Análisis, un nombre largo que en verdad no sé a que se debe. El siguiente diagrama de UML muestra la relación de realización entre un caso de uso y su escenario de análisis.

Fig. 1 – Realización de Caso de Uso

Si contamos con un modelo de dominio bien hecho, el análisis de casos de uso puede ser realizado por medio de la identificación de cuales de las clases de aquel modelo que participan en el caso de uso, y presentar estas en un diagrama de interacción: ya sea de colaboración o más normalmente, de secuencia.

El siguiente diagrama SPEM muestra la estructura de esta tarea:

Fig. 2 – Diagrama SPEM de la Tarea Analizar Caso de Uso
(Versión con Modelo de Dominio)

Por otra parte, RUP nos sugiere una aproximación alternativa: utilizar las llamadas clases de análisis; que son clasificadores de UML estereotipados en tres tipos básicos: control, entidad e interfaz. Esta técnica no presupone la existencia de un modelo de dominio y aunque en su momento daré un ejemplo, no es la aproximación que considero mejor integrada con el resto del método.

El siguiente diagrama ilustra la estructura de la Tarea Encontrar Clases de Análisis, que es la variedad del Análisis de Caso de Uso que utiliza clases de análisis de RUP en lugar de un modelo de dominio.

Fig. 3 – Diagrama SPEM de la Tarea Encontrar Clases de Análisis
(Versión de Análisis de Caso de Uso sin Modelo de Dominio)

Dejando de lado la diferencia en el producto, quiero que se note que en el primer caso la entrada es un Caso de Uso y un Actor, por oposición al Modelo de Casos de Uso completo, que si es la entrada de la segunda aproximación.

Justamente lo anterior es lo que rescata la técnica de las clases de análisis a mis ojos; uno puede tomar no uno, sino varios casos de uso relacionados por algún concepto, y analizarlos en su conjunto; lo que nos lleva a conclusiones diferentes y útiles.

Definimos Caso de Uso como…

Hoy en día los casos de uso son la principal forma de capturar los requisitos de los proyectos de desarrollo de software; y de ahí por tanto que sean el lugar de inicio más común para los libros que explican métodos de desarrollo. Sin embargo son también quizás, el concepto peor entendido de todos, probablemente por su sencillez y por estar enfocado a su tarea de modelar requisitos pero dejar poco lugar para nada más.

Formalmente, para el glosario:

Caso de Uso Escenario que narra la interacción entre un sistema y una entidad externa a la que se le provee una funcionalidad. Los casos de uso son principalmente cuerpos de texto de definición de requisitos funcionales aunque por medio de extensiones pueden ser utilizados por fuera de este ámbito.

El lenguaje UML incluye en su especificación el soporte para los casos de uso, permitiendo representar por medios visuales diversas características de estos; complementando así lo indicado en las especificaciones en formato texto de cada caso de uso.

Considerando que los sistemas de información modernos son altamente interactivos, tanto por su relación con múltiples operadores humanos como por su necesidad de integrarse e interactuar con otros sistemas, es necesario entonces que los requisitos sean capturados respetando esta naturaleza interactiva. Es decir, si bien antes nos bastaba preguntar qué debe hacer el sistema ahora es necesario agregar para cada uno de sus usuarios.

Por sencillez, llamaremos actor a cada operador externo, tanto si es un sistema aparte del nuestro como si se trata de un operador humano.

Con el enfoque de los casos de uso, el sistema luce diferente para cada uno de sus actores. A unos, la funcionalidad que ofrece serán la que se corresponde con su trabajo, en tanto que a otros, será la que corresponda con la necesidad de estos. Esta organización de la funcionalidad según el punto de vista de cada actor es clave para poder capturar rápida y efectivamente, los requisitos funcionales de un sistema altamente interactivo.

En su conjunto, los casos de uso constituyen el llamado Modelo de Requisitos Funcionales el cual puede ser complementado con documentos que detallen Requisitos No Funcionales en una forma más tradicional. Es responsabilidad del Analista de Requisitos el construir y el mantener estos artefactos.

El Modelado de Casos de Uso es hoy por hoy, la principal técnica de captura de requisitos funcionales, y es una pieza central en los procesos de desarrollo de pruebas, de la interfaz hombre-maquina, de la documentación de usuario y manuales así como de guiar el análisis y diseño de la solución técnica del desarrollo. Es decir, que el proceso de desarrollo se encuentra centrado en casos de uso.

Si bien los casos de uso pueden ser manejados en forma gráfica, con ayuda de los diagramas de caso de uso del lenguaje UML, la información total que estos contienen va mucho más allá. Entre las propiedades de los casos de uso se encuentran los flujos de eventos, las pre condiciones, los puntos de extensión y muchos más elementos, solo posibles de ser representados con ayuda de un documento de texto. En este blog, podrá encontrar un ejemplo completo.

Casos de Uso Avanzados: Relación de Inclusión

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 construcción 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 más casos de uso este fragmento repetido, por referencia en lugar de repetirlo en cada caso.

A este proceso de extracción del fragmento repetido lo modelamos por medio de la relación de inclusión <<include>>, tal como se ve en el siguiente diagrama:

Fig. 1 – Relación de inclusión 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 relación, 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 relación de extensión, 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:

Relación de Inclusión <<include>> Un caso de uso concreto incluye a un fragmento de caso de uso, cuando como parte de su descripción 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 especificación del caso de uso.

Para lograr que se entienda el concepto, nada mejor que un ejemplo. Supongamos que estamos hablando de un sistema de gestión de agenda de un empresas con gerentes y asistentes. En este sistema hemos identificado dos casos de uso:

Código: UC-0100.
Nombre: Acepta cita.
Actor: Gerente.
Descripción: El Gerente visualiza su calendario de citas y aprueba aquellas citas que desee aceptar.

Código: UC-0200.
Nombre: Coordina cita.
Actor: Asistente.
Descripción: El asistente busca un momento apropiado para las citas pendientes al visualizar el calendario de citas del Gerente. Indica para cada cita propuesta la descripción, el día 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 función abarca no solo la visualización del calendario, sino también ciertas funciones de búsqueda 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 situación da lugar al siguiente diagrama:

Fig. 2 – Modelo de casos de uso con un
ejemplo de relación de inclusión

De esta forma, evitamos tener que definir en múltiples 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 estándar para esta tarea, tengamos una serie de numeración 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 especificación 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 inclusión de lo dicho en el fragmento.

La relación de inclusión es claramente diferente a la relación de extensión y espero que haya quedado claro. La inclusión es una relación entre un caso de uso concreto y un fragmento, en tanto que la extensión involucra casos de uso concretos.

Por otra parte, a diferencia de la relación de extensión, la inclusión 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 situación en una relación de extensión.

Casos de Uso Avanzados: Relación de Extensión

En muchas ocasiones el uso de características avanzadas de los casos de uso generan dudas en los equipos de desarrollo. La razón básica es que estos modelos deben ser claros antes que cualquier otra cosa, lo que lleva a evitar el uso de las relaciones de inclusión y extensión, entre otras características.

Sin embargo, por muy de acuerdo que podamos estar con el deseo de claridad y sencillez, existen situaciones en que hacer uso de una relación 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 relación de extensión <<extend>>.

Técnicamente como para el glosario, la relación de extensión <<extend>> se define como:

Relación <<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 relación que apunta del caso extendido al caso base y la conexión se hace o bien al principio del flujo de eventos principal del caso base o en alguno de los puntos de extensión que este haya definido.

La notación gráfica es la siguiente:

Fig. 1 – Relación de extensión <<extend>>

La relación del ejemplo significa que un caso de uso ya existente (el caso «A») se aprovecha en la definición de un segundo caso (el caso «B»). Dado que la reutilización que requerimos agrega funcionalidad pero no altera al caso base, se ha optado por la relación de extensión. Dicha relación se ha denotado gráficamente 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 podría 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 electrónico. Digamos que este sistema va a atender tanto a clientes finales como a clientes corporativos, permitiendo que adquieran productos en nuestra tienda en línea. La diferencia será que los clientes corporativos hacen compras masivas, quizás programando la entrega a lo largo de un periodo de tiempo de lo que compraron. Esta visión la podemos expresar en el siguiente diagrama:

Fig. 2 – Ejemplo de relación <<extend>> en un sistema
de tienda electrónica en Internet

Ahora si vamos al caso de uso base «Compra artículo (UC-0100)» podríamos tener la funcionalidad de escoger el artículo a comprar y el de pagar con tarjeta de crédito, 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 artículo a comprar y el modo de pago: digamos tarjetas de crédito. Además el caso de uso captura también 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 idéntica a la encontrada en el caso del cliente final, optamos por reutilizar la especificación por vía de la relación de extensión.

Los criterios a aplicar para saber si la relación de extensión es aplicable son los siguientes:

1. Hay cuando menos un caso base y un caso extendido.
2. El caso base no se ve modificado por la existencia del caso extendido.
3. El caso base es un caso concreto atado a cuando menos un actor.
4. El caso extendido incorpora al caso base por completo.

La relación de extensión guarda relación con todos los restantes tipos de reutilización que están definidas para los casos de uso; en particular la relación es muy intima con la relación de inclusión <<include>> sin embargo la diferencia primordial entre <<extend>> e <<include>> es la modificación del caso base. Extensión no implica cambio, en tanto que la inclusión añade funcionalidad al caso base.

Otra relación, la herencia, es similar también a la extensión. 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 «artículo» en el caso base es ahora referido más detalladamente como «libro» o «juguete». La herencia de casos de uso reutiliza al caso base sí, pero nos permite alterar la semántica de los detalles; algo que la relación de extensión (ni la de inclusión) pueden hacer.

Por tanto concluyamos: la relación de extensión permite reutilizar una especificación pero sin modificar al caso base.

Ejemplo de caso de uso

Considerando lo vital que es la gestión de requisitos y lo populares y útiles que son los casos de uso, nunca esta de más intentar una explicación de la técnica. Así que supongamos a un sistema pequeño que nos sirva de ejemplo: el teléfono de un hogar promedio. En dicho sistema, es de interés realizar llamadas de voz, o en otras palabras, el sistema tiene entre sus objetivos el de permitir al usuario del mismo comunicarse remotamente por medio de conexiones de voz.

Primero hemos de identificar al actor. En este caso es claramente el operador o usuario del teléfono. Tendremos en cuenta siempre que cada actor admite solamente cierto tipo de comunicación, impone sus propios requisitos sobre el sistema y exige una funcionalidad bajo ciertas condiciones. Pero para facilitar las cosas podemos simplemente indicarlo; quizás incluso recurriendo a un formalismo gráfico tomado de UML.

Fig. 1 – Ejemplo sencillo de un Actor

Ahora podemos identificar cual es la actividad precisa que queremos expresar en nuestro modelo. Digamos que estamos hablando de las llamadas de voz. Así que decimos:

«El usuario del teléfono levanta el auricular y marca el número de destino. Al completar la secuencia de dígitos la conexión se realiza. Por medio de tonos particulares el sistema indica el estado de error y de progreso en la conexión».

El párrafo previo contiene la esencia de la situación de llamar por teléfono. A esta breve descripción le llamamos Caso de Uso por cuanto describe la interacción entre un actor -el usuario- y el sistema -el teléfono- indicando el requisito funcional que se exige al sistema.

Ahora bien, ciertamente es difícil referirse a este caso de uso diciendo cada vez el párrafo completo. Por esto le vamos a poner un nombre y un código de identificación. Digamos que le llamamos llamada de voz y que le colocamos el código CS-0100.

Además es claro que antes de hacer la llamada de voz es necesario que el teléfono este colgado así que podemos pensar en una precondición: el teléfono ha de estar colgado.

Armados con estos datos, podemos construir una tabla que resuma lo que tenemos en nuestro caso de uso:

Código: CS-0100.
Nombre: Llamada de voz.
Actores: Usuario.
Descripción: El usuario del teléfono levanta el auricular y marca el número de destino. Al completar la secuencia de dígitos la conexión se realiza. Por medio de tonos particulares el sistema indica el estado de error y de progreso en la conexión.
Precondición: El teléfono está colgado.
Postcondición: Ninguna.

Tabla 1 – Detalle de un sencillo Caso de Uso

Y aún más, podemos construir un atractivo diagrama con el fin de comunicar lo que hemos hecho con los clientes.

Fig. 2 – Sencillo ejemplo de un Modelo de Casos de Uso

Si bien en la representación gráfica no aparecen ni la precondición ni la descripción, si en cambio nos ha permitido indicar que el caso de uso (el ovalo) esta en el alcance del proyecto, al haberlo colocado dentro del rectángulo que define los límites del sistema. Por cierto, a dicho rectángulo lo llamamos sujeto en la especificación de UML.

Si en la revisión con los stakeholders identificamos que el caso de uso CS-0100 (el del ejemplo) merece ser detallado más cuidadosamente, entonces y solo entonces, podemos invertir algo de tiempo en la creación de los flujos de eventos. Observemos aquí, que la línea que une al actor con el caso de uso en el modelo gráfico quiere justamente hacer referencia al flujo de eventos.

Al flujo de eventos lo construimos como una tabla, indicando el número del paso el sujeto que realiza la acción y el paso de información que se hace. En aquellos pasos en que estemos hablando del sistema también vamos a indicar la operación o cálculo que este ha de efectuar con los datos. Por otra parte, el flujo de eventos lo vamos a iniciar, casi sin excepción, con el actor.

Flujo Principal:
Paso 1 – Usuario: Levanta el auricular.
Paso 2 – Sistema: Da el tono de marcado.
Paso 3 – Usuario: Indica el número de teléfono.
Paso 4 – Sistema: Realiza la conexión. Da tono de aviso en tanto se levanta el teléfono del lado contrario de la conexión. Permite la conversación al hacerse efectiva la conexión.
Paso 5 – Usuario: Conversa y al finalizar esta, tranca el teléfono.
Paso 6 – Sistema: Termina la conexión.

Tabla 2 – Flujo principal del Caso de Uso

Claro que no siempre las llamadas de voz se corresponden con este flujo de eventos. Sin embargo en un día feliz, cuando todo sale sin problemas, es de esta manera en que sucede. A lo que ocurre en todos los demás casos los vamos a tratar por medio de los flujos alternativos.

Los flujos alternativos pueden ser vistos como una forma de manejo de errores o bien, como un medio para especificar el comportamiento del sistema en caso de un error. Siendo así el caso, una forma de indicarlo es decir una aserción sobre un paso y la acción a tomar cuando esta se viola. Entre las posibles acciones podríamos tener: terminar el caso de uso, saltar a otro paso, presentar un reporte y continuar, etc.

Digamos entonces para efectos del ejemplo, que queremos especificar el comportamiento del sistema cuando el operador a indicado un número inexistente. El siguiente flujo alternativo trata esa situación:

Flujo alternativo: Número incorrecto
Paso 3 – El sistema: Presenta tono de error y el caso de uso termina.

Tabla 3 – Flujo alternativo del Caso de Uso

Aceptando que claramente es posible indicar tantos flujos alternativos como sean necesarios, además de especificar post condiciones y requisitos no-funcionales relacionados, tenemos entonces un caso de uso sencillo modelado quizás más completamente que lo que en realidad vale la pena. Pongamos todo junto:

Código: CS-0100.
Nombre: Llamada de voz.
Actores: Usuario.
Descripción: El usuario del teléfono levanta el auricular y marca el número de destino. Al completar la secuencia de dígitos la conexión se realiza. Por medio de tonos particulares el sistema indica el estado de error y de progreso en la conexión.
Precondición: El teléfono está colgado.
Postcondición: Ninguna.
Diagrama:

Flujo Principal:
Paso 1 – Usuario: Levanta el auricular.
Paso 2 – Sistema: Da el tono de marcado.
Paso 3 – Usuario: Indica el número de teléfono.
Paso 4 – Sistema: Realiza la conexión. Da tono de aviso en tanto se levanta el teléfono del lado contrario de la conexión. Permite la conversación al hacerse efectiva la conexión.
Paso 5 – Usuario: Conversa y al finalizar esta, tranca el teléfono.
Paso 6 – Sistema: Termina la conexión.

Flujo alternativo: Número incorrecto
Paso 3 – El sistema: Presenta tono de error y el caso de uso termina.

Tabla 4 – Caso de Uso completo

Un modelo de casos de uso es entonces una especificación de funcionalidad desde el punto de vista de la interacción del sistema con sus actores, apoyada en la representación gráfica para facilidad de comunicación pero constituida principalmente por texto.

De momento es todo. Mucho más se puede decir sobre los casos de uso: características avanzadas como la relación de extensión y la relación de inclusión; pero en casi todos los casos priva que mientras más sencillo mantengamos la especificación mejor, lo sencillo se entiende más, y la especificación de requisitos ha de entenderse bien. Que tan sofisticado lo hagamos no es ni de lejos, tan importante como la claridad.

Modelado de Casos de Uso

La idea de especificar los requisitos de un sistema es simple: indicar lo que el sistema debe hacer. Sin embargo, dado que los sistemas modernos son altamente interactivos; tanto por su relación con múltiples operadores como por su integración con otros sistemas – los llamados actores; hoy por hoy es necesario dar un giro en esa ideal inicial. Hoy es necesario especificar lo que el sistema hace para cada actor.

La organización de un cuerpo de requisitos modernos es pues, una presentación de las responsabilidades del sistema desde el punto de vista de cada uno de los actores que requieren los servicios del sistema. A esta forma de documentar los requisitos le llamamos Caso de Uso.

En su forma más simple, un caso de uso es un párrafo de texto que describe un escenario de interacción entre el actor -o actores- y el sistema. Dicho párrafo contiene la especificación de la funcionalidad requerida y puede ser considerada la unidad fundamental de un modelo de requisitos.

En adición a esta descripción de la interacción, es usual encontrar detalles adicionales. La principal de estas adiciones es el llamado flujo de eventos, que pone en limpio la interacción entre el actor y el sistema por medio de su presentación en pasos, indicando tanto la información que viaja de un lado al otro, y el cálculo o proceso que se requiere que el sistema realice con la información.

Usual también, es encontrar las desviaciones al flujo de eventos típico presentadas como flujos alternativos. Manejando de esta forma las condiciones de error que se requieren sean cubiertas por el sistema.

Sin embargo, con mucho la más popular de las extensiones o adiciones que se hacen a los casos de uso es la de presentarlos en forma gráfica con ayuda del lenguaje de modelado UML. Sin embargo, es importante dejar en claro que la representación gráfica no es donde el requisito es capturado. Este papel es cubierto por las descripciones textuales del escenario y en gran parte también, por los flujos de eventos principales y alternativos.

Un ejemplo rápido de diagrama de caso de uso, quizás parte de un modelo mucho más grande y complejo es el siguiente:

Fig. 1 – Ejemplo de diagrama de casos de uso

Un ejemplo más completo de caso de uso puede ser encontrado en este blog, en la entrada Ejemplo de Caso de Uso.

Finalmente comento que la técnica de los Casos de Uso fue introducida por primera vez por Ivar Jacobson a principios de los años noventa. La técnica fue presentada en un contexto en el que la orientación a objetos era popular; por lo que hoy en día se consideran comúnmente a los casos de uso como integrantes del análisis y diseño orientado a objetos. Sin embargo los casos de uso no tienen nada de específicamente orientado a objeto, ya que su objetivo es la documentar requisitos de sistemas interactivos y estos por razones obvias no tienen porqué ser objetos. Así que ya sea que se desarrolle un sistema orientado a objeto o no, los casos de uso son apropiados para capturar los requisitos del sistema; siempre y cuando, digo de nuevo, el sistema sea fuertemente interactivo.