Documentos de Académico
Documentos de Profesional
Documentos de Cultura
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?”.
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 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.
Página 4 de 17
Guía Básica de Referencia Sobre Casos de Uso
− 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.
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?
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
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.
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.
A parte de lo que ya hemos visto, podemos hacernos las siguientes preguntas como ayuda
para identificar a los actores:
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:
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).
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
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:
Ejemplo:
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 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 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.
− 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.
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:
- 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
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.
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>
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
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).
Página 15 de 17
Guía Básica de Referencia Sobre Casos de Uso
Bibliografía
− 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
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