Investigación‎ > ‎

Estructuración y Especificación de Casos de Uso

Introducción

Los CU forman parte de las especificaciones de UML 2.0, así como de metodologías de desarrollo, los mismos son empleados para la especificación de requerimientos funcionales.

El propósito es esta página es presentar una guía para la construcción de Casos de Uso (CU o UC), ello implica los pasos para la construcción del diagrama, la especificación de los CU y la forma en como deben estructurarse para aprovechar las bondades de reutilización, modularización y herencia entre CU.

Este documento está dirigido a los analistas de requerimientos y los revisores internos de los documentos relacionados con los CU con el objeto de establecer los criterios que permitan evaluar si los CU han sido escritos de forma útil, comprensible, portable, completa y sin ambigüedades.

Cada analista de requerimientos debe conocer profundamente el significado de escribir CU y el empleo que a éstos se les dará. Los casos de uso son una manera de capturar requerimientos, para ser expresados a los equipos de análisis, quienes encontrarán en estos su principal fuente para identificar objetos y clases.

Pueden definirse varios estilos de CU dependiendo de las características del sistema a ser descrito, en este documento se encontrarán igualmente las pautas para cada uno de los estilos autorizados por la Organización, así como los criterios que permiten identificar cuándo cada criterio debe ser utilizado y por qué.

El documento es producido como una recopilación de buenas prácticas y conceptos de varias fuentes de literatura, libros, cursos de requerimientos, presentaciones sobre requerimientos de IBM Rational, entre otros. El documento representa un esfuerzo para realizar, de manera consistente casos de uso, manteniendo el espíritu de lo que es un caso de uso y no una especificación tradicional o un algoritmo.

Otros documentos relacionados con esta guía son la “Guía para la clasificación y trazabilidad de los requerimientos”, “Guía para el análisis de CU”, “Checklist de validación de CU” y “Pautas para la construcción del glosario”.

¿Cuando utilizar los Casos de Uso?

Los casos de uso son un tipo de requerimientos utilizados para especificar funcionalidad, especialmente en sistemas con un alto grado de interacción hombre/máquina (y pueden ser utilizados hasta en sistemas de batch). En esencia los casos de uso describen los intercambios entre el sistema que se está describiendo y las personas o sistemas externos que interactúan con el primero, por lo tanto son muy útiles para describir funcionalidades a varios tipos de usuarios y con muchas interfaces.

¿Para qué sirven los Casos de Uso?

Los casos de uso son útiles para capturar requerimientos, ayudar a definir la arquitectura, establecer las pautas para el diseño y las pruebas funcionales. Los CU son una guía de los elementos que serán incluidos en los documentos de usuarios para las aplicaciones, así como la forma en como éstos deben ser empleados. Los CU también establecen las bases para los protocolos de comunicación entre aplicaciones y el diseño de las interfaces gráficas, entre otros.

La validez de los casos de uso viene dada cuando los usuarios e involucrados del sistema aceptan el funcionamiento propuesto en los CU, siempre que la redacción de los mismo sea buena, no dejando cabida a ambigüedades.

Entonces los casos de uso deben ser útiles y ofrecer valor tanto al equipo de usuarios e involucrados como a los desarrolladores del proyecto.

¿Qué es un Modelo de CU y que son los CU?  

Los casos de uso describen secuencias de acciones que realiza un sistema y que lleva a un resultado de valor a un actor específico.

Un modelo de CU está compuesto por dos partes, un diagrama (gráfico) y una parte textual. El diagrama muestra las relaciones entre actores y casos de uso, así como las relaciones entre los CU y entre actores – en caso que existan –. La parte textual muestra la descripción escrita en lenguaje natural que narra los pasos y demás características del caso de uso.

¿Qué son los actores y cómo identificarlos?

Actor es algo o alguien fuera del Sistema que interactúa con el Sistema.

Un actor especifica un rol que alguna entidad externa adopta cuando interactúa con el sistema directamente. Puede representar un rol de usuario o un rol jugado por otro sistema o hardware que toca la frontera del sistema. [NEUSTADT]

La siguiente es la lista de preguntas que permiten identificar a los actores que interactuarán con el Sistema:

  • ¿Quién o qué utiliza el Sistema?
  • ¿Qué roles toman en la interacción?
  • ¿Quién toma información del Sistema?
  • ¿Quién provee información al Sistema?
  • ¿En qué parte de la compañía es utilizado el Sistema?
  • ¿Quién instala, soporta y mantiene el Sistema?
  • ¿Quién inicia y termina la ejecución del sistema?
  • ¿Qué otros sistemas utilizan el Sistema?
  • ¿Ocurre algo en algún momento específico?

La siguiente es la tabla que describe a los actores del sistema. El código del actor reseñado como ACT.# se refiere al prefijo ACT. seguido por el número de actor asignado. La descripción se refiere a una breve reseña del rol del actor para el sistema y las fuentes son los involucrados del negocio que ayudaron a definir y describir al actor.

Actor ACT.# Nombre del Actor 
Descripción <descripción del actor>
Responabilidades
  • <Responsabilidad 1>
  • <Responsabilidad 2>
Fuentes <Stakeholders que identificaron y contribuyeron a definir al actor>

¿Cómo se hace el Diagrama de CU? 

El diagrama de CU ofrece la visión global que cuenta lo que hay afuera del sistema y lo que hay adentro del sistema. Esto es, especifica las fronteras del sistema.

El aspecto de diagramas de casos de uso para sistemas batch varía con respecto a los empleados para interfaces con usuarios.

El diagrama de CU no debe reflejar ni el flujo de control ni el flujo de datos, sino de asociaciones que son canales de comunicación.

Los casos de uso reflejan las relaciones entre los actores y los casos de uso.

