Gua Bsica de Referencia Sobre

Casos de Uso

Oscar Canalejo Castrillero - 2003

Gua Bsica de Referencia Sobre Casos de Uso

Contenido
Introduccin.......................................................................................................................................3 Qu contiene esta gua? A quin 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 identificacin 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 Cmo represento las ramificaciones que puede sufrir un Caso de Uso?................................9 Cundo debo usar la relacin Includes y cundo la relacin 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 transaccin individual como un caso de uso en s mismo ...............13 Identificar los verdaderos objetivos del usuario..........................................................................13 Evitar una excesiva descomposicin...........................................................................................13 Evitar una excesiva abstraccin...................................................................................................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 Bibliografa y Enlaces de inters.................................................................................................15 Bibliografa.....................................................................................................................................15 Enlaces de Inters .......................................................................................................................15 Agradecimientos.............................................................................................................................16

Pgina 2 de 17

Gua Bsica de Referencia Sobre Casos de Uso

Introduccin
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 presentacin, ste interrumpe frecuentemente un tanto mosqueado: Por qu cuando hago esto el sistema no aplica la regla de negocio correspondiente?, Por qu no habis incluido aquella opcin que os dije que era muy importante?, Por qu esa pantalla presenta esos datos en lugar de los que realmente necesito?. La captura y documentacin de requisitos es una de las tareas ms importantes en el desarrollo de aplicaciones informticas. Puede que sea incluso la ms importante de todas, puesto que de una adecuada comprensin de los requisitos del sistema depende en gran parte el xito o fracaso del proyecto. Quiz nuestro sistema sea el ms veloz, el que mejor aprovecha los recursos, el que menos incidencias reportar, el que est diseado y programado con la mayor elegancia y haciendo uso de las ltimas tecnologas. Pero si no hace lo que el usuario realmente necesita, habremos fracasado estrepitosamente.

Qu contiene esta gua? A quin va dirigida?

Ya hace algn tiempo que empec a tomar notas y recoger conclusiones personales sobre la capura de requisitos mediante casos de uso, fruto de largas charlas con compaeros, de varios artculos sobre el tema y de algunos libros sobre anlisis y diseo de software. Mi intencin era elaborar una especie de gua de referencia para tenerla siempre a mano, que recogiese en pocas pginas las cuestiones principales sobre casos de uso. Cuestiones que deba recordar al comienzo de un nuevo proyecto o en la revisin de uno ya desarrollado anteriormente. Por tanto este documento no ambiciona ser un manual o un gran tutorial, con ejemplos prcticos y extensas explicaciones. No es ni ms ni menos que un resumen, una gua bsica de referencia sobre casos de uso. Algo que pueda servirnos para, con un rpido vistazo, repasar y no perder de vista las cuestiones fundamentales sobre el tema. Estas pginas estn 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 Anlisis y Diseo de software y ms concretamente en las fases tempranas del anlisis, donde intervienen las tareas de captura y documentacin de las funcionalidades del sistema, y la necesidad de investigar aquello que el sistema debe hacer antes de investigar cmo debe hacerlo.

Pgina 3 de 17

Gua Bsica de Referencia Sobre Casos de Uso

Los Casos de Uso

Qu son los Casos de Uso?
Los casos de uso son casos de utilizacin del sistema, descripciones narrativas de su comportamiento, gracias a las cuales podemos mejorar la comprensin 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 implementacin), y por tanto lo involucran en la revisin y validacin de los mismos. Su lenguaje es igualmente comprensible y til para los miembros el equipo de desarrollo. Descubren posibles reas de colaboracin del negocio. Permiten separar los procesos del negocio en reas funcionales. Ayudan a identificar posibilidades de reutilizacin. 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 diseo detallado, ...). Gracias a ellos podemos identificar y mostrar el impacto que tendrn los cambios de requisitos funcionales sobre la implementacin, o el impacto de los cambios de implementacin sobre la funcionalidad del sistema. Sirven como base para el plan de pruebas del sistema. Para la elaboracin 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 mtodos distintos para identificar los casos de uso: Identificacin basada en los actores: 1: Se identifican los actores.

