Casos De Uso
CARLOSKAX29 de Noviembre de 2011
7.273 Palabras (30 Páginas)654 Visitas
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
Este apunte no es sólo un resumen de la bibliografía existente, sino que intenta agregar conceptos que
surgieron a partir de la aplicación de los casos de uso en la práctica. Por lo tanto, es importante tener en
cuenta que lo que se discute en este apunte, si bien está basado en la bibliografía, no necesariamente refleja
estrictamente las definiciones formales sobre los casos de uso. Por ejemplo, la técnica de identificar nuevos
casos de uso a partir de casos existentes, discutida más adelante, está basada en el análisis estructurado, pero
no es mencionada en la bibliografía que describe los casos de uso.
1.5. Los Casos de Uso y UML
A partir de la publicación del libro de Jacobson, gran parte de los más reconocidos especialistas en métodos
Orientados a Objetos coincidieron en considerar a los casos de uso como una excelente forma de especificar
el comportamiento externo de un sistema. De esta forma, la notación de los casos de uso fue incorporada al
lenguaje estándar de modelado UML –Unified Modelling Language– propuesto por Ivar Jacobson, James
Rumbaugh y Grady Booch, tres de los precursores de las metodologías de Análisis y Diseño Orientado a
Objetos, y avalado por las principales empresas que desarrollan software en el mundo. UML va en camino de
convertirse en un estándar para modelado de sistemas de software de amplia difusión.
A pesar de ser considerada una técnica de Análisis Orientado a Objetos, es importante destacar que los casos
de uso poco tienen que ver con entender a un sistema como un conjunto de objetos que interactúan, que es la
premisa básica del análisis orientado a objetos “clásico”. En este sentido, el éxito de los casos de uso no hace
más que dar la razón al análisis estructurado, que propone que la mejor forma de empezar a entender un
sistema es a partir de los servicios o funciones que ofrece a su entorno, independientemente de los objetos que
interactúan dentro del sistema para proveerlos.
Como era de esperar, es probable que en el futuro los métodos de análisis y diseño que prevalezcan hayan
adoptado las principales ventajas de todos los métodos disponibles en la actualidad –estructurados, métodos
formales, métodos orientados a objetos, etc.–
De lo dicho anteriormente podemos concluir que los casos de uso son independientes del método de diseño
que se utilice, y por lo tanto del método de programación. Luego de documentar los requerimientos de un
sistema con casos de uso, se puede diseñar un sistema “estructurado” (manteniendo una separación entre
datos y funciones), o un sistema Orientado a Objetos, sin que la técnica sea de mayor o menor utilidad en
alguno de los dos casos. Esto da más flexibilidad al método, y probablemente contribuya a su éxito.
Casos de Uso – Un Método Práctico para Explorar Requerimientos
Cátedra de Ingeniería del Software I Pág. 3
2. Definiciones Básicas
2.1. Actores
Un actor es una agrupación uniforme de personas, sistemas o máquinas que interactúan con el sistema que
estamos construyendo de la misma forma. Por ejemplo, para una empresa que recibe pedidos en forma
telefónica, todos los operadores que reciban pedidos y los ingresen en un sistema de ventas, si pueden hacer
las mismas cosas con el sistema, son considerados un único actor: Empleado de Ventas.
Los actores son externos al sistema que vamos a desarrollar. Por lo tanto, al identificar actores estamos
empezando a delimitar el sistema, y a definir su alcance. Definir el alcance del sistema debe ser el primer
objetivo de todo analista, ya que un proyecto sin alcance definido nunca podrá alcanzar sus objetivos.
Es importante tener clara la diferencia entre usuario y actor. Un actor es una clase de rol, mientras que un
usuario es una persona que, cuando usa el sistema, asume un rol. De esta forma, un usuario puede acceder al
sistema como distintos actores. La forma más simple de entender esto es pensar en perfiles de usuario de un
sistema operativo. Una misma persona puede acceder al sistema con distintos perfiles, que le permiten hacer
cosas distintas. Los perfiles son en este caso equivalentes a los actores.
...