Tampoco se trata de diseño.

Cuando la comunicación es iniciada por el actor, la relación de comunicación contiene una flecha hacia el lado del CU. Si no la contiene entonces el CU es quien solicita al actor de la interacción. Que un sistema invoque a un actor para alguna función solo ocurre con el caso de actores no humanos (otros sistemas), y nunca ocurre que el CU por sí solo invoca al actor, siempre tiene que haber un actor que solicite su activación, considere que si esto no ocurre, probablemente lo que Ud. esté tratando de modelar no sea un CU. Arlow y Neustadt sugieren la incorporación de un actor llamado tiempo para cuando un CU es disparado no por la interacción directa de un actor sino cada cierto período de tiempo, ejemplo, «CU.1 Recolectar información de campo»: Breve descripción «Cada 5 minutos el sistema dispara automáticamente este CU que se comunica con los dispositivos de campo para solicitar información».

¿Qué son Casos de Uso y cómo identificarlos?

Los Casos de Uso representan lo que un actor desea que haga el Sistema. Los casos de uso definen una secuencia de acciones ejecutadas por un sistema que producen un resultado observable de valor para un actor.

En el libro “The UML Reference Manual” de RUMBAUGH se definen los casos de uso como: la especificación de secuencia de acciones, incluyendo variaciones a la secuencia y secuencia de los errores, que un sistema, subsistema o clase realizan con la interacción de actores externos.

Los casos de uso son siempre iniciados por un actor y son escritos desde el punto de vista del actor.

La siguiente es la lista de preguntas que permiten identificar los casos de uso dentro de las fronteras de un sistema:

  • ¿Qué funciones del sistema son requeridas por un actor específico?
  • ¿El sistema guarda o recupera información? Si es así ¿Qué actores disparan esta acción?
  • ¿Qué ocurre cuando el sistema cambia de estado? ¿Algún actor es notificado?
  • ¿Algún evento externo afecta al sistema? ¿Qué notifica el sistema respecto de estos eventos?
  • ¿El sistema interactúa con algún sistema externo?
  • ¿El sistema genera algún reporte?

¿Como especificar Casos de Uso?

La especificación de los casos de uso se refiere a la descripción de cada una de las partes definidas para lograr su descripción completa. En la organización, la especificación de los Casos de Uso se hará bajo el formato presentado a continuación. El siguiente cuadro muestra las partes y las indicaciones básicas para iniciar su redacción. En las siguientes secciones del documento se presentan las recomendaciones que hacen que la redacción de CU sea más fácil, sencilla de leer y escribir.

Caso de Uso CU.1 XX
Fuentes <Stakeholders que proporcionaron información de esta funcionalidad>
Actor Act.# <nombre de los actores> [(<Pseudónimos>)] [ – secundario]
Descripción <Descripción del caso de uso>
Flujo básico 1. Titulo del paso
Descripción del paso.
2. Titulo del paso
Descripción del paso.
Flujos alternos 1. Titulo del FA
Descripción del FA
2. Titulo del FA
Descripción del FA.
Pre-condiciones 1. Titulo del Precondición
Descripción del PRC
Post-condiciones 1. Titulo del Poscondiciones
Descripción de la PTC
Requerimientos trazados 1. Titulo del requerimiento
Descripción del requerimiento o porqué se enlaza a el desde este caso de uso
Puntos de inclusión 1. Título del punto de inclusión
Descripción del punto de inclusión
Puntos de extensión 1. Título del punto de extensión
Descripción del punto de extensión
Notas 1. Titulo de la Nota
Descripción de la nota

Caso de Uso

El nombre del CU debe comenzar por un verbo y ser lo más corto posible, pero que a su vez, describa lo que el CU hace. El nombre del CU debe indicar el valor u objeto que genera para el actor. El nombre del CU comienza por su identificación CU.# donde # es el número asignado a este CU.

Fuentes

Son las personas que conocen del negocio, y las que proporcionan información para la descripción de la funcionalidad.

Actores

Los actores que interactúan directamente con el sistema, tanto los primarios quienes inician el CU, como los secundarios que interactúan con el sistema luego que este ha iniciado. Cuando se nombran los actores en la sección de actores del CU se coloca el código asignado en la sección de actores ejemplo Act.1. En caso de haber actores segundarios, el CU debe indicar cuales son secundarios, el resto se asumen primarios, de lo contrario se asume que todos son primarios. Los actores secundarios se les coloca luego del pseudónimo un guión y la palabra «secundario» en letra itálica.

El nombre del actor puede contener al lado una lista de pseudónimos, estos son utilizados en el CU para describir su funcionamiento con el empleo del pseudónimo en vez del nombre del actor (o rol) que puede ser muy largo. El pseudónimo también puede ser empleado en forma de lista de actores, si un pseudónimo está indicado en varios actores, entonces la referencia al pseudónimo en el detalle del CU hará indistinta la sustitución por cualquiera de los actores.

Descripción

Es un párrafo que resume el objetivo del caso de uso. Sin dar detalles del cómo, la descripción del caso de uso resume todo lo que el caso de uso hace, que es el valor que da al actor (o actores) primario, así como la necesidad de la existencia de actores secundarios, para los casos que aplique.

Ejemplo. “El caso de uso permite al Administrador crear, modificar y borrar usuarios en el sistema” ó “El caso de uso permite al Cliente obtener la información sobre su estado de cuenta del Sistema de Manejo de Clientes”.

Flujo básico

El flujo básico (FB) describe los pasos que se sucederían en el escenario del “mundo perfecto” o del “día feliz”. El flujo básico es un camino simple, sin ramificaciones y en él suelen hacerse una serie de asunciones, las alternativas a estos presuntos son los flujos alternos.

