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.