Pgina 4 de 17

Gua Bsica de Referencia Sobre Casos de Uso

2: Averiguamos qu procesos inician o en cules participan: Cules son sus responsabilidades, Crear/Modificar/Eliminar elementos, Mantenimiento/Soporte del sistema?. de qu tareas se Introducir/Obtener encargan: datos,

Debern informar al sistema sobre algn 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 algn evento que se produzca (ej.: Error en la ejecucin de un proceso desatendido)?. Necesitan indicar al sistema que efecte algn proceso concreto en un momento determinado (ej.: Realizar una copia de seguridad de los datos del perodo)?. Otros procesos en los que los actores participen como estimuladores del sistema, como receptores de informacin procedente del sistema, o como colaboradores del mismo en la ejecucin de tareas.

Identificacin basada en los eventos: 1: Se identifican los eventos ante los que el Sistema debe reaccionar. Creacin/Modificacin/Eliminacin de elementos. Entrada/Solicitud de datos por parte de algn actor. Orden de ejecucin de algn proceso. Notificaciones sobre eventos externos al sistema (p.ej.: El paso del tiempo). Es necesario que algn 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 identificacin 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 comn en la identificacin de casos de uso, es representar los pasos, las operaciones o las transacciones individuales, como casos de uso. Por ejemplo: Imprimir Factura sera un caso de uso errneo, puesto que en realidad se trata de un paso u operacin del caso de uso Comprar Producto/Servicio. No obstante hay ocasiones en las que un paso o transaccin de un caso de uso merece ser representado como un caso de uso aparte (Lo veremos ms 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.

Pgina 5 de 17

Gua Bsica 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 interaccin con el sistema, quiz recurriremos a la opcin obvia para la solucin, pasando por alto otras maneras posiblemente ms efectivas de cumplir con los objetivos del usuario.

Pgina 6 de 17

Gua Bsica 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 inters personal en el comportamiento del caso de uso, incluso si nunca interacta directamente con el sistema. Ejemplos de este tipo de actores seran: El dueo del sistema, el departamento de procesos de la compaa, etc. Prestar atencin 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 tambin mostrar cmo 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 envindole un mensaje, pulsando un botn, 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 telefnico o un dependiente de una tienda inician el caso de uso ante una peticin 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 despus, 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, basndonos 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. Tambin es cierto que sobre la conveniencia de identificar como actor a un sistema externo, hay diferentes opiniones entre los gurs 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@ cul te parece mejor:

Pgina 7 de 17

Gua Bsica de Referencia Sobre Casos de Uso

Todas las interacciones con sistemas externos deben aparecer en el diagrama de casos de uso. Slo se deben mostrar los sistemas externos como actores, cuando ellos sean los que inicien el caso de uso. Slo 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. Paradjicamente, 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: Quin est interesado en un requisito concreto? En qu dominios de la organizacin se usar el sistema? Quin ser beneficiario de la nueva funcionalidad? Quin proporcionar, usar u obtendr informacin? Quin 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, centrmonos 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 cul de estos modos empleemos para referirnos al trmino 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 tambin el rol Comercial en este caso de uso. (Si estamos usando diagramas UML, podremos reflejarlo dibujando una flecha de generalizacin que vaya del Jefe de Ventas al Comercial). Crear un nuevo rol con un nombre ms genrico, por ejemplo Vendedor, y hacer que este sea el actor principal del caso de uso. Escribiremos que el Jefe de Ventas y el Comercial estn jugando el rol Vendedor en ese caso de uso. (Nuevamente, en UML, podremos reflejarlo dibujando una flecha de generalizacin que vaya desde el Jefe de Ventas y el Comercial al nuevo rol Vendedor).

Pgina 8 de 17

Gua Bsica de Referencia Sobre Casos de Uso

Ninguna de estas opciones es mejor que la otra. Simplemente debemos escoger aquella que nos resulte ms cmoda de utilizar y creamos que facilita la comprensin a las personas que vayan a leer nuestros casos de uso (los dems 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 decisin 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 sera un actor, ya que se encontrara dentro del sistema. Sin embargo, si escogemos como sistema el software y hardware del Terminal Punto de Venta, se entenderan como actores al Cliente y al Cajero.

Pgina 9 de 17

Gua Bsica 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 rpidamente los actores externos del sistema, y las formas bsicas en que lo utilizan. Un diagrama de casos de uso: Explica grficamente un conjunto de casos de uso, normalmente agrupados por funcionalidad. Representa la relacin entre los actores y los casos de uso. Describe la interaccin de los actores con el sistema.

Cmo represento las ramificaciones que puede sufrir un Caso de Uso?

Un caso de uso puede contener puntos de decisin. Por ejemplo, en una compra, el cliente puede optar por distintas formas de pago (efectivo, tarjeta, cheque, ...) Si una de las trayectorias de decisin es muy representativa, y las otras son alternativas poco frecuentes, el caso tpico ser sobre el que se describa el curso normal, y las otras opciones se describirn como cursos alternativos. Pero para los casos en los que todas las opciones son igualmente importantes y de uso frecuente, podemos seguir la siguiente notacin: 1. En la seccin principal curso normal se indicarn las ramificaciones. 2. Se crear una subseccin por cada ramificacin, siguiendo el esquema de descripcin acostumbrado. 3. Si alguna subseccin tiene a su vez ramificaciones, se describirn como cursos alternativos de esa subseccin. Ejemplo: Accin de los Actores 1.- .... 3.- El Cliente escoge el tipo de pago: a) Efectivo (ver subseccin Pago en Efectivo) b) Tarjeta (ver subseccin Pago con Tarjeta) c) Cheque (ver subseccin Pago con Cheque) Respuesta del Sistema 2.- ... 4.- ...

