Casos_uso

Esta es una vista previa del archivo. Inicie sesión para ver el archivo original

Casos_uso.pdf
Guía Básica de Referencia Sobre
Casos de Uso
Oscar Canalejo Castrillero - 2003
Guía Básica de Referencia Sobre Casos de Uso
Contenido
Introducción .......................................................................................................................................3
¿Qué contiene esta guía? ¿A quién va dirigida?..........................................................................3
Los Casos de Uso .............................................................................................................................4
¿Qué son los Casos de Uso?........................................................................................................4
¿Qué ventajas me pueden aportar?..............................................................................................4
Identificar los Casos de Uso del sistema.......................................................................................4
Errores comunes en la identificación de Casos de Uso...............................................................5
Los Actores ........................................................................................................................................6
¿Qué es un actor de Casos de Uso, qué representa?.................................................................6
Identificar a los Actores...................................................................................................................7
Los Actores juegan Roles...............................................................................................................7
La importancia de la frontera o contexto del sistema...................................................................8
Escribiendo Casos de Uso ..............................................................................................................9
¿Qué son los Diagramas de Casos de Uso?................................................................................9
¿Cómo represento las ramificaciones que puede sufrir un Caso de Uso?................................9
¿Cuándo debo usar la relación Includes y cuándo la relación Extends?...................................9
Plantillas de Casos de Uso...........................................................................................................12
Consejos y recordatorios importantes .......................................................................................13
No olvidar la perspectiva del usuario...........................................................................................13
No perder de vista la frontera del sistema...................................................................................13
No confundir un paso o transacción individual como un caso de uso en sí mismo ...............13
Identificar los verdaderos objetivos del usuario..........................................................................13
Evitar una excesiva descomposición...........................................................................................13
Evitar una excesiva abstracción...................................................................................................13
No escribir los casos de uso demasiado escuetos....................................................................13
No omitir los posibles cursos alternativos...................................................................................13
No complicarse la vida decidiendo si usar “includes” o “extends”............................................14
Mantener separadas las cuestiones sobre la Interfaz de Usuario............................................14
Bibliografía y Enlaces de interés .................................................................................................15
Bibliografía.....................................................................................................................................15
Enlaces de Interés .......................................................................................................................15
Agradecimientos .............................................................................................................................16
Página 2 de 17
Guía Básica de Referencia Sobre Casos de Uso
Introducción
No son pocos los casos en los que, tras varios meses de trabajo duro y noches en vela, por fin
se entrega el producto al cliente. Pero durante la presentación, éste interrumpe
frecuentemente un tanto mosqueado: “¿Por qué cuando hago esto el sistema no aplica la
regla de negocio correspondiente?”, “¿Por qué no habéis incluido aquella opción que os dije
que era muy importante”?, “¿Por qué esa pantalla presenta esos datos en lugar de los que
realmente necesito?”. 
La captura y documentación de requisitos es una de las tareas más importantes en el
desarrollo de aplicaciones informáticas. Puede que sea incluso la más importante de todas,
puesto que de una adecuada comprensión de los requisitos del sistema depende en gran
parte el éxito o fracaso del proyecto. Quizá nuestro sistema sea el más veloz, el que mejor
aprovecha los recursos, el que menos incidencias reportará, el que está diseñado y
programado con la mayor elegancia y haciendo uso de las últimas tecnologías. Pero si no
hace lo que el usuario realmente necesita, habremos fracasado estrepitosamente. 
¿Qué contiene esta guía? ¿A quién va dirigida?
Ya hace algún tiempo que empecé a tomar notas y recoger conclusiones personales sobre la
capura de requisitos mediante casos de uso, fruto de largas charlas con compañeros, de
varios artículos sobre el tema y de algunos libros sobre análisis y diseño de software.
Mi intención era elaborar una especie de guía de referencia para tenerla siempre a mano, que
recogiese en pocas páginas las cuestiones principales sobre casos de uso. Cuestiones que
debía recordar al comienzo de un nuevo proyecto o en la revisión de uno ya desarrollado
anteriormente.
Por tanto este documento no ambiciona ser un manual o un gran tutorial, con ejemplos
prácticos y extensas explicaciones. No es ni más ni menos que un resumen, una guía básica
de referencia sobre casos de uso. Algo que pueda servirnos para, con un rápido vistazo,
repasar y no perder de vista las cuestiones fundamentales sobre el tema.
Estas páginas están dirigidas a todos aquellos que ya conozcan algo o que deseen iniciarse
en el modelado de requisitos mediante Casos de Uso. Para aquellos que tengan intereses
personales o profesionales en el Análisis y Diseño de software y más concretamente en las
fases tempranas del análisis, donde intervienen las tareas de captura y documentación de las
funcionalidades del sistema, y la necesidad de investigar aquello que el sistema debe hacer
antes de investigar cómo debe hacerlo.
Página 3 de 17
Guía Básica de Referencia Sobre Casos de Uso
Los Casos de Uso
¿Qué son los Casos de Uso?
Los casos de uso son casos de utilización del sistema, descripciones narrativas de su
comportamiento, gracias a las cuales podemos mejorar la comprensión de los requisitos.
Estas descripciones cubren tanto el comportamiento normal del sistema, como todas las
variantes, de éxito o de fracaso, que pudieran originarse durante un proceso.
Un caso de uso capta una funcionalidad visible para el usuario. Logra un objetivo concreto,
tangible.
Por tanto, podemos decir que un caso de uso: Describe la secuencia de eventos y acciones
que se producen entre un Actor y un Sistema que interactuan para cumplir un objetivo.
¿Qué ventajas me pueden aportar?
Los casos de uso:
− Documentan los procesos de negocio del sistema.
− Capturan los requisitos del sistema desde la perspectiva del usuario (libres de cuestiones
de implementación), y por tanto lo involucran en la revisión y validación de los mismos. Su
lenguaje es igualmente comprensible y útil para los miembros el equipo de desarrollo.
− Descubren posibles áreas de colaboración del negocio.
− Permiten separar
los procesos del negocio en áreas funcionales.
− Ayudan a identificar posibilidades de reutilización.
− Pueden emplearse para categorizar los requisitos del sistema (Nivel de importancia, Nivel
de riesgo, Nivel de Prioridad, Nivel de Dificultad, etc.).
− Pueden ser utilizados para exponer los requisitos a varios niveles: De alto nivel, nivel de
diseño detallado, ...).
− Gracias a ellos podemos identificar y mostrar el impacto que tendrán los cambios de
requisitos funcionales sobre la implementación, o el impacto de los cambios de
implementación sobre la funcionalidad del sistema.
− Sirven como base para el plan de pruebas del sistema.
− Para la elaboración del manual de usuario pueden aprovecharse gran parte de las
descripciones de los casos de uso.
− Fomentan la calidad del sistema, ya que identifican escenarios alternativos y excepciones
posibles, en una fase temprana del proceso de desarrollo.
Identificar los Casos de Uso del sistema
Existen dos métodos distintos para identificar los casos de uso:
• Identificación basada en los actores:
1: Se identifican los actores.
Página 4 de 17
Guía Básica de Referencia Sobre Casos de Uso
2: Averiguamos qué procesos inician o en cuáles participan:
− ¿Cuáles son sus responsabilidades, de qué tareas se encargan:
Crear/Modificar/Eliminar elementos, Introducir/Obtener datos,
Mantenimiento/Soporte del sistema?.
− ¿Deberán informar al sistema sobre algún evento externo que se produzca (ej.
Llegada de ficheros de datos a su destino, listos para ser procesados)?
− ¿Deben ser informados por el sistema sobre algún evento que se produzca (ej.:
Error en la ejecución de un proceso desatendido)?.
− ¿Necesitan indicar al sistema que efectúe algún proceso concreto en un momento
determinado (ej.: Realizar una copia de seguridad de los datos del período)?.
− Otros procesos en los que los actores participen como estimuladores del sistema,
como receptores de información procedente del sistema, o como colaboradores del
mismo en la ejecución de tareas.
• Identificación basada en los eventos:
1: Se identifican los eventos ante los que el Sistema debe reaccionar.
− Creación/Modificación/Eliminación de elementos.
− Entrada/Solicitud de datos por parte de algún actor.
− Orden de ejecución de algún proceso.
− Notificaciones sobre eventos externos al sistema (p.ej.: El paso del tiempo).
− ¿Es necesario que algún actor sea informado sobre ciertos cambios o
acontecimientos que se produzcan en el sistema?
− Cualquier otro evento ante el cual el sistema deba reaccionar.
2: Se relacionan los eventos con actores y con casos de uso.
Al finalizar, deberemos hacernos una última pregunta: ¿Los casos de uso que hemos
identificado son capaces de cubrir todos los requisitos funcionales que tenemos anotados?
Errores comunes en la identificación de Casos de Uso
− La Parte por el Todo:
Hay que recordar que un caso de uso está formado por un conjunto de pasos o transacciones
necesarios para cumplir un proceso. Sin embargo, un error común en la identificación de
casos de uso, es representar los pasos, las operaciones o las transacciones individuales,
como casos de uso. Por ejemplo: “Imprimir Factura” sería un caso de uso erróneo, puesto que
en realidad se trata de un paso u operación del caso de uso “Comprar Producto/Servicio”. No
obstante hay ocasiones en las que un paso o transacción de un caso de uso merece ser
representado como un caso de uso aparte (Lo veremos más adelante, en el repaso de
“Includes/Extends”).
− “Interacciones con el sistema” y “Objetivos del usuario”: 
En ocasiones existen diferencias entre lo que el usuario hace con el sistema, y los verdaderos
objetivos del usuario. Por ejemplo, en un procesador de textos “Aplica Negrita” y “Cambia
estilo” son interacciones con el sistema. Sin embargo, los verdaderos objetivos del usuario
son: “Garantiza el formato del documento” y “Haz que el formato del documento sea igual que
el de otro”. 
Página 5 de 17
Guía Básica de Referencia Sobre Casos de Uso
Teniendo en cuenta tanto los objetivos del usuario como las interacciones con el sistema,
podremos considerar formas alternativas para el cumplimiento de tales objetivos. Si llegamos
muy pronto a la interacción con el sistema, quizá recurriremos a la opción obvia para la
solución, pasando por alto otras maneras posiblemente más efectivas de cumplir con los
objetivos del usuario.
Página 6 de 17
Guía Básica de Referencia Sobre Casos de Uso
Los Actores
¿Qué es un actor de Casos de Uso, qué representa?
Los actores no forman parte del sistema. Un actor es una entidad externa al sistema que de
alguna manera participa en el caso de uso. Generalmente estimula al sistema con eventos de
entrada, o bien recibe algo de él.
Podemos distinguir varios tipos de actores:
 
