Casos De Uso

1. Introducción

1.1. Objetivo de este apunte

En uno de los párrafos más citados del artículo por lejos más citado en la bibliografía de la Ingeniería del

Software, Frederick P. Brooks [Brooks87], dice: “La parte más difícil de construir un sistema es

precisamente saber qué construir. Ninguna otra parte del trabajo conceptual es tan difícil como establecer

los requerimientos técnicos detallados, incluyendo todas las interfaces con gente, máquinas, y otros sistemas.

Ninguna otra parte del trabajo afecta tanto al sistema si es hecha mal. Ninguna es tan difícil de corregir mas

adelante... Entonces, la tarea más importante que el ingeniero de software hace para el cliente es la

extracción iterativa y el refinamiento de los requerimientos del producto”.

Los casos de uso son un método que, justamente, ayudan al Ingeniero de Software a llevar adelante esta parte

del desarrollo de un sistema de software.

Si bien sus antecedentes tienen ya más de 15 años de antigüedad, la técnica de análisis con caso de uso es

relativamente nueva. La bibliografía es bastante escasa y, en muchos casos, tiene pocos consejos prácticos

para ayudar al personal de desarrollo de sistemas que intenta aplicarla.

El objetivo principal de este apunte es ayudar a los alumnos de Ingeniería del Software I a aplicar la técnica

de análisis con casos de uso en sus trabajos prácticos. Además, esperamos que sea de utilidad para quien

quiera aplicarla en un proyecto de desarrollo real.

1.2. ¿Qué son los Casos de Uso?

Los casos de uso son una técnica para especificar el comportamiento de un sistema:

“Un caso de uso es una secuencia de interacciones entre un sistema y alguien o algo que usa alguno de sus

servicios.”

Todo sistema de software ofrece a su entorno –aquellos que lo usan– una serie de servicios. Un caso de uso es

una forma de expresar cómo alguien o algo externo a un sistema lo usa. Cuando decimos “alguien o algo”

hacemos referencia a que los sistemas son usados no sólo por personas, sino también por otros sistemas de

hardware y software.

Por ejemplo, un sistema de ventas, si pretende tener éxito, debe ofrecer un servicio para ingresar un nuevo

pedido de un cliente. Cuando un usuario accede a este servicio, podemos decir que está “ejecutando” el caso

de uso ingresando pedido.

1.3. Historia

Los Casos de Uso fueron introducidos por Jacobson en 1992 [Jacobson92]. Sin embargo, la idea de

especificar un sistema a partir de su interacción con el entorno es original de Mc Menamin y Palmer, dos

precursores del análisis estructurado, que escribieron en 1984 un excelente libro cuya lectura recomendamos

[McMenamin84]. En ese libro, se define un concepto muy parecido al del caso de uso: el evento. Para Mc

Menamin y Palmer, un evento es algo que ocurre fuera de los límites del sistema, ante lo cual el sistema debe

responder. Siguiendo con nuestro ejemplo anterior, nuestro sistema de ventas tendrá un evento “Cliente hace

Pedido”. En este caso el sistema deberá responder al estimulo que recibe –el pedido– procesándolo.

Casos de Uso – Un Método Práctico para Explorar Requerimientos

Cátedra de Ingeniería del Software I Pág. 2

Sin embargo, existen algunas diferencias entre los casos de uso y los eventos. Las principales son:

1) Los eventos se centran en describir qué hace el sistema cuando el evento ocurre, mientras que los casos

de uso se centran en describir cómo es el diálogo entre el usuario y el sistema.

2) Los eventos son “atómicos”: se recibe una entrada, se la procesa, y se genera una salida, mientras que los

casos de uso se prolongan a lo largo del tiempo mientras dure la interacción del usuario con el sistema.

De esta forma, un caso de uso puede agrupar a varios eventos.

3) Para los eventos, lo importante es qué datos ingresan al sistema o salen de él cuando ocurre el evento

(estos datos se llaman datos esenciales), mientras que para los casos de uso la importancia del detalle

sobre la información que se intercambia es secundaria. Según esta técnica, ya habrá tiempo más adelante

en el desarrollo del sistema para ocuparse de este tema.

Los casos de uso combinan el concepto de evento del análisis estructurado con otra técnica de especificación

de requerimientos bastante poco difundida: aquella que dice que una buena forma de expresar los

requerimientos de un sistema es escribir su manual de usuario antes de construirlo. Esta técnica, si bien ganó

pocos adeptos, se basa en un concepto muy interesante: al definir requerimientos, es importante describir al

sistema desde el punto de vista de aquél que lo va a usar, y no desde el punto de vista del que lo va a

construir. De esta forma, es más fácil validar que los requerimientos documentados son los verdaderos

requerimientos de los usuarios, ya que éstos comprenderán fácilmente la forma en la que están expresados.

1.4. Aclaraciones Importantes

...