Comparativa Caso de Uso vs.Objetivo de Usuario

El ejemplo consiste en especificar la funcionalidad “Dispensar Bebida” de una aplicación interactiva en la que una máquina dispensadora de bebidas permite a un usuario comprar la bebida deseada.

Caso de Uso Concreto

Los casos de uso fueron introducidos por Ivar Jacobson en 1986 como una manera simple y útil de describir los requisitos funcionales (Jacobson, 1992).

Los casos de uso son descripciones exhaustivas de los requisitos funcionales del sistema, en forma transaccional y plasmadas en acciones de usuario de bajo nivel en conjunción con las reacciones del Sistema, y que habitualmente se representan de forma textual. En un caso de uso puede haber varios tipos de actores. Un actor es una entidad con comportamiento: una persona identificada por un rol (por ejemplo un cliente), un sistema informatizado (por ejemplo el sistema de contabilidad de una empresa) o una organización o entidad (por ejemplo un cajero).

En el caso de uso “Dispensar Bebida” (Tabla 3.1) se definen las acciones del Usuario y del Sistema (la máquina dispensadora) que producen el efecto deseado “El Sistema dispensa la bebida…” , y además se incluyen separadamente las acciones que producen los cursos alternativos. Se mencionan los elementos necesarios que participan en el caso de uso, tanto del dispositivo (“ranura”, “teclado”, etc) como de la interfaz concreta (“menú”, “selecciona”, etc). Las acciones del Sistema son acciones internas de la lógica de negocio (“verifica”, “detecta”, etc) y acciones externas (“solicita cantidad”, “devuelve la tarjeta”, etc).

Tabla 3.1 Caso de uso “Dispensar Bebida“

Acciones del Usuario Reacciones del Sistema

1. El Cliente inserta la tarjeta de crédito en la ranura

2. El Sistema solicita el PIN

3. El Cliente teclea 4 dígitos usando el teclado

4. El Sistema verifica la identidad del usuario

5. El Sistema solicita la selección del producto de un menú de opciones

6. El Cliente selecciona el producto 7. El Sistema solicita cantidad utilizando un menú

8. El cliente selecciona la cantidad 9. El Sistema verifica disponibilidad producto

10. El Sistema verifica saldo

11. El Sistema devuelve la tarjeta a través de la ranura. 12. El Sistema dispensa la bebida por la zona de dispensa de productos.

CURSOS ALTERNATIVOS:

4.1. El Sistema detecta PIN erróneo. Paso 2

9.1. El Sistema verifica que no hay cantidad suficiente. 9.1.1. Opción 1: Repetir selección. Paso 5. 9.1.2. Opción 2: Cancelar. Fin.

10.1. El Sistema verifica que no hay saldo suficiente. 10.1.1. Cancelar. Fin.

Caso de Uso Esencial

Los casos de uso esenciales forman parte del Diseño Centrado en el Uso (Constantine and Lockwood, 1999). Son narraciones estructuradas, expresadas en el lenguaje del dominio de la aplicación y de los usuarios, que describen una tarea de forma simplificada, generalizada, abstracta, libre de tecnología e independiente de la implementación, definida desde el punto de vista del usuario, dentro de un rol o roles en su relación con el Sistema, y que recoge el propósito de la interacción (Constantine, 1995). Un caso de uso esencial, a diferencia de los casos de uso concretos, no contiene suposiciones sobre el tipo de interfaz ni la tecnología que se usará. Se centra en lo que un usuario quiere hacer y en las responsabilidades del Sistema,

acciones del Usuario y del Sistema (máquina dispensadora) se abstraen de la tecnología (tarjeta, ranura, etc) y de la interfaz concreta (menú, selección, etc).

Tabla 3.2 Caso de uso esencial “Dispensar Bebida”

Acciones del Usuario Reacciones del Sistema

1. El Cliente se identifica 2. El Sistema valida la identidad del usuario

3. El Sistema solicita indicación de producto

4. El Cliente indica el producto 5. El Sistema valida producto

6. El Cliente indica la cantidad 7. El Sistema valida cantidad

8. El Sistema solicita Pago

9. El Cliente efectúa Pago 10. El Sistema valida Pago

11. El Sistema valida disponibilidad

12. El Sistema dispensa bebidas

CURSOS ALTERNATIVOS: 2.1. El Sistema deniega el paso. Paso 1.

5.1. El Sistema verifica que el nombre o código de producto no es correcto 5.1.1. Paso 4.

7.1. El Sistema verifica que la cantidad no es una cifra correcta. 7.1.1 Paso 6.

10.1. El Sistema verifica que el Pago es incorrecto 10.1.1. Opción 1: Paso 9

10.1.2. Opción 2: Cancelar. Fin. 11.1. El Sistema verifica que no hay producto.

11.1.1. Opción 1: Paso 3. 11.1.2. Opción 2: Cancelar. Fin.

Objetivo de Usuario

En un Objetivo de Usuario el foco de la especificación es el usuario final, y a él va dirigida la interacción. Los actores son siempre dos: el usuario y el Sistema como identidad abstracta que agrupa el comportamiento de la aplicación en la IU. Una vez detectado un UO, el primer paso en la vida de un UO es su formalización. Por ejemplo:

UO5-Dispensar bebida: El usuario quiere obtener una bebida en una máquina dispensadora de bebidas.

La especificación del UO (Tabla 3.3) describe únicamente las acciones del Usuario y del Sistema a nivel externo (comunicación directa Usuario-Sistema); esto es, describe los efectos de esas acciones en la interfaz de usuario: “El Cliente se identifica”, “El Sistema responde”, “El Sistema solicita”…

Tabla 3.3 Especificación de UO5 - Dispensar Bebida

Acciones del Usuario Reacciones del Sistema

1. (Nueva ventana) El Cliente se identifica

2.a. El Sistema responde: “Identidad del usuario correcta”. Paso 3.

2.b. El Sistema responde “Identidad Incorrecta”. Paso 1.

3. (Nueva ventana)El Sistema solicita indicación de producto.

4. El Cliente indica el producto 5a. El Sistema responde: “Nombre de producto Correcto” . Paso 6.

5b. El Sistema responde: “Nombre de producto Incorrecto” . Paso 4.

6. El Sistema solicita indicación de Cantidad

7. El cliente indica la cantidad 8a. El Sistema responde: “Cantidad correcta y disponible”. Paso 9.

8.b. El Sistema responde: “Cantidad no correcta”. Paso 7.

8c. El Sistema responde:“Cantidad no disponible”. Paso 4.

9. (Nueva ventana)El Sistema indica total a pagar y solicita Pago

10. El cliente efectúa Pago 11a. El Sistema responde “Pago correcto” y dispensa bebida. Fin.

11b. El Sistema responde “Pago insuficiente”. Paso 10.

11c. El Sistema responde: “No se dispone de cambios”. Devuelve Pago y Fin.

Por otra parte, al igual que los casos de uso esenciales, la especificación inicial de los UOs se abstraen de la tecnología y de la interfaz concreta (menús, colores, tipos de botones, etc). Sin embargo incluyen algunos elementos mínimos para la presentación en la interfaz de las

acciones (en el ejemplo “nueva ventana”) que son necesarios para generar prototipos de bajo nivel que van a permitir evaluar mejor estas especificaciones con los usuarios.

Además, quedan integradas en la propia especificación las acciones alternativas del Sistema (2a-2b, por ejemplo) y las desviaciones (“Paso 3”, por ejemplo), que representan la semántica de la aplicación (requisitos funcionales) a tener en cuenta posteriormente en la implementación.

Discusión sobre Especificaciones de UOs, Casos de Uso, Casos de Uso

Esenciales y otros

En las tres formas expuestas: Casos de Uso, Casos de Uso Esenciales y Objetivos de Usuario, se observan diferencias en la descripción de las acciones del usuario y del sistema. Así, Larry Constantine y Lucy Lockwood observan excesos en los casos de uso concretos, en cuanto a las descripciones precisas sobre la forma en que se construirá la interfaz de usuario. Esta precisión obliga a tomar decisiones de diseño tempranas, e incluir estas decisiones en las especificaciones dificulta su modificación más tarde (Constantine, 1995). Alistair Cockburn razona que desde el punto de vista metodológico o de proceso, el diseño de la IU es posterior a la especificación concreta de la funcionalidad: “The design of the UI is likely to change too often for such writings to be used as contractual requirements and as system requirements” (Cockburn, A, 1997). Normalmente, un equipo de diseñadores lee la especificación y ofrece diferentes maneras de recoger y presentar la información. Por esta razón, otros autores prefieren trabajar a nivel de interacción semántica, describiendo sólo la información que interactúa, sin describir la secuencia o la naturaleza de la interacción (sin describir el diálogo preciso). Esta es la idea de Larry Constantine con sus “Essential Use Cases”.

En cualquiera de los dos casos de uso, concretos y esenciales, el foco de la especificación está más en las acciones que debe realizar el Sistema que en la comunicación que debe tener con el Usuario, derive ésta o no de sus acciones internas. La especificación de los Objetivos de Usuario, sin embargo, permite centrar la atención en los aspectos de la interacción Usuario-Sistema a un nivel de usuario, de tal modo que la evaluación y verificación de dicha especificación muestre a los usuarios únicamente el comportamiento futuro de la aplicación en la interfaz. Los aspectos internos del comportamiento del Sistema no se especifican a este

nivel ya que no son relevantes para el usuario y dificultan su evaluación. Por ello, los Objetivos de Usuario que propone InterMod ayudan a organizar un proyecto definiendo las necesidades funcionales y restricciones debidas al Usuario y/o al Sistema, y además llevan implícitos los requisitos de usabilidad por su recogida y evaluación.

Existen también diferencias entre los UOs y los Goals, empleados en varios trabajos sobre análisis de requisitos. (Anton, 1996) (van Lamsweerde, 2004) Tanto los UOs como los Goals comparten algunas características comunes: pueden referirse a propiedades funcionales o no funcionales y permanecen activos durante toda la vida del proyecto como guía del mismo. Sin embargo, sus diferencias son notables en cuanto a su orientación y evolución en el desarrollo.

Los Goals son mecanismos lógicos que sirven para identificar y justificar los requisitos de software. El análisis necesario para identificar los Goals, implica la exploración de documentación seguida de un proceso de organización y clasificación. El análisis de captación de UOs, sin embargo, parte de los deseos directos de usuarios finales, y son evaluados con ellos de forma temprana para su mejor adquisición. Esto es, en palabras de Antón, “Goals are high level objectives of the business, organization or system” (Anton, 1996), y, de forma similar, para Lamsweerde “A goal is an objective the system under consideration should achieve” (van Lamsweerde, 2001); mientras que los UOs son objetivos abocados a cumplir deseos directos del usuario final.

Los UOs se formalizan mediante la descripción del comportamiento de los usuarios (acciones para completar) y los comportamientos del Sistema (reacción de la aplicación), en relación a la interfaz. Estas descripciones incluyen sólo una parte de los requisitos funcionales, ya que sólo se indican las reacciones del sistema en la interfaz. Es decir, no incluyen las reacciones de control de la aplicación, como "comprobar la compra" o "guardar la línea de pedido". Los UOs son útiles para organizar la interfaz y también para ayudar a descubrir y formalizar los casos de uso en etapas posteriores.

En cuanto a la evolución de los Goals, ésta se refiere a la forma en que éstos cambian desde el momento en que son identificados hasta el momento en que son operativos en la especificación del sistema. Esto encaja dentro de una perspectiva up-front en la que se contemplan todos los requisitos desde un principio. Desde la perspectiva ágil que comparte

InterMod, los requisitos, incluso después de su implementación y validación, pueden ser revisados y actualizados.