Cada paso del flujo básico contiene 1) un número de paso o flujo, 2) titulo del paso, y 3) la descripción del paso. La numeración del paso es un consecutivo que inicia con el número 1 en el primer paso. El título del paso representa un resumen de lo que el paso realiza, suele ser una oración que inicia con un verbo en estado activo Ej. “crear usuario”, “buscar datos de clientes mayores”. La descripción del paso contiene el detalle de lo que se espera que ocurra en el paso. Dependiendo de la complejidad del sistema o los datos manejados, los pasos pueden tener varios intercambios, ejemplo:

3.        Crear código de movimiento manual

El sistema solicita al Administrador de Tablas de O/S el valor del código de movimiento y una descripción asociada a ese código. El Administrador de Tablas de O/S indica al sistema los valores para estos campos y le indica al sistema guardar la información. El caso de uso termina.

Tabla 1. Listado del último paso de un CU

Es obligatorio que cada paso contenga el número del paso y su título, la descripción puede ser opcional en casos de uso cuyos pasos se limitan a la oración del título.

Los pasos de los flujos básicos no contienen, nunca, referencias a los flujos alternos ni a flujos básicos.

La descripción del primer paso del FB indica que actor comienza el flujo y cuál es el disparador del mismo, ejemplo “El caso de uso inicia cuando el Administrador de Tablas de O/S indica al sistema la opción de visualizar órdenes de servicio.”. El último paso del flujo básico cierra indicando que el caso de uso termina, o finaliza, ejemplo ver Tabla 1.

Flujos alternos

Los flujos alternos (FA) se definen como flujos independientes, no como subflujos, permitiendo hacer que un flujo alterno aplique de manera global a todo el CU, o a varios flujos básicos u alternativos. Mantener los FA de forma plana facilita su lectura, su escritura y su comprensión. El formato utilizado emplea una sección separada para los flujos alternos. Los flujos alternos pueden hacer referencia a flujos básicos u otros flujos alternos. Todos los FA deben indicar (en este orden):

·        ¿Dónde comienzan? Desde donde parte este FA, puede ser un FB o un FA.

·        ¿Qué los dispara? Que hace que este FA inicie

·        ¿Qué sucede? Lo que pasa cuando el FA es invocado, análogo al FB.

·        ¿A dónde regresa? Una vez que termina de ejecutarse el flujo alterno, ¿A dónde regresa la ejecución del caso de uso?

El siguiente es un ejemplo de un FA.

1.    Excepción: No se encontraron O/S para el criterio aplicado

En el paso 2 del flujo básico el resultado de la búsqueda no arroja ningún resultado. El sistema muestra al Usuario un mensaje alertando sobre tal situación. El usuario acepta el mensaje. El caso de uso retorna al paso 1 del flujo básico con los valores anteriormente empleados para la búsqueda.

2.    Mostrar la lista de mensajes asociados a una O/S

En el paso 2 o el paso 3 del flujo básico el Usuario selecciona ver la lista de mensajes asociados. El sistema muestra una tabla con todos los mensajes contenidos por la O/S. El caso de uso retorna al paso en que fue llamado.

Tabla 2. Listado del último paso de un CU

Al igual que los FB, los FA cuentan con un número de flujo, un título y una descripción. El número de flujo es un secuencial que se inicia en 1 con el primer FA del CU. El título describe la acción que realiza FA y se escribe con las mismas normas que en los FB, sin embargo, los FA que indican excepciones se presentan de forma diferente, se indica que son excepciones y el comportamiento que es erróneo, no se escriben comenzando con verbo en forma activa. La descripción debe contener la respuesta a las cuatro preguntas presentadas en el mismo orden en que se encuentran listadas.

Pre-condiciones

Las precondiciones son elementos opcionales de los CU. Cada precondición listada tiene: 1) número, 2) título 3) descripción (opcional). El número es un consecutivo. El titulo debe resumir muy brevemente la condición. La descripción puede dar detalles de cómo la condición es evaluada, o el rango de valores que pueden ser aceptados para la condición.

Bittner y Spence hacen énfasis en que las precondiciones no son eventos que disparan o activan el CU en el sistema. Sin embargo son declaraciones en las cuales el caso de uso puede comenzar. Las precondiciones son necesariamente ciertas para que el CU pueda comenzar, pero no suficientes. El CU sólo puede ser comenzado por el actor cuando las precondiciones son ciertas.

Las precondiciones no son evaluadas en los FB ni los FA pues se asumen como ciertas. Si las precondiciones aplican para todos los CU del sistema entonces es un requerimiento y no debe indicarse.

Para hallar precondiciones formúlese las siguientes preguntas:

·        ¿En qué estado debe encontrarse el sistema para que el CU se pueda disparar?

·        ¿Qué elementos deben estar presentes para que el CU pueda iniciar?

·        ¿Cuáles son los supuestos asumidos?

·        ¿Qué restricciones aplican al empleo del CU por los actores?

Note que las precondiciones son opcionales de no existir no agregue precondiciones que no aporten a la explicación del CU. Evite precondiciones como «El usuario debe estar vivo» o «La maquina debe estar encendida y el sistema debe estar activado y funcionando», pues no agregan valor al diseño y son obvias.

Post-condiciones

Las postcondiciones son elementos opcionales de los CU. Los elementos y patrones para describir postcondiciones son iguales a los de las precondiciones.

Bittner y Spence explican que las postcondiciones deben ser ciertas cuando el CU termina, sin importar el curso de eventos que se sucedieron. Si algo puede fallar Ud. debe cubrirlo en las postcondiciones para describir el estado en el que el sistema se encontrará cuando el CU se completa.