Cundo debo usar la relacin Includes y cundo la relacin Extends?

Includes (Antes llamada Uses): Un caso de uso incluido es bsicamente un paso del caso de uso base, que decidimos extraer a parte para mejorar la comprensin, por la importancia que tiene el paso por s mismo, o para factorizar comportamiento comn que se repite en varios casos de uso. El caso de uso base conoce cundo, dnde 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.

Pgina 10 de 17

Gua Bsica de Referencia Sobre Casos de Uso

Extends: Una relacin de extensin 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 slo bajo ciertas condiciones. Modelar varios flujos que se pueden insertar en un punto dado, controlados por la interaccin explcita con un actor.

Una relacin extends puede reflejar bsicamente una extensin (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 extensin es el que conoce cundo, dnde 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 extensin nombra al caso de uso base cuando se cumple la condicin que lo hace ejecutarse. Algunos ejemplos del uso de extends: Cuando hay varios servicios asncronos 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 aadiendo 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 propsito de no tocar requisitos ya cerrados.

Es preferible mantener la extensin dentro del caso de uso base siempre que sea posible. Extraeremos las extensiones como casos de uso aparte cuando: La extensin se produce en varios sitios (factorizar comportamiento extendido comn) La explicacin de la extensin puede hacer difcil la comprensin 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 extensin slo cuando sea necesario, ya que son ms difciles de comprender para la gente, y tambin ms difciles 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

Pgina 11 de 17

Gua Bsica de Referencia Sobre Casos de Uso

extensiones. Sin embargo, con la relacin includes, es frecuente que no haya un actor asociado con el caso que se incluye.

Pgina 12 de 17

Gua Bsica de Referencia Sobre Casos de Uso

Plantillas de Casos de Uso

Las plantillas permiten describir los casos de uso de una manera homognea, ordenada y estructurada, facilitando un formato de documentacin comn 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 caractersticas de forma y contenido que ms se adecen a nuestras necesidades. Como muestra aqu tenemos una que no es ni demasiado extensa ni demasiado escueta, y que en mi opinin contempla los elementos ms importantes para la documentacin de casos de uso.

<ID Caso de Uso>: <Nombre>

Caractersticas
Resumen Pre-Condiciones Post-Condiciones Actor Principal Actores Secundarios
<Breve descripcin de lo que hace el Caso de Uso, del objetivo que logra> <Lo que debe cumplirse para ejecutar el Caso de Uso> <Lo que debe cumplirse una vez finalizado el Caso de Uso con xito> <Nombre del Rol>: <Descripcin del Rol del Actor que est interactuando con el Sistema> <Aqu podemos incluir, por ejemplo, a los actores de soporte>

Curso Normal (Escenario normal)

Paso
<Paso N>

Actor
<Nombre del Actor implicado>

Description
<Descripcin de lo que ocurre en el paso>

Cursos Alternativos y Extensiones del Curso Normal

Paso
<Paso N>

Variacin
<Cul es la condicin que desencadena la extensin o variante>

Descripcin
<Descripcin de lo que ocurre en la variacin o extensin>

Puntos Abiertos
Punto
<ID Pto>

Descripcin
<Descripcin de las dudas o indefiniciones existentes en el Caso de Uso>

Pgina 13 de 17

Gua Bsica 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 transaccin individual como un caso de uso en s mismo

Salvo cuando por cuestiones de simplificacin y/o ayuda a la comprensin 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 descomposicin

A menudo se invierte mucho esfuerzo en la estructuracin de los casos de uso. Es comn tener un caso de uso que contempla bastante lgica, e intentar por todos los medios llegar a un nivel de granularidad mayor, que consideramos ms 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 descomposicin funcional, que es precisamente la anttesis de la orientacin a objetos. Adems, 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 abstraccin

Un buen anlisis es el que consigue reducir un problema complejo en unas cuantas abstracciones sencillas, convirtindolo 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 ms que desvirtuar uno de los objetivos principales de los casos de uso: La comunicacin con el usuario, adems de haber invertido quiz demasiado tiempo en llegar a ese nivel de abstraccin.

No escribir los casos de uso demasiado escuetos

En la descripcin 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 podramos hacer el documento muy pesado y perder la atencin de los lectores.

No omitir los posibles cursos alternativos

Aunque el curso principal de un caso de uso es generalmente ms fcil de identificar, eso no significa que debamos obviar los cursos alternativos que puedan darse, y ms cuando estos reflejen cuestiones importantes. El esfuerzo invertido en los cursos alternativos en una fase temprana como es la construccin de casos de uso, se ver recompensado a la hora de codificar, ya que tendremos identificados los problemas potenciales, y resuelta la lgica de su

Pgina 14 de 17

Gua Bsica de Referencia Sobre Casos de Uso

tratamiento. (No hacerlo provocar que el desarrollador decida por s mismo la solucin a aplicar, casi siempre influido por la facilidad de implementacin y no por el modo ms 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 fcil decidir cul de los dos aplicar. El consejo es que no perdamos un mes devanndonos los sesos con esta cuestin. 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 confusin.

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 descripcin de esta, podemos emplear otro documento de casos de uso especfico, prototipos Html, o cualquier otro medio que se nos ocurra. Pero es importante que la descripcin de los requisitos funcionales no vaya vinculada a los requisitos de usabilidad o esttica 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.

Pgina 15 de 17

Gua Bsica de Referencia Sobre Casos de Uso

Bibliografa y Enlaces de inters

Bibliografa
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: Artculo 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 ttulos, 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 Inters
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

Pgina 16 de 17

Gua Bsica de Referencia Sobre Casos de Uso

Agradecimientos
Espero que no os importe que aproveche la ocasin para dedicar esta gua: 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 cmo hacerlo, y a continuacin, pero slo despus de lo anterior, traducir lo obtenido a cdigo fuente. He tenido el privilegio de conocer profesionales que trabajan as, amantes como yo de esta profesin 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 envo un fuerte abrazo y les doy las gracias.

Pgina 17 de 17