Actor Silencioso:
Es aquel que tiene un interés personal en el comportamiento del caso de uso, incluso si nunca
interactúa directamente con el sistema. Ejemplos de este tipo de actores serían: El dueño del
sistema, el departamento de procesos de la compañía, etc. 
Prestar atención a este tipo de actores mejora la calidad de los casos de uso. Sus intereses se
advierten en las validaciones que el sistema realiza, los logs que genera, y las acciones que
lleva a cabo. Los casos de uso deben también mostrar cómo el sistema protege estos
intereses.
Actor Principal:
Es aquel que invoca al sistema para lograr cierto objetivo. Este actor es frecuentemente,
aunque no siempre, quien inicia el caso de uso enviándole un mensaje, pulsando un botón,
etc. Hay dos situaciones comunes en las que el que inicia el caso de uso no es el actor
principal: Una es cuando un operador telefónico o un dependiente de una tienda inician el caso
de uso ante una petición de otra persona, que es la realmente interesada. El otro caso se da
cuando el que inicia el caso de uso es “el tiempo”.
Los actores principales son importantes al principio de la captura de requisitos y después,
justo antes de empezar a desarrollar el sistema. Entre estos dos puntos, no deben
preocuparnos demasiado. 
Durante la fase inicial de caputra de requisitos, obtener una completa lista de actores
principales nos permite tener un punto de vista amplio sobre el sistema, detectando y
comprendiendo los objetivos que deben cumplirse, basándonos en las necesidades de esos
actores principales.
Antes de empezar a desarrollar el sistema, hacer un repaso de esa lista nos permitirá
asegurarnos de que dichas necesidades han sido realmente satisfechas, establecer niveles de
seguridad para cada caso de uso (administrador, usuario web, ...), y preparar manuales de
usuario para los distintos grupos de usuarios.
Actor de Soporte:
Es aquel que proporciona un servicio al sistema. Puede ser una impresora, otro sistema
distinto al nuestro que provee acceso a sus servicios (p.ej.: Web Services), o que invoca a
nuestro sistema para lograr un objetivo, etc. Identificar los actores de soporte es muy
importante, porque eso nos permitirá detectar las interfaces externas que nuestro sistema
utilizará. Un mismo actor puede ejercer de actor principal en un caso de uso, y de actor de
soporte en otro.
También es cierto que sobre la conveniencia de identificar como actor a un sistema externo,
hay diferentes opiniones entre los gurús del tema. Yo personalmente me quedo con la primera,
por los motivos que acabo de exponer, pero tú échales un vistazo y luego decide por tí mism@
cuál te parece mejor:
Página 7 de 17
Guía Básica de Referencia Sobre Casos de Uso
− Todas las interacciones con sistemas externos deben aparecer en el diagrama de casos
de uso.
− Sólo se deben mostrar los sistemas externos como actores, cuando ellos sean los que
inicien el caso de uso.
− Sólo se deben mostrar los sistemas externos como actores, cuando ellos sean los que
necesiten al caso de uso (Martin Fowler, autor de “UML Gota a Gota”, se queda con esta).
− Algunos piensan que es un enfoque equivocado considerar que un sistema externo
es un
actor. Paradójicamente, sostienen que un actor es un usuario que desea algo del sistema.
Identificar a los Actores
A parte de lo que ya hemos visto, podemos hacernos las siguientes preguntas como ayuda
para identificar a los actores:
− ¿Quién está interesado en un requisito concreto?
− ¿En qué dominios de la organización se usará el sistema?
− ¿Quién será beneficiario de la nueva funcionalidad?
− ¿Quién proporcionará, usará u obtendrá información?
− ¿Quién dará soporte y administrará el sistema?
− ¿Usará el sistema un recurso externo?
− ¿Interaccionará el nuevo sistema con un sistema antiguo?
Los Actores juegan Roles
Para explicar lo siguiente, centrémonos por un momento en el caso en que los actores son
personas.
Un actor puede representar bien el cargo de la persona que usa el sistema, o bien el rol que
esa persona está jugando en el momento de usar el sistema. Realmente no es significativo
cuál de estos modos empleemos para referirnos al término “actor”. Lo verdaderamente
importante es “el objetivo” que cada caso de uso pretende cumplir, ya que nos dice lo que el
sistema va a hacer.
Muchas veces nos encontraremos con que hay roles cuyas competencias se solapan. Por
ejemplo, quizá veamos que el Jefe de Ventas podrá eventualmente actuar como un Comercial,
realizando una venta. En estos casos podremos optar por cualquiera de las siguientes
soluciones:
− Escribir en la cabecera del caso de uso: El actor principal es el Jefe de Ventas o el
Comercial.
− Escribir: El Jefe de Ventas puede jugar también el rol Comercial en este caso de uso. (Si
estamos usando diagramas UML, podremos reflejarlo dibujando una flecha de
generalización que vaya del Jefe de Ventas al Comercial).
− Crear un nuevo rol con un nombre más genérico, por ejemplo “Vendedor”, y hacer que
este sea el actor principal del caso de uso. Escribiremos que el Jefe de Ventas y el
Comercial están jugando el rol “Vendedor” en ese caso de uso. (Nuevamente, en UML,
podremos reflejarlo dibujando una flecha de generalización que vaya desde el Jefe de
Ventas y el Comercial al nuevo rol Vendedor).
Página 8 de 17
Guía Básica de Referencia Sobre Casos de Uso
Ninguna de estas opciones es mejor que la otra. Simplemente debemos escoger aquella que
nos resulte más cómoda de utilizar y creamos que facilita la comprensión a las personas que
vayan a leer nuestros casos de uso (los demás miembros del equipo, el usuario, etc).
La importancia de la frontera o contexto del sistema
Es importante definir la frontera del sistema para distinguir lo que es interno o externo a él, así
como las responsabilidades del sistema. El ambiente externo está representado únicamente
por actores, por lo que la decisión sobre la frontera que se elija para el sistema tendrá
influencias importantes. Por ejemplo, en el sistema de un supermercado, si elegimos como “el
sistema” la tienda entera, el Cajero no sería un actor, ya que se encontraría dentro del
sistema. Sin embargo, si escogemos como sistema el software y hardware del Terminal Punto
de Venta, se entenderían como actores al Cliente y al Cajero.
Página 9 de 17
Guía Básica de Referencia Sobre Casos de Uso
Escribiendo Casos de Uso
¿Qué son los Diagramas de Casos de Uso?
Los diagramas de casos de uso tienen por objeto permitir conocer rápidamente los actores
externos del sistema, y las formas básicas en que lo utilizan.
Un diagrama de casos de uso:
− Explica gráficamente un conjunto de casos de uso, normalmente agrupados por
funcionalidad.
− Representa la relación entre los actores y los casos de uso.
− Describe la interacción de los actores con el sistema.
¿Cómo represento las ramificaciones que puede sufrir un Caso de Uso?
Un caso de uso puede contener puntos de decisión. Por ejemplo, en una compra, el cliente
puede optar por distintas formas de pago (efectivo, tarjeta, cheque, ...) Si una de las
trayectorias de decisión es muy representativa, y las otras son alternativas poco frecuentes, el
caso típico será sobre el que se describa el curso normal, y las otras opciones se describirán
como cursos alternativos.
Pero para los casos en los que todas las opciones son igualmente importantes y de uso
frecuente, podemos seguir la siguiente notación:
1. En la sección principal curso normal se indicarán las ramificaciones.
2. Se creará una subsección por cada ramificación, siguiendo el esquema de descripción
acostumbrado.
3. Si alguna subsección tiene a su vez ramificaciones, se describirán como cursos
alternativos de esa subsección.
Ejemplo:
Acción de los Actores Respuesta del Sistema
1.- .... 2.- ...
3.- El Cliente escoge el tipo de pago:
a) Efectivo (ver subsección “Pago en Efectivo”)
b) Tarjeta (ver subsección “Pago con Tarjeta”)
c) Cheque (ver subsección “Pago con Cheque”)
4.- ...
¿Cuándo debo usar la relación Includes y cuándo la relación Extends?
Includes (Antes llamada “Uses”):
Un caso de uso “incluido” es básicamente un paso del caso de uso base, que decidimos
extraer a parte para mejorar la comprensión, por la importancia que tiene el paso por sí
mismo, o para factorizar comportamiento común que se repite en varios casos de uso.
El caso de uso base conoce cuándo, dónde y por qué debe ejecutarse el caso de uso incluido.
Por tanto, el caso de uso base es quien “inicia”, quien “llama” al caso de uso que incluye.
Página 10 de 17
Guía Básica de Referencia Sobre Casos de Uso
Extends:
Una relación de extensión se utiliza para:
− Modelar las variantes posibles del caso de uso base.
− Modelar la parte de un caso de uso que el usuario puede ver como comportamiento
opcional del sistema. De esta forma, se separa el comportamiento opcional del obligatorio. 
− Modelar un subflujo separado que se ejectua sólo bajo ciertas condiciones. 
− Modelar varios flujos que se pueden insertar en un punto dado, controlados por la
interacción explícita con un actor.
Una relación extends puede reflejar básicamente una extensión (una variante, un curso
alternativo) del caso de uso base, que extraemos para modelarlo como caso de uso a parte. 
El caso de uso base sigue su curso, pero ante determinadas condiciones, su comportamiento
se ve interrumpido con el del caso de uso que lo extiende.
El caso de uso extensión es el que conoce cuándo, dónde y por qué debe incorporar su
comportamiento, extendiendo el caso de uso base. El caso de uso base no nombra al caso de
uso que le extiende. De hecho no sabe nada de él. El caso de uso extensión nombra al caso
de uso base cuando se cumple la condición que lo hace ejecutarse.
Algunos ejemplos del uso de extends:
− Cuando hay varios servicios asíncronos que el usuario puede activar interrumpiendo al
caso de uso base. Por ejemplo, en un procesador de texto, el caso de uso base: “Redactar
documento”, se puede ver interrumpido en cualquier momento si el usuario activa las
acciones: “Poner en negrita”, “Justificar texto”, etc.
− Cuando estamos añadiendo nueva funcionalidad a unos requisitos ya cerrados. Por
ejemplo, de un sistema ya desarrollado que ahora queremos ampliar. En estas situaciones
podemos crear nuevos casos de uso que extiendan a uno base ya cerrado, evitando así
modificarlo directamente. De hecho, se inventó “extends” con el propósito de no tocar
requisitos ya cerrados.
Es preferible mantener la extensión dentro del caso de uso base siempre que sea posible.
Extraeremos las extensiones como casos de uso aparte cuando:
- La extensión se produce en varios sitios (factorizar comportamiento extendido común)
- La explicación de la extensión puede hacer difícil la comprensión del caso de uso
base, por ser larga y/o complicada.
- Queremos ampliar la funcionalidad o comportamiento del caso de uso base, pero sin
modificarlo directamente.
Es aconsejable crear casos de uso extensión sólo cuando sea necesario, ya que son más
difíciles de comprender para la gente, y también más difíciles de mantener.
NOTA: Con extends los actores tienen algo que ver con los casos de uso que se
extienden. Se
supone que un actor dado intervendrá tanto en el caso de uso base, como de todas sus
Página 11 de 17
Guía Básica de Referencia Sobre Casos de Uso
extensiones. Sin embargo, con la relación includes, es frecuente que no haya un actor
asociado con el caso que se incluye.
Página 12 de 17
Guía Básica de Referencia Sobre Casos de Uso
Plantillas de Casos de Uso
Las plantillas permiten describir los casos de uso de una manera homogénea, ordenada y
estructurada, facilitando un formato de documentación común entre distintos miembros de un
equipo de desarrollo, o incluso entre distintos equipos.
Existen numerosas plantillas para documentar casos de uso, pero ninguna de ellas es el
modelo perfecto. En realidad, la plantilla perfecta es aquella que reuna las características de
forma y contenido que más se adecúen a nuestras necesidades.
Como muestra aquí tenemos una que no es ni demasiado extensa ni demasiado escueta, y
que en mi opinión contempla los elementos más importantes para la documentación de casos
de uso.
<ID Caso de Uso>: <Nombre>
Características
Resumen <Breve descripción de lo que hace el Caso de Uso, del objetivo
que logra>
Pre-Condiciones <Lo que debe cumplirse para ejecutar el Caso de Uso>
Post-Condiciones <Lo que debe cumplirse una vez finalizado el Caso de Uso con
éxito>
Actor Principal <Nombre del Rol>: <Descripción del Rol del Actor que está
interactuando con el Sistema>
Actores Secundarios <Aquí podemos incluir, por ejemplo, a los actores de soporte>
Curso Normal (Escenario normal)
Paso Actor Description
<Paso Nº> <Nombre del Actor
implicado>
<Descripción de lo que ocurre en el paso>
Cursos Alternativos y Extensiones del Curso Normal
Paso Variación Descripción
<Paso Nº> <Cuál es la condición
que desencadena la
extensión o variante>
<Descripción de lo que ocurre en la variación o
extensión>
Puntos Abiertos
Punto Descripción
<ID Pto> <Descripción de las dudas o indefiniciones existentes en el Caso de Uso>
Página 13 de 17
Guía Básica de Referencia Sobre Casos de Uso
Consejos y recordatorios importantes
No olvidar la perspectiva del usuario
Recordar que, al identificar y describir los casos de uso, es importante mantener una
perspectiva cercana al usuario.
No perder de vista la frontera del sistema
Es importante definir la frontera del sistema para distinguir lo que es interno o externo a él, así
como sus responsabilidades.
No confundir un paso o transacción individual como un caso de uso en sí
mismo 
Salvo cuando por cuestiones de simplificación y/o ayuda a la comprensión se haga necesario.
Identificar los verdaderos objetivos del usuario
Hay que distinguir los verdaderos objetivos del usuario de las interacciones obvias del usuario
con el sistema. De esta manera podremos siempre descubrir maneras alternativas de resolver
un mismo objetivo.
Evitar una excesiva descomposición
A menudo se invierte mucho esfuerzo en la estructuración de los casos de uso. Es común
tener un caso de uso que contempla bastante lógica, e intentar por todos los medios llegar a
un nivel de granularidad mayor, que consideramos más apropiado. Para ello, tomamos ese
“super caso de uso” y lo descomponemos en varios sub-casos mediante relaciones include o
extends (principalmente includes). A su vez vamos descomponiendo de igual forma cada uno
de esos sub-casos, hasta obtener casos de uso “elementales”. 
Lo que en realidad estaremos haciendo es una “descomposición funcional”, que es
precisamente la antítesis de la orientación a objetos. Además, un excesivo nivel de detalle en
la estructura de casos de uso no es necesario en las fases tempranas del desarrollo, y sin
embargo hacerlo nos costará un tiempo muy útil para otras tareas importantes.
Evitar una excesiva abstracción
Un buen análisis es el que consigue reducir un problema complejo en unas cuantas
abstracciones sencillas, convirtiéndolo en algo manejable. Ese es nuestro objetivo como
analistas. Sin embargo, abstraer excesivamente los casos de uso puede conducirnos a un
punto en el que el usuario tenga dificultades para entender lo que queremos comunicarle, y
eso no hace más que desvirtuar uno de los objetivos principales de los casos de uso: “La
comunicación con el usuario”, además de haber invertido quizá demasiado tiempo en llegar a
ese nivel de abstracción.
No escribir los casos de uso demasiado escuetos
En la descripción de casos de uso es siempre preferible extenderse a quedarse corto. Hemos
de recordar que un caso de uso debe expresar con suficiente claridad las acciones del usuario
y las respuestas del sistema a estas acciones. Evitar un texto excesivamente conciso es
especialmente importante si las descripciones de los casos de uso van a ser aprovechadas
como base para el manual de usuario. Tampoco es conveniente extendernos demasiado,
porque podríamos hacer el documento muy pesado y perder la atención de los lectores.
No omitir los posibles cursos alternativos
Aunque el curso principal de un caso de uso es generalmente más fácil de identificar, eso no
significa que debamos obviar los cursos alternativos que puedan darse, y más cuando estos
reflejen cuestiones importantes. El esfuerzo invertido en los cursos alternativos en una fase
temprana como es la construcción de casos de uso, se verá recompensado a la hora de
codificar, ya que tendremos identificados los problemas potenciales, y resuelta la lógica de su
Página 14 de 17
Guía Básica de Referencia Sobre Casos de Uso
tratamiento. (No hacerlo provocará que el desarrollador decida por sí mismo la solución a
aplicar, casi siempre influido por la facilidad de implementación y no por el modo más
conveniente).
No complicarse la vida decidiendo si usar “includes” o “extends”
La diferencia entre los dos tipos de relaciones de casos de uso a veces resulta tan sutil que no
es fácil decidir cuál de los dos aplicar. El consejo es que no perdamos un mes devanándonos
los sesos con esta cuestión. El tipo de recurso que empleemos no debe preocuparnos tanto
como para congelar nuestro progreso. Es preferible elegir un único mecanismo con el que nos
sintamos confortables, y mantenerlo hasta el final, a tener los dos pero empleados en
situaciones muy parecidas, lo que provocará confusión.
Mantener separadas las cuestiones sobre la Interfaz de Usuario
Debemos asegurarnos de que lo que escribamos refleje únicamente requisitos funcionales del
sistema, no simplemente las acciones del usuario manejando la interfaz de usuario. Para la
descripción de esta, podemos emplear otro documento de casos de uso específico, prototipos
Html, o cualquier otro medio que se nos ocurra. Pero es importante que la descripción de los
requisitos funcionales no vaya vinculada a los requisitos de usabilidad o estética de la interfaz
de usuario. Son aspectos del sistema bien diferenciados que deben tratarse por separado. No
hacerlo puede suponer, entre otras cosas, que el documento se alargue excesivamente y que
se debiliten los requisitos, haciendo que un cambio en la interfaz de usuario implique un
cambio en la funcionalidad.
Página 15 de 17
Guía Básica de Referencia Sobre Casos de Uso
Bibliografía y Enlaces de interés
Bibliografía
− El Lenguaje Unificado de Modelado: Booch, Jacobson, Rumbaugh (Rational Software
Corporation http://www.rational.com/ ) – Editorial Addison Wesley, 1999
− UML y Patrones: Graig Larman – Editorial Prentice Hall, 1999.
− Writing Effective Use Cases: Alistair CockBurn – Editorial Addison Wesley, 2001
− Use and Abuse Cases: Artículo de la columna “Methods in Practice” de Martin Fowler en
la revista “Distributed Computing”.
Disponible en: http://martinfowler.com/articles/abuse.pdf
(Martin Fowler es autor de varios títulos, entre ellos “UML Distiled”).
− Top Ten Use Case Mistakes: White Paper de Febrero de 2001, del sitio web “Software
Development Online”.
Disponible en: http://www.sdmagazine.com/documents/s=815/sdm0102c/
Enlaces de Interés 
− Use Case Zone: http://www.pols.co.uk/usecasezone/
− Sitio
Web de Martin Fowler: http://martinfowler.com/
− Sitio Web de Alistair Cockburn: http://members.aol.com/acockburn/
− VICO (Completo sitio web sobre UML): http://www.vico.org/
− UML Central: http://www.embarcadero.com/support/uml_central.asp#tutorials
Página 16 de 17
Guía Básica de Referencia Sobre Casos de Uso
Agradecimientos
Espero que no os importe que aproveche la ocasión para dedicar esta guía: A todos aquellos
que opinan que para construir software de calidad, es necesario hacer primero algo que con
frecuencia se olvida: Pensar . Primero en lo que hay que hacer, luego en cómo hacerlo, y a
continuación, pero sólo después de lo anterior, traducir lo obtenido a código fuente.
He tenido el privilegio de conocer profesionales que trabajan así, amantes como yo de esta
profesión y de las cosas bien hechas, a los que admiro y respeto profundamente, por los
buenos momentos que hemos pasado juntos y por lo mucho que de ellos aprendí y espero
seguir aprendiendo. Desde aquí les envío un fuerte abrazo y les doy las gracias.
Página 17 de 17