Las postcondiciones son importantes puesto que dan las luces sobre las condiciones que garantizan que siempre que termine el CU el sistema queda en un estado válido y los datos inherentes (en caso de existir) se encuentran consistentes. Las postcondiciones son igualmente útiles para verificar que las pruebas que se realicen sobre este CU aseguren que estas condiciones se darán al salir, sea cual fuere el curso de acciones tomadas.

Para hallar postcondiciones formúlese las siguientes preguntas:

·        ¿En qué estado debe quedar el sistema luego que termina el CU?

·        ¿Qué debe garantizarse cuando termine para que el sistema no quede inconsistente o no utilizable?

·        ¿Cuáles son las únicas condiciones válidas en las que puede acabar una ejecución del CU?

Armour y Miller aclaran que tanto las precondiciones como postcondiciones se refieren a estados del sistema, no del ambiente fuera del mismo, ello debido a que las condiciones del ambiente no se modelan dentro del sistema.

Requerimientos trazados

Los requerimientos son formas de enlazar los CU o especificaciones funcionales con el resto de las especificaciones no funcionales. Estas especificaciones o requerimientos deben encontrarse en el repositorio de requerimientos con la información completa de los atributos definidos. Aunque la trazabilidad con los requerimientos especiales se da por demostrada en el mapa de trazabilidad de los requerimientos, el tenerlos presentes en el CU hace más fácil su lectura para el diseñador e constructor.

Para los requerimientos se debe especificar el número, el título y la descripción del requerimiento (opcional). El título puede contener el código del requerimiento y el título del mismo según la definición que se establezca para las especificaciones no funcionales del sistema. La descripción puede omitirse puesto que se asume que la misma se encuentra en el repositorio de requerimientos, sin embargo se pueden dar indicaciones adicionales de cómo el CU debe cumplir con este requerimiento.

Puntos de inclusión y extensión

Los puntos de inclusión son los enlaces para incluir un funcionamiento específico del CU que es empleado por más de un CU.

Los puntos de extensión son los enlaces que permiten extender la funcionalidad de un CU en un punto específico de flujo básico.

Para determinar cuando colocar y qué colocar en un punto de inclusión o un punto de extensión ver la sección de «¿Cómo estructurar Casos de Uso?».

Notas

Las notas son elementos opcionales muy importantes de los CU pues reflejan el análisis y la comprensión del funcionamiento del sistema, más allá de la descripción de las interacciones entre los usuarios. Las notas en los CU se utilizan para plasmar explicaciones, detalles sobre la información, formatos de archivos que ya se encontraban establecidos y otros acuerdos con los que la aplicación debe cumplir. Es importante que todas las notas se encuentren referenciadas con algún elemento del Caso de Uso, ejemplo la descripción, el FB, el FA, las referencias justifican la existencia de la nota.

Las notas son características muy importantes de los CU puesto que permiten capturar conocimientos propios del sistema que no se está describiendo, que son útiles a la hora de hacer el diseño y la implementación, sin embargo, no representan una funcionalidad propia del CU que se está especificando.

Recuerde que en su rol de analista de requerimientos, su misión es plasmar la mayor cantidad posible de detalle posible, ello debido a que es Ud. quién se encuentra más cercano a los funcionales que puedan estar revelando la información.

Consideraciones a la hora de escribir un Caso de Uso

La siguiente es una serie de consideraciones que deben ser tomadas a la hora de escribir o especificar casos de uso.

Empleo del SI Condicional

Referido en inglés como “using if-statement”. Ni los flujos básicos ni los alternos deben contener SI condicionales, en esencia, los casos de uso no son algoritmos, sino que describen la interacción entre los actores y el sistema. Para hacerlos no ambiguos, los casos de uso asumen un camino ideal y el resto son caminos alternativos.

INCORRECTO

1.        Modificar el horario

Si el usuario ya tenía un horario en su cuenta entonces proceder a mostrar el detalle del horario. Si no, mostrar un mensaje que indica que el usuario no tiene horario asignado.

CORRECTO

2.        Modificar el horario

El sistema muestra el detalle del horario.

NOTA: El sino representa un flujo alterno

Tabla 3. Empleo del si condicional

Opciones de los actores

Referido en inglés como “actor choices” o “avoid CRUD use cases”. Tanto en flujos básicos, principalmente, como en flujos alternos, un paso puede contener varias alternativas. El paso debe presentar al lector todas las alternativas posibles para el actor y tomar una de ellas, la que corresponde al día feliz. El resto de las opciones corresponderán a flujos alternos del caso de uso. El listado de las opciones debe ser completo, no debe utilizarse el etc. pues es un indicio de elementos que no han sido especificados y dejarán al diseñador la opción para que los sustituya por cualquier cosa. El siguiente ejemplo muestra el uso de opciones de los actores.

3.        Crear código de movimiento manual

El sistema permite al Administrador de Tablas de O/S crear, modificar o borrar códigos de movimiento manual. El Administrador de Tablas de O/S indica al sistema crear código de movimiento manual. El sistema solicita al Administrador de Tablas de O/S la información de código descripción del código. El Administrador de Tablas de O/S suministra los valores para estos campos y le indica al sistema guardar la información. El caso de uso termina.

Tabla 4. Opciones de los actores

Mostrando iteraciones

Las iteraciones son descritas en el caso de uso de manera plana, no se debe escribir en forma de algoritmo con pasos, sino de forma descriptiva. El siguiente es un ejemplo del uso de iteraciones.

1.      Seleccionar O/S

El sistema muestra la lista de las órdenes de servicio que aplican según los criterios de búsqueda seleccionados por el Usuario. Para cada elemento de la lista el sistema muestra el Código de movimiento, el estatus de la Orden, la fecha de la orden, el tipo de error, el número de la orden de servicio, la interfaz que originó la O/S, si la orden ha sido marcada para ser archivada, un indicador que especifica si la O/S tiene Formato 2000 asociado y un indicador que especifica si la O/S tiene mensajes asociados. El Usuario puede visualizar el F2K asociado a la O/S (en caso de contenerlo) o la lista de mensajes asociados (en caso de contenerlos). El Usuario selecciona visualizar el F2K asociado.

