Casos De Uso

Modelización con Diagramas de Casos de Uso

Maestrando: Ing. Javier Nader

1- Introducción

En la perspectiva Orientada a Objetos el principal bloque de todos los sistemas

software es el objeto o clase. Por ejemplo, considérese una arquitectura

sencilla de tres capas para un sistema de contabilidad, que involucre una

interfaz de usuario, una capa intermedia y una base de datos. En la interfaz del

usuario aparecen objetos tales como botones, menúes, y cuadros de diálogos.

En la base de datos aparecen objetos concretos como tablas que representan

entidades del dominio del problema. En la capa intermedia aparecen objetos

como transacciones y reglas del negocio, así como vistas de más alto nivel de

las entidades del problema.

Visualizar, especificar, construir y documentar sistemas desde la perspectiva

orientada a objetos se puede realizar con el Lenguaje Unificado de Modelado

(UML).

En este documento se presenta uno de los tantos diagramas del UML,

Diagramas de Casos de Uso. Se introduce en la terminología de estos

diagramas, como construirlos, sus características principales, ejemplos y se

propone una herramienta CASE para automatizar su construcción. Los

ejemplos mostrados son a efectos de ejemplificar en términos generales las

características principales y la forma de los diagramas, ya que el presente

documento no pretende mostrar una modelización completa sino introducir los

conceptos principales de los diagramas de casos de uso.

Para presentar los conceptos principales se utilizaran ejemplos en donde se

verá como se puede modelar un diagrama de contexto y un diagrama de

requisitos utilizando los casos de uso. Estos modelos están basados en una

descripción en donde se puede observar la necesidad de automatización de

una biblioteca que pertenece a una universidad. En dicha automatización se

destacarán ciertas necesidades como préstamos, devoluciones y

mantenimiento de los libros entre otros.

2- Casos de Uso

Ningún sistema se encuentra aislado. Cualquier sistema interactúa con actores

humanos o mecánicos que lo utilizan con algún objetivo y que esperan que el

sistema funcione de forma predecible.

Los casos de uso bien estructurados denotan solo comportamientos esenciales

del sistema o de un subsistema, y nunca deben ser excesivamente genéricos ni

demasiado específicos.

2.1- Introducción a los Casos de Uso

Un factor clave al definir casos de uso es que no se debe especificar como

implementarlos. Por ejemplo, se puede especificar como debería comportarse

un Sistema de Gestión de una Biblioteca mediante casos de uso y como

interactúan los usuarios con el sistema. Los casos de uso especifican un

comportamiento deseado, no imponen como se llevara a cabo ese

comportamiento. Lo más importante es que se permite que los usuarios finales

y los expertos del dominio se comuniquen con lo desarrolladores sin entrar en

detalles. Estos detalles llegaran, pero los casos de uso permiten centrarse en

las cuestiones más importantes para el usuario final.

En UML, todos esos comportamientos se modelan como casos de uso que

pueden especificarse independientemente de su realización. Un caso de uso es

una descripción de un conjunto de secuencias de acciones, incluyendo

variantes, que ejecuta un sistema para producir un resultado observable, de

valor para un actor.

Un caso de uso describe un conjunto de secuencias, donde cada secuencia

representa la interacción de los elementos externos al sistema (sus actores)

con el propio sistema (y sus abstracciones clave). En realidad, estos

comportamientos son funciones a nivel del sistema que se utilizan durante la

captura de requisitos y el análisis para visualizar, especificar, construir y

documentar el comportamiento del sistema. Por ejemplo, un caso de uso

fundamental en el Sistema de Gestión de Bibliotecas es el procesamiento de

Préstamos de libros.

Un caso de uso involucra la interacción de actores y el sistema. Un actor

representa un conjunto coherente de roles que juegan los usuarios de los

casos de uso al interactuar con estos. Los actores pueden ser personas o

pueden ser sistemas mecánicos. Por ejemplo, en el modelado de la Biblioteca,

el procesamiento de un préstamo (modelado como caso de uso) implica, entre

otras cosas, la interacción con un responsable o encargado de la biblioteca

(modelado como un actor).

Un caso de uso puede tener variantes. En cualquier sistema se pueden

