casos de uso

CASOS DE USO
Texto tomado de: Meyer, B. (1999). Construcción de
software Orientado a Objetos (Segunda ed.). Madrid,
España: Prentice Hall.

Ivar Jacobson ha abogado por basarse en los casos de uso como forma de obtener clases. Un caso
de uso (use case) denominado escenario por otros autores de análisis y diseño (y traza de sucesos
en la informática teórica. especialmente en el estudio dela concurrencia), es una descripción de
un curso completo de eventos iniciados por un [usuario del futuro sistema] y [de]
la interacción entre [el usuario] y el sistema.
Por ejemplo, en un sistema de conmutación telefónica, en caso de uso “el usuario inicia una
llamada” tiene una secuencia de eventos: el usuario levanta el auricular, se manda una
identificación al sistema, el sistema envíatono de marcar, y así sucesivamente. Otros casos de uso
del sistema pudieran incluir “la instalación de un servicio de identificación de quién llama” y la
“desconexión de un usuario”.
Los casos de uso no son una buena herramienta para encontrar clases. Apoyarse en ellos de
manera significativa entraña varios riesgos:


1

Los casos de uso hacen hincapié en un orden (“Cuando un consumidorhace un pedido por
teléfono, se valida el número de su tarjeta de crédito. Entonces la base de datos se
actualiza y se crea un número de confirmación”, etc.). Esto es incompatible con la
tecnología de objetos que rehuye una dependencia temprana de propiedades
secuenciales, porque éstas son muy frágiles y están sometidas a cambios. El analista y
diseñador O-O competente rechaza centrar laatención en propiedades de la forma “El
sistema hace a y luego b”; en lugar de esto plantea la pregunta “¿Cuáles son las
operaciones disponibles sobre instancias de la abstracción A y cuáles son las restricciones
de estas operaciones? Las verdaderas propiedades secuenciales emergerán en la forma de
restricciones de alto nivel sobre las operaciones; por ejemplo en lugar de decir que una
pila1 admiteuna secuencia de operaciones alternadas de push y pop con nunca más pop
que push, lo que se hace es asociar precondiciones a cada una de estas operaciones, lo
que implica una propiedad de orden, pero es más abstracto. Los requisitos de orden
menos fundamentales no tienen cabida en el modelo de análisis ya que destruyen la

Una pila (stack en inglés) es una lista ordenada o estructura de datosen la que el modo de acceso a sus
elementos es de tipo LIFO (del inglés Last In First Out, último en entrar, primero en salir) que permite
almacenar y recuperar datos. Para el manejo de los datos se cuenta con dos operaciones básicas: apilar
(push), que coloca un objeto en la pila, y su operación inversa, retirar (o desapilar, pop), que retira el último
elemento apilado. [Tomado de Wikipedia]



adaptabilidad del sistema y por consiguiente su futura supervivencia. Un énfasis temprano
en el orden está entre los peores errores que puede cometer un proyecto O-O. Si uno se
apoya en los casos de uso para el análisis, este error es difícil de evitar.
Apoyarse en un escenario significa centrar la atención en la forma en que los usuarios ven
el funcionamiento del sistema. Peroel sistema no existe todavía. (Podría existir un sistema
anterior, pero si fuese totalmente satisfactorio no se habría solicitado cambiarlo o
reescribirlo.) De modo que el panorama del sistema que dan los casos de uso están
basados en procesos existentes, informatizados o no. La tarea como constructor de un
sistema es inventar escenarios nuevos, mejores, no perpetuar modos anticuados deoperación. Ya hay más que suficientes ejemplos de sistemas que imitan servilmente
procedimientos obsoletos.
Los casos de uso favorecen un enfoque funcional, basado en procesos (acciones). Este
enfoque es el inverso de la descomposición O-O, que se centra en las abstracciones de
datos. Esto conlleva un serio riesgo de volver, bajo un título de desarrollo orientado a
objetos, a las formas más...