Tabla 5. Uso de iteraciones

Secuencias de eventos y eventos opcionales

A la hora de especificar secuencias de eventos, debe considerarse que no se indiquen secuencias que no son requeridas. Cada paso en el flujo básico indica un orden, en el cual los eventos deben ocurrir, sin la posibilidad (explicita) de hacerse en otro orden. En el caso en que esto ocurre, se deben especificar los eventos como parte de un mismo flujo o, de forma explícita, de que forma los eventos pueden ser ejecutados en otro orden. El siguiente ejemplo muestra los pasos en un flujo básico que indican secuencias que no son requeridas y dos alternativas para resolverlas.

 

Secuencia no requerida. No hay razón para solicitar información de la tarjeta de crédito en este orden.

1.    Introducir información de compra

El CU inicia cuando el usuario indica crear una solicitud para la venta de un ítem. El sistema solicita al usuario la información del cliente: nombre, apellido, CI, dirección y teléfono; la cantidad de productos a incluir en el pedido y la categoría de precios en la que se encuentra el cliente. El usuario indica al sistema la información solicitada e indica validar la información.

2.    Validar información de compra

El sistema verifica que todos los datos solicitados tengan información, y determina si el cliente ya se encuentra registrado en el sistema. El sistema determina que todos los datos suministrados son correctos y que el cliente no se encuentra registrado. El sistema solicita al usuario la confirmación del pedido.

3.    Confirmar la información de compra

El sistema presenta al usuario todos los datos suministrados en referencia al cliente, el pedido y la lista de precios solo en forma de lectura. El usuario puede confirmar la compra o indicar nuevos valores para este campo. El usuario confirma los datos.

4.    Indicar información de tarjeta de crédito

El sistema solicita al usuario la información de la tarjeta de crédito del cliente: banco, tipo, número, fecha de expiración, código de seguridad y nombre en la tarjeta de crédito. El usuario indica todos los datos y le indica al sistema realizar la compra.

5.    Crear solicitud de compra

El sistema crea la orden de compra con los datos suministrados y realiza la transacción con el banco. El banco autoriza la compra.

6.    Presentar resultado de la transacción

El sistema muestra al usuario un mensaje indicando que la transacción ha sido realizada de forma exitosa, presenta los datos de la compra y el detalle de los elementos vendidos. El sistema indica al usuario que entregue el pedido.

Alternativa 1. La solicitud de información de tarjeta de crédito no requiere hacerse luego de la validación.

1.    Introducir información de compra

El CU inicia cuando el usuario indica crear una solicitud para la venta de un ítem. El sistema solicita al usuario la información del cliente: nombre, apellido, CI, dirección y teléfono; la cantidad de productos a incluir en el pedido y la categoría de precios en la que se encuentra el cliente; y la información de tarjeta de crédito del cliente banco, tipo, número, fecha de expiración, código de seguridad y nombre en la tarjeta de crédito. El usuario indica al sistema la información solicitada e indica validar la información.

2.    Validar información de compra

El sistema verifica que todos los datos solicitados tengan información, y determina si el cliente ya se encuentra registrado en el sistema. El sistema determina que todos los datos suministrados son correctos y que el cliente no se encuentra registrado. El sistema solicita al usuario la confirmación del pedido.

3.    Confirmar la información de compra

El sistema presenta la usuario todos los datos suministrados en referencia al cliente, el pedido y la lista de precios solo en forma de lectura. El usuario puede confirmar la compra o indicar nuevos valores para este campo. El usuario confirma los datos.

4.    Crear solicitud de compra

El sistema crea la orden de compra con los datos suministrados y realiza la transacción con el banco. El banco autoriza la compra.

5.    Presentar resultado de la transacción

El sistema muestra al usuario un mensaje indicando que la transacción ha sido realizada de forma exitosa, presenta los datos de la compra y el detalle de los elementos vendidos. El sistema indica al usuario que entregue el pedido.

Alternativa 2. El sistema solicita al usuario toda la información pero no indica el orden en que debe ser presentada. Caso análogo a trabajar con tabs o pestañas.

1.    Iniciar compra

El CU inicia cuando el usuario indica crear una solicitud para la venta de un ítem.

2.    Introducir información de usuario

El sistema solicita al usuario la información del cliente: nombre, apellido, CI, dirección y teléfono.

3.    Introducir información de volumen de compra

El sistema solicita al usuario la cantidad de productos a incluir en el pedido y la categoría de precios en la que se encuentra el cliente. Este paso puede ocurrir en cualquier momento luego de iniciar la compra.

4.    Introducir información de tarjeta de crédito

El sistema solicita al usuario la información de tarjeta de crédito del cliente banco, tipo, número, fecha de expiración, código de seguridad y nombre en la tarjeta de crédito. Este paso puede ocurrir en cualquier momento luego de iniciar la compra.

5.    Validar información de compra

El usuario indica al sistema la información solicitada e indica validar la información. El sistema verifica que todos los datos solicitados tengan información, y determina si el cliente ya se encuentra registrado en el sistema. El sistema determina que todos los datos suministrados son correctos y que el cliente no se encuentra registrado. El sistema solicita al usuario la confirmación del pedido.

6.    Confirmar la información de compra

El sistema presenta la usuario todos los datos suministrados en referencia al cliente, el pedido y la lista de precios solo en forma de lectura. El usuario puede confirmar la compra o indicar nuevos valores para este campo. El usuario confirma los datos.

7.    Crear solicitud de compra

El sistema crea la orden de compra con los datos suministrados y realiza la transacción con el banco. El banco autoriza la compra.

8.    Presentar resultado de la transacción

El sistema muestra al usuario un mensaje indicando que la transacción ha sido realizada de forma exitosa, presenta los datos de la compra y el detalle de los elementos vendidos. El sistema indica al usuario que entregue el pedido.

Tabla 6. Manejo de secuencia de eventos

Si una secuencia de eventos se presenta, el diseñador o desarrollador asumirá que ésta es la forma correcta de realizar las actividades, sin dejar posibilidad a otras formas de realizar la secuencia de pasos.

Nivel de detalle esperado

Se espera que el nivel de detalle del caso de uso no contemple detalles sobre la interfaz, ni la arquitectura, ni el procesamiento interno de los datos cuando estos no sean concernientes a los involucrados. Los casos de uso presentan detalles de requerimientos, no de diseño, otras herramientas son utilizadas para el diseño, como el prototipo. Esta separación se realiza para hacer más fácil de entender los CU.

El caso de uso debe contener el detalle justo y necesario para explicar los intereses (requerimientos funcionales) del involucrado y entregar el sistema.

El nivel de detalle esperado para el caso de uso es el necesario para guiar al diseñador en la forma en que se desea presentar los datos y expresar los resultados, en ningún momento se debe limitar al diseñador en este aspecto. En caso de existir restricciones o requerimientos de algún otro tipo que limiten las opciones, los mismos deben ser referenciados en la sección de restricciones o requerimientos especiales según el caso.

Las siguientes palabras, como regla general, indican un nivel de detalle incorrecto: Base de Datos, archivo, etc., botón, HTML, http, SMTP, radio button.

¿Dónde colocar información necesaria sobre requerimientos de interfaz o arquitectura?

El documento que contiene los requerimientos debe contener esta información. Es deber del analista de requerimientos tomar en consideración todos los requerimientos recolectados y presentarlos de manera total y consistente para que el diseñador y desarrollador los puedan tener en cuenta a la hora de hacer su trabajo. Los requerimientos pueden ser presentados en el listado de requerimientos especiales.

Creatividad

Debe recordar que Ud. Está escribiendo flujos que afectarán la experiencia del usuario en la herramienta, y que eso que se defina será validado con el usuario. A la hora de escribir, el CU hágase la pregunta ¿Qué es lo que el sistema debería hacer mejor? ¿Qué hay detrás de los requerimientos? ¿A qué están acostumbrado los usuarios? ¿Dónde el CU genera valor? ¿Las necesidades de los usuarios quedarán totalmente satisfechas con la solución propuesta? ¿Qué otra cosa se podría hacer para al sistema sea más usable?

Recuerde que cuando escribe los CU, Ud. Está escribiendo como el sistema va a trabajar y como la experiencia del usuario se verá afectada por el uso del sistema.

Sin embargo, debe tomar en cuenta que si bien el CU debe agregar valor a los procesos que el actor realizará con la herramienta, el mismo debe poderse implementar en los tiempos solicitados, que el analista de requerimientos no debe introducir requerimientos que no agreguen valor a la cadena.

Especificaciones fáciles pueden hacer sistemas fáciles de utilizar. Especificaciones complicadas, harán, con toda seguridad, sistemas complejos, lo cual incrementa la oportunidad de rechazo del sistema por los usuarios, agregando a todo el equipo la posibilidad de fracaso, pues su éxito está atado al éxito de la experiencia que los usuarios con el uso del sistema que se está analizando.

Nombre de los actores en todas las secciones del caso de uso

Cuando el CU especifica los pasos que el actor está realizando en el sistema, el CU debe indicar claramente quién es el actor, no deben emplearse expresiones como: «El actor hace…. » en vez debe especificarse el nombre completo del actor el pseudónimo. Nótese que el pseudónimo puede ser el mismo en varios CU para hacer referencia a actores diferentes, entonces se debe estar claro que el alcance del pseudónimo se restringe, de manera estricta, al CU.

Los nombres de los actores siempre comienzan en mayúscula y todas las palabras que los componen comienzan en mayúsculas, como el formato de cualquier nombre de persona (menos los artículos, ejemplo: de, la, el, para, del, con, etc.

¿Cómo estructurar Casos de Uso?

La estructuración de los CU es un paso posterior a la construcción del modelo inicial del modelo de CU. La primera construcción del modelo de CU nunca incluye la estructuración, ello ocurre producto de la especificación cuando se comienza a ver que los casos de uso tienen definiciones semejantes, compartidas o dependientes. La estructuración de CU busca simplificar la explicación del funcionamiento del sistema y es el primer acercamiento para contemplar la reutilización y la modularización en la definición del diagrama de clases. La estructuración de CU consta de cuatro casos posibles que se listan a continuación, la explicación contiene la repercusión el modelo de clases resultantes.

Generalización de actores

La generalización de actores permite al analista identificar un rol que hace factor común de las funcionalidades de varios usuarios. Si el actor A1 puede hacer {UC1, UC2 y UC3} y el actor A2 puede hacer {UC1, UC3 y UC4} entonces se puede crear un actor A3 que puede hacer {UC1 y UC3}, que los actores A1 y A2 extiendan de A3, que A1 pueda hacer {UC2} y que A2 pueda hacer {UC4}. Gráficamente:

Generalización de casos de uso

Expresión clave: Plantilla de CU.

La generalización de CU, al igual que en los actores, permite extraer factor común de dos o más casos de uso que comparten características. En la generalización de CU existe un CU padre (o base, o general) y un CU hijo que es una especialización del base. En estos casos el hijo hereda todas las características del padre, puede agregar nuevas características, y puede modificar (sobrescribir) características del padre excepto por las relaciones y los puntos de extensión.

Cuando un CU es hijo de otro, en el nombre debe indicar cual es su padre, indicando: «CU.1.2 Crear libro «child» ». No es lógico el empleo de herencia múltiple en CU, por lo cual no está permitido. En la generalización de CU la numeración se modifica para indicar cual es el padre del caso de uso, en el ejemplo anterior el “CU.1.2 Crear libro” es hijo del “CU.1 Crear producto”, adicionalmente se agrega el indicador «child» para indicar que es la especialización de un caso de uso base. En la descripción del CU se indica cual es su CU base y que valor agrega sobre el mismo.

La especialización permite establecer en el padre un comportamiento general y el cada hijo una variación del comportamiento general, variando múltiples elementos del CU, ejemplo flujos básicos, alternos, precondiciones, etc. para lograr un resultado de valor. Un CU base puede ser especializado por múltiples veces.

Como buena práctica aunque no es necesario, se recomienda que cuando se hace generalización de CU, el CU base es abstracto, es decir que los actores no lo utilizan directamente sino que utilizan las especializaciones.

Cuando se especializa un CU, se inicia y termina la especialización y no el CU base.

Gráficamente, la generalización de CU se representa como a continuación. Note que CU.2 y CU.3 son los hijos y CU.1 es el padre.

Extensión de casos de uso

Expresión clave: Plugin.

La extensión de CU se utiliza para agregar nuevas funcionalidades o comportamientos a un CU. Cuando se extiende un CU, el CU base indica el punto en los que se hace la extensión.

Los puntos de extensión en la especificación del CU debe incluir, un título que es el nombre del CU que se extiende, y un texto de indica: 1) el paso del flujo básico que se extiende con esta funcionalidad o grupo de funcionalidades – note que los puntos de extensión nunca son sobre los flujos alternos – 2) opcionalmente la condición que establece que esta funcionalidad esté disponible para el actor, y 3) la acción que realiza el actor para que el flujo de eventos se curse hacia el CU extendido.

El nombre del CU que extiende especifica cual es su caso base de manera semejante a la generalización: «CU1.1 Procesar O/S manuales «extend» ». En este caso, el CU1.1 extiende al CU1 “Visualizar O/S”, e indica que es una extensión de funcionalidad del caso de uso base con la palabra clave “extend”.

En la extensión, los CU base son instanciados, no abstractos, a diferencia de lo que ocurre en la generalización.

Las extensiones son casos más específicos que las generalizaciones porque una especialización de CU puede contener muchas modificaciones al comportamiento de CU, mientras que una extensión se refiere a la adición de una funcionalidad a un CU en un punto específico. La extensión no sobrescribe las funcionalidades presentes en el CU base. Una extensión no tiene que ser un CU completo. El caso de uso que inicia es el CU base y se agrega la extensión.

Las extensiones se utilizan para:

  • Describir características que son opcionales al comportamiento básico del sistema.
  • Describir errores o excepciones complejas de considerarlas en el CU base complicaría su comprensión.
  • Personalización de requerimientos para resolver necesidades específicas del cliente.
  • Mejorar la gestión del alcance y la configuración de las soluciones entregadas.

Gráficamente, la extensión de CU se representa como a continuación. Note que CU.6 es la extensión de CU.1


Inclusión de casos de uso

Expresión clave: Factor común

La inclusión de CU se utiliza para extraer como factor común una serie de pasos que son repetidos en diferentes CU, permitiendo incluirlos múltiples veces sin necesidad de volverlos a escribir.

Cuando hay inclusiones, el CU base no está completo sin sus inclusiones, sin embargo, el CU inclusión puede o no ser completo por sí solo.

Los puntos de inclusión se emplean en los CU base para indicar el punto exacto donde se incluye su funcionamiento, la interpretación es que una vez que el punto de inclusión es alcanzado, el control pasa al CU de inclusión, luego que este termina, la ejecución retorna al CU base. Por lo tanto el flujo nunca se inicia por el CU de inclusión solo, a diferencia de lo que ocurren en las generalizaciones.

El punto de inclusión contiene un título que es el nombre del caso de inclusión y una descripción que contiene el punto o puntos en el FB en los que el CU se incluye.

El error más común es que un include se encuentre solo en un CU. A esto se le llama descomposición funcional. Los include habilitan la reutilización.

El nombre del CU de inclusión indica que es un CU de inclusión: «CU2 Buscar cliente «incluyes»». Todo el contenido del CU de inclusión es sumado al CU base.

Note que el CU de inclusión no tiene conciencia de los CU base que lo incluyen, sin embargo sabe que es un CU de inclusión.

Gráficamente, la inclusión de CU se representa como a continuación. Note que CU.1 y CU.4 incluyen la funcionalidad en CU.5

Como interactúan los CU

Bittner et al. explican que los CU no se comunican entre sí de forma directa, recuerde que los CU son solo descripciones. La única forma de interactuar entre ellos es a través del estado del sistema que describen. Los CU pueden chequear el estado del sistema en cualquier momento o esperar a que un estado cambie, así como depender de un estado empleando precondiciones. No hay forma directa de relacionar CU, y esto no es una debilidad. No hay nada en la definición de CU que permita la secuenciación entre diferentes CU de forma directa. Cada CU se espera que sea independiente de otros CU. Los CU son secuencias independientes de comportamientos que producen un resultado de valor a un usuario del sistema. La necesidad de hacer que un CU “llame” a otro es, normalmente, una deficiencia de la definición del alcance de los CU, en cuyo caso se recomienda que revise si cada CU se mantiene independiendo y produciendo un resultado de valor observable para el actor que lo invoca, generalmente se resuelve agrupando CU en uno solo.

Modelos de casos de uso no tienen niveles

Bittner et al. explican que los CU expresan lo que los involucrados quieren que el sistema haga, no como el sistema lo va a implementar. Quienes quieren ver niveles en CU quieren convertir los CU en instrumentos de análisis, permitiendo transparentar lo que se desea que sea la arquitectura del sistema en cuestión.

Los CU ayudan a capturar la descripción de lo que el sistema debe hacer. Esto es la expresión del comportamiento que se desea de un sistema. Por lo tanto, el sistema se debe comportar de esta forma independientemente del diseño y la implementación que se haga. El valor de los CU se encuentra en hacer que el comportamiento se exprese de forma simple y sin ambigüedades. Mientras más se estructura la descripción más difícil se hace comprender el comportamiento deseado.

Casos de uso de negocio (CUN) 

Para Bittner et al. (2006) los casos de uso pueden ser utilizados para definir procesos de negocio, en estos casos son llamados casos de uso de negocio (CUN) o “Business Use Cases (BUC)”, este término fue introducido por Jaccobson. Los actores en el modelo de casos de uso de negocio son externos al negocio, ellos son clientes, accionistas, proveedores y otras partes que participan en el negocio en algún tipo de relación.

Los casos de uso de negocio sirven para clarificar el ambiente en el que un sistema será utilizado, ellos pueden ser útiles para:

·        Clarificar el contexto del sistema y obtener el acuerdo de los requerimientos

·        Cuando se están modelando más de un sistema para soportar uno o más procesos de negocio. En este sentido los CUN especifican el alcance y las responsabilidades de cada uno de los sistemas.

·        En la construcción de aplicaciones que serán utilizados por varias organizaciones. En este caso muestran la flexibilidad de los sistemas para adaptarse a los procesos de dichas organizaciones.

·        Para definir sistemas que serán utilizados en nuevas líneas de negocio.

·        En proyectos complejos de reingeniería.

Los CUN muestran como los procesos son llevados a cabo por personas y los activos de la organización.

En la sección anterior se explicó que los CU, por ser herramientas para capturar requerimientos no tienen niveles. Trabajar con BUC y CU en un mismo proyecto no representa múltiples niveles de casos de uso, sin embargo, los BUC permiten identificar claramente, con base en un proceso de negocio, cuales serían las oportunidades de automatización y en ese caso sería una entrada importante de información para desarrollar los CU con base en los requerimientos del negocio.

Es importante aclarar que, así como los CU no explican como el sistema realiza las operaciones ni la forma de las interfaces con el usuario, los BUC no revelan detalles de cómo los procesos son implementados por los actores, ni los artefactos de uso interno del proceso, mas sí lo que hacen en el marco funcional.

Palabras reservadas

La siguiente es la lista de las palabras que son reservadas para la redacción del CU, y en ningún caso deberán ser empleadas como parte de las palabras relacionadas al contexto o negocio al que hace referencia el CU, a menos que se trate del mismo significado.

·        UC, CU: Caso de uso

·        BUC, CUN: Caso de uso de negocio

·        Actor: Actor del caso de uso

·        FB: Flujo básico

·        FA: Flujo alterno

·        Sistema: El sistema que se está analizando para este CU, en ningún caso debe ser utilizado como pseudónimo de un sistema externo.


Recomendaciones generales

Esta sección contiene recomendaciones que deben ser consideradas a la hora de redactar, tanto documentos de este tipo, como cualquier otro documento para la organización.

Empleo de estilos del procesador de palabras

Los procesadores de palabras cuentan en la actualidad con manejo de estilos o formatos preconfigurados de texto. Estos estilos, al igual que ocurre con los CSS (Cascade Style Sheets) en Web, hacen del documento un documento mucho más fácil de escribir y de modificar, puesto que con modificar el estilo se modifica todo el documento sin tener que identificar párrafo por párrafo donde se deben cambiar las fuentes, tamaños, etc.

Redacciones cortas, concisas y completas

Como a Ud., el resto de las personas que leen estos documentos probablemente no tengan tiempo de leerlo, por lo tanto considere escribir de forma de expresar todas las ideas relevantes sin emplear expresiones que abulten el texto que escribe sin agregar valor.

La forma estructurada de este documento tiene inmerso el espíritu de «solo escribir lo necesario y hacerlo sin ambigüedades». Procure mantener en mente esta expresión una vez que comience a escribir CU.

Lo otro que debe tener en mente es que alguien como Ud. va a leer este documento para hacer el análisis, implementar un sistema, escribir la documentación, identificar las pruebas y vender el funcionamiento del sistema, por lo que el documento debe ser: 1) lo suficientemente detallado para que el diseñador, programador, probador y documentalista no deba leer ningún documento no referenciado desde éste para realizar su trabajo en relación con el sistema, 2) lo suficientemente preciso para no aburrir a un usuario a quién se le explique como trabaja el sistema, sino que se obtenga de él el feedback que permita identificar los cambios necesarios en la fase de redacción de CU en vez de cuando se entregue el sistema, y 3) los suficientemente claro para que Ud. pueda entregar el documento y no tener que dar más explicaciones sobre lo que está escrito.

Material consultado

Las recomendaciones y estilos son inspirados en:

Curso de Análisis de Requerimientos con Casos de Uso (ARCU) IBM-ISCA.

Recomendaciones en Writing good Use Cases de Jim Heumann, Evangelista de Requerimientos  (IBM)

J. Arlow, I. Neustatd, (2005). UML 2 and The Unified Proccess. Addison Wesley. 2da Edición, Massachusetts, USA

K. Bittner, I Spence (2006). Use case modelling. Addison Wesley. Massachusetts, USA

Armour F., Miller G. (2001). Advanced Use Case Modelling. Addison Wesley, 8th printing. Massachusetts, USA

 

Comments