encontrar casos de uso que son versiones especializadas de otros casos de

uso, casos de uso incluidos como parte de otros, y casos que extienden el

comportamiento de otros casos de uso básicos. Se puede factorizar el

comportamiento común y reutilizable de un conjunto de casos de uso

organizándolos según estos tres tipos de relaciones. Por ejemplo, cuando se

modela una biblioteca aparecen muchas variaciones del caso de uso básico de

procesar un préstamo, tales como las diferencias entre procesar un préstamo

de un libro frente a un préstamo que involucre gran cantidad de libros. En cada

opción, sin embargo, estos casos de uso comparten algo de comportamiento,

como el caso de uso de aprobar el préstamo para muchos libros, un

comportamiento que es parte del procesamiento de cualquier tipo de préstamo.

Los casos de uso se pueden aplicar al sistema completo. También se pueden

aplicar a partes del sistema, incluyendo subsistemas e incluso clases e

interfaces individuales. En cada caso, estos casos de uso no solo representan

el comportamiento esperado de estos elementos, sino que también pueden

utiizarse como la base para establecer casos de pruebas para estos elementos

mientras evolucionan durante el desarrollo del sistema. Los casos de uso,

aplicados al sistema completo son una fuente excelente de pruebas del sistema

y de integración. UML proporciona una representación gráfica de un caso de

uso y un actor, como se muestra en la figura 1. Esta notación permite visualizar

un caso de uso independientemente de su implementación y en un contexto

con otros caso de uso.

Figura 1. Actor, Asociación y Caso de Uso.

2.2- Términos y Conceptos

2.2.1- Nombres

Gráficamente, un caso de uso se representa como una elipse. Cada caso de

uso debe tener un nombre que lo distinga de otros casos de uso. Un nombre es

una cadena de texto. Ese nombre solo se llama nombre simple; un nombre de

camino consta del nombre del caso de uso precedido del nombre del paquete

(se denomina paquete a un mecanismo de propósito general para organizar

elementos en grupos) en el que se encuentra. Normalmente, un caso de uso se

dibuja mostrando solo su nombre, como se muestra en la figura 2.

Gestión de

Préstamos

Encargado

nombre

actor caso de uso

asociación

Figura 2. Nombres simples y de camino.

2.2.2- Casos de Uso y Actores

Un actor representa un conjunto coherente de roles que los usuarios de los

casos de uso juegan al interactuar con estos. Normalmente, un actor

representa un rol que es jugado por una persona, un dispositivo hardware o

incluso otro sistema al interactuar con nuestro sistema.

Como se muestra en la figura 3, los actores se representan como monigotes.

Se pueden definir categorías generales de actores (como Lector) y

especializarlos (como Estudiante) a través de relaciones de generalización.

Figura 3. Actores

Los actores sólo pueden conectarse a los casos de uso a través de

asociaciones (ver figura 1). Una asociación entre un actor y un caso de uso

Gestión de

Préstamos

nombre simple

Gestión de

Devoluciones

Usuarios::Verificar

nombre de Tipo Lector

camino

Lector

actor

Estudiante

actor

generalización

indica que el actor y el caso de uso se comunican entre sí, y cada uno puede

enviar y recibir mensajes.

2.2.3- Casos de Uso y Flujo de Eventos

El comportamiento de un caso de uso se puede especificar describiendo un

flujo de eventos de forma textual, lo suficientemente claro para que alguien

ajeno al sistema lo entienda fácilmente. Cuando se describe este flujo de

eventos se debe incluir como y cuando empieza y acaba el caso de uso,

cuando interactúa con los actores y que objetos se intercambian, el flujo básico

y los flujos alternativos del comportamiento.

Por ejemplo, en el contexto de la biblioteca, se podría describir el caso de uso

Gestión de Validación Tipo de Usuario de la siguiente forma:

Flujo de eventos principal: El caso de uso comienza cuando el sistema pide al

usuario el Número de Identificación o Nombre de usuario. El usuario puede

introducir su identificación a través del teclado. El usuario acepta la entrada

pulsando el botón Enter. El sistema comprueba entonces este número o

nombre para ver si es válido y a que tipo de lector pertenece. Si el número o

...