Está en la página 1de 8

Cmo describir Casos de uso?

Casos de Uso

Introduccin
El diagrama de CU nos da una vista grfica del sistema, mostrando qu/quin interacta con el sistema (actores) y cules son sus objetivos al hacerlo (casos de uso). El texto de documentacin de CU nos da la descripcin de estos actores y casos de uso, pudiendo conocer ms sobre quin/qu espera algo del sistema (descripcin de actores) y cmo se comporta el sistema para que ese actor logre el objetivo que desea (descripcin del caso de uso) La parte mas importante es el texto. Mucha gente tiene la idea equivocada que el modelado visual (con el UML) es dibujar unos cuanto monigotes, burbujitas y lneas. Los casos de uso implican escribir texto. Dibujar el modelo es solo una parte del esfuerzo. Por lo general mas del 75% del esfuerzo durante la captura de requerimientos se centra en realizar la descripcin textual de lo que sucede en cada caso de uso. La descripcin de lo que sucede es llamado: flujo de eventos, o tambin curso normal Qu contiene un modelo de Casos de uso? Rta: Diagrama de CU Y documentacin textual del diagrama.

Descripcin del caso de uso


El comportamiento de un caso de uso se puede especificar describiendo un flujo de eventos de forma textual, lo suficientemente claro que lo entienda fcilmente el cliente. Este flujo est compuesto por un flujo bsico (comnmente llamado: curso normal) y flujos alternativos (subflujos o excepciones) del comportamiento. Es importante especificar cmo y cundo se empieza y acaba el caso de uso. Se utilizar una plantilla para describir el CU. A continuacin se especifican las secciones que la componen:

Precondiciones
Antes de comenzar a describir el curso normal se deben indicar qu precondiciones son necesarias para que se intancie el CU (es decir para que se pueda iniciar el CU) Se expresa de manera tal que no exista ningn tipo de ambigedad y que permita objetivamente su comprobacin. Las condiciones deben ser encerradas entre corchetes, y se unen mediante algn operador lgico en caso de que existiera ms de una condicin. Una expresin lgica es una expresin que al ser evaluada puede dar como resultado, nicamente, verdadero o falso. La sintaxis que deber emplearse consistir en una Profesores: Gustavo J. Sabio/ Fernando Pinciroli Pgina 1 de 8

Cmo describir Casos de uso?

Casos de Uso

cadena de condiciones atmicas encerradas entre corchetes unidas con operadores lgicos (expresados mediante las etiquetas AND, OR, XOR), debiendo comenzar cada rengln con el operador lgico. Se debern utilizar tambin los corchetes para romper la precedencia de clculo normal de estos operadores; por ejemplo: [[cond1] OR [cond2]] AND [cond3]. En trminos generales, se podr plantear una condicin tan compleja como sea necesario, en la medida en que se respete la sintaxis de una expresin lgica.

Curso Normal
El curso normal se describe mediante la creacin de pasos que permitan contar la interaccin que se produce entre los actores y el sistema.

Pasos
Es aconsejable que cada paso se redacte en forma de script, esto es, una oracin estructurada constituida por varias partes que, en conjunto, conforman una actividad. Las partes que componen a un script son: <Iniciador>, generalmente un actor que se obtiene mediante la pregunta "Quin o qu...?" <Accin>, que realiza el actor <colaborador>, sobre quin o sobre qu cosa se realiza la accin [servicio], es opcional e indica la accin de respuesta del colaborador. Cada paso debe tener asociado un nmero positivo que se incrementa de uno en uno a partir de la unidad.

Pasos Concurrentes
Cuando dos o ms pasos se pueden realizar en un orden indistinto o en paralelo, estamos en presencia de "pasos concurrentes". Cada una de las ramas concurrentes se deber distinguir mediante el agregado de una letra en letra minscula, comenzando desde la letra a hasta la z. De esta manera, suponiendo que en un caso de uso los pasos nmero 3 y 4 pudieran ser intercambiados sin afectar su ejecucin lgica, y adems se considere til o necesario dejar constancia expresa de esta situacin, por el hecho de ser concurrentes ambos pasos tendrn la misma numeracin, pero distinguiendo cada rama por medio de la letra recin mencionada. As, los pasos 3 y 4 pasarn a ser 3a y 3b respectivamente. Desde el punto de vista semntico, esta notacin est reflejando concurrencia entre esos dos pasos, pero ambos deben completarse satisfactoriamente antes de pasar al paso siguiente (el ahora paso 4 que antes corresponda al 5). Grficamente esta situacin se representa por medio de las barras de sincronizacin. Por otra parte, cada una de las ramas puede contener ms de un paso, para lo que deber agregarse, luego de la letra y separada por el correspondiente punto de la numeracin decimal, un nuevo dgito que se incrementar de uno en uno a partir de la unidad. En definitiva, los nmeros siempre indicarn secuencia y las letras indicarn ramas concurrentes. A continuacin podemos ver un ejemplo grfico de lo dicho hasta el momento: Profesores: Gustavo J. Sabio/ Fernando Pinciroli Pgina 2 de 8

Cmo describir Casos de uso?

Casos de Uso

Nota: Como puede observarse en la figura del diagrama de actividades, en caso de no contar con ms de un paso por rama, no es necesario numerar la secuencia (3a).

Paso condicional
El paso condicional es un caso particular del subflujo (ver "subflujo" en el apartado "Curso Alternativo") basado en la premisa de lograr un curso normal muy claro y auto contenido (con la menor cantidad de referencias posibles). Un paso condicional es un subflujo que cuenta con un nico paso. Para esto en el curso normal se debe indicar como sigue: N de paso. SI [expresin lgica] <paso> SINO <paso> Ejemplo: SI [se encuentra habilitado] el Bibliotecario otorga el prstamo

Relacin incluir
Tal como establece el estndar UML, la asociacin de dependencia estereotipada con incluir se emplea para evitar describir el mismo flujo de eventos repetidas veces, aportando un mecanismo de factorizacin que permite ubicar comportamiento comn en un nico caso de uso aparte que ser compartido por todos aquellos casos de uso en los que originalmente se encontraba expresada la porcin de pasos comn. Semnticamente se debe interpretar que el caso de uso base "incluye" la funcionalidad expresada en el caso de uso comn (por esa razn la flecha de la asociacin de dependencia apunta al caso de uso comn, puesto que el caso de uso base "depende" del aqul porque necesita su funcionalidad para poder completarse). La relacin de inclusin se expresa en un paso con el estereotipo incluir ms el nombre del caso de uso comn (o factorizado) entre parntesis, en lugar del paso o de los pasos que fueron factorizados. Esta llamada genera el mismo efecto que insertar todo el caso de uso factorizado en el punto de inclusin indicado de esa manera. Las asociaciones de extensin, que complementan al concepto de inclusin, se tratarn dentro del apartado "Curso Alternativo". En algunas oportunidades, la complejidad inherente de la realidad que se estar tratando de modelar podra obligar al empleo de etiquetas que indican un cambio en la secuencia normal de ejecucin del caso de uso. Estas etiquetas contendrn el nmero del paso del curso normal con el que se debe continuar. Este recurso debera ser utilizado exclusivamente en aquellas circunstancias en las que esta fuera la manera ms clara de interpretar el desarrollo del caso de uso, pero sin dudas deber ser utilizado en circunstancias excepcionales. Las etiquetas, de acuerdo a lo establecido por el UML, son valores encerrados entre llaves. En nuestro caso, el valor ser el prefijo cn (curso normal) seguido por el nmero de la secuencia del paso en la que debe continuar la ejecucin del caso de uso; por ejemplo {cn1}.

Reglas de Negocio
Las reglas de negocio que establecen las condiciones de xito de paso en cuestin sern enumeradas y colocadas entre corchetes (debido a que son condiciones, y en UML todas las condiciones deben ir entre corchetes). En el caso de que se debiera cumplir con un Profesores: Gustavo J. Sabio/ Fernando Pinciroli Pgina 3 de 8

Cmo describir Casos de uso?

Casos de Uso

conjunto de reglas de negocios, debern separarse con los operadores lgicos AND, OR o XOR, sin necesidad de utilizar ningn tipo de narracin del tipo debe cumplir con. El conjunto de reglas de negocios deber ir en rengln nuevo y con un rengln en blanco que lo separe de la descripcin del paso. Cada regla de negocios se incluir expresando su cdigo entre corchetes. El cdigo de las reglas de negocio deber estar formado el prefijo "rn" ms un nmero de cuatro cifras y precedido por los cdigos de la jerarqua de paquetes que las contienen separados por un guin medio. En caso de que una regla de negocio se encuentre en ms de un paquete, deber tomarse como nombre completo aqul que haga referencia al paquete en el que se defini en el sistema. El tratamiento para la numeracin es igual que para los casos de uso. En caso de que sea necesario disparar un curso alternativo por no haberse cumplido una regla de negocio, se deber atender la situacin de acuerdo a lo establecido para la ejecucin de una excepcin.

Curso alternativo
La naturaleza propia de la mayora de los procesos reales involucra condiciones que llevan a tomar diferentes cursos de accin, y expresar el desarrollo de un comportamiento incluyendo todas las alternativas posibles hara imposible la lectura del caso de uso. Dentro de estos pasos condicionales o cursos alternativos, encontramos dos tipos diferentes de pasos alternativos que, por su naturaleza, corresponden a dos situaciones diferentes que hemos decidido denominar:
? ?

Subflujo (que se identificar con el prefijo "sf") Excepcin (que se identificar con el prefijo "ex")

Una excepcin se utiliza para describir funcionalidades indeseadas o excepcionales de un paso a causa de una condicin no cumplida. Un subflujo se utiliza para expresar caminos alternativos de un paso en donde cada uno de los cursos de accin no es una excepcin del otro, sino que todos tienen igualdad de importancia y son parte del camino normal. De esta manera, las excepciones se deben documentar fuera del curso normal, mientras que los subflujos se deben documentar dentro del curso normal del caso de uso.

Subflujos
Cuando en un paso se debe tomar un curso de accin en funcin de una condicin por la naturaleza propia del mismo problema o negocio, pero en donde las acciones no son excepcionales, estos cursos alternativos sern identificados como subflujos. La condicin de la que surgen los subfljuos se expresa como un paso en el curso normal, y los subflujos continan como pasos sucesivos. Por ejemplo, en el caso de uso Contratar Empleado podra contratarse a una persona de otra empresa (curso normal ya que es el escenario mas frecuente), podra transferirse una persona de un departamento a otro (algo frecuente en ciertas compaas) o podra contratarse a un extranjero (conlleva sus reglas especficas). Estas dos ltimas variantes o alternativas pueden expresarse como subflujos del curso normal. El subflujo se representar con un cdigo entre parntesis en el curso normal anteponiendo el prefijo sf al nmero de paso en el que se encuentra la llamada, ms Profesores: Gustavo J. Sabio/ Fernando Pinciroli Pgina 4 de 8

Cmo describir Casos de uso?

Casos de Uso

un punto seguido por un nmero entero positivo que se incrementar de uno en uno comenzando con la unidad; por ejemplo (sf3.1). Debido a que los subflujos se ejecutan a partir de una condicin en el curso normal, sta se indicar como un paso condicional de la siguiente manera: N Paso SI [expresin lgica] {subflujo} SINO {subflujo} Ejemplo: 4 - SI [es extranjero] {sf1} SINO {sf2} La etiqueta SI y SINO debern ir siempre en letra mayscula. El empleo del SINO es opcional.

Relacin condicional
En los subflujos podran aparecer nuevos actores, pero su participacin est supeditada a que la condicin que implica la ejecucin del subflujo tenga un resultado "verdadero". De esta manera, el actor no estara participando siempre en el caso de uso, sino a veces o quizs nunca. Dentro de esta descripcin textual del caso de uso es necesario contar con un elemento que permita dejar en claro esta situacin, por lo que al actor que participe en estas circunstancias se lo acompaar del estereotipo condicional, que significar que es un actor que aparece en un subflujo. Grficamente es posible representar esta situacin mediante el empleo de condicionalidad 0 en la multiplicidad de la asociacin entre el actor en cuestin y el caso de uso, pero esta solucin estara obligando a especificar la multiplicidad en todas las asociaciones de todos los diagramas a fin de tener uniformidad de criterios, puesto que el no especificar multiplicidad en UML significa una multiplicidad 1:* por omisin. As, quedan dos alternativas posibles: o se expresa la multiplicidad en todas las asociaciones de todos los diagramas de casos de uso, y para estos actores de los subflujos se indica condicionalidad 0, o no se expresa multiplicidad en ninguna asociacin y se indica la situacin que estamos considerando con la incorporacin del estereotipo condicional en la asociacin de los actores de los subflujos.

Relacin extender
Cuando una condicin en el curso normal de un caso de uso "A" implica la ejecucin de un conjunto de pasos que se llevan a cabo en forma excepcional o que corresponden al tratamiento de un error, estos pasos excepcionales se deben agrupar y modelar como un nuevo caso de uso caso de uso "B". De esta manera, el caso de uso base "A" ser extendido por el caso de uso excepcional "B". Entre los casos de uso "A" y "B" existir una asociacin de dependencia estereotipada como extender, lo que significa que la funcionalidad del caso de uso "B" "extiende" la funcionalidad del caso de uso "A" en tanto y en cuanto en el caso de uso "A" se cumpla la condicin que implica la ejecucin del caso de uso "B". Y la asociacin de dependencia debe apuntar al camino base (contrariamente a lo que sucede en la asociacin de inclusin) debido a que el caso de uso "B" depende de que se cumpla con una condicin en "A" para poder llevarse a cabo. Como se puede observar, la funcionalidad que estamos modelando con una asociacin de extensin podra modelarse perfectamente tambin como un subflujo, por lo que se ha decidido establecer las siguientes reglas prcticas: un subflujo es, conceptualmente, diferente a una excepcin, por lo que su tratamiento debera ser diferente: los subflujos son parte del camino base y las excepciones son tales, como su nombre lo indica

Profesores:

Gustavo J. Sabio/ Fernando Pinciroli

Pgina 5 de 8

Cmo describir Casos de uso?

Casos de Uso

la funcionalidad de las excepciones debera tratarse como un caso de uso que extiende al caso de uso base, pero en algunas oportunidades esta funcionalidad excepcional es tan pequea (en cuanto al nmero de pasos) que no sera conveniente, desde un punto de vista meramente prctico, destinar un caso de uso entero a esa pequea porcin de funcionalidad, describindose, entonces, en la seccin destinada a los subfujos dentro del documento que contiene la descripcin del caso de uso base este criterio prctico ser adoptado siempre que la excepcin cuente con ms de 10 pasos o que la excepcin posea nuevas excepciones

Es importante aclarar que las condiciones anteriores no representan una regla absoluta y automtica ya que si el subflujo cumple con una o dos de las condiciones anteriores y el subflujo no puede considerarse, por el nivel de abstraccin y criterio personal, un nuevo caso de uso extendido, puede dejarse como subflujo. En conclusin, estas reglas son para contar con un disparador que nos ponga en alerta de una posible relacin de extensin. En caso de requerir, bajo las condiciones anteriormente indicadas, generar una relacin de extensin debe consignarse en el curso normal con la siguiente sintaxis: N de paso. SI [expresin lgica] (cdigo de caso de uso) SINO (cdigo de caso de uso) Ejemplo: SI [el usuario est inhabilitado] (cu0039) Asimismo en la seccin destinada a los Subflujos, stos debern ordenarse de manera creciente por nmero de paso del curso normal y nmero de subflujo mediante el siguiente esquema: Cdigo de Subflujo N de paso

Nombre del Subflujo Paso (representado a travs de un script)

Un subflujo cuenta con la posibilidad de soportar excepciones indicndolas con el cdigo utilizado para cualquier paso de un curso normal. Por ejemplo, {ex.sf.12.4} sera la cuarta excepcin del subflujo llamado en el paso 12 del curso normal.

Excepciones
Una excepcin es un curso alternativo que puede preverse pero no controlarse para ser evitado y que puede alterar el desarrollo del paso del curso normal. En general responde a situaciones no deseadas que alteran el curso normal. Todos los pasos de un curso normal pueden realizarse con o sin xito. En alguno de ellos es importante establecer las condiciones que determinan el xito y en otros no. En aquellos pasos en donde es importante determinar la condicin de xito, cuando la ejecucin del paso no fue exitosa debera indicarse la secuencia de pasos excepcionales que se deberan llevar a cabo como consecuencia del fracaso en la ejecucin del paso del curso normal. En estos pasos los cursos alternativos que se generen se encontraran originados por un desempeo anormal de una actividad o paso y no como un flujo alternativo propio de la naturaleza del problema. As, debern enumerarse, separados por punto y coma, las diferentes excepciones que pueden presentarse en el desarrollo normal del paso, a continuacin de l, entre llaves Profesores: Gustavo J. Sabio/ Fernando Pinciroli Pgina 6 de 8

Cmo describir Casos de uso?

Casos de Uso

y en un rengln nuevo. Las excepciones se deben identificar mediante un cdigo de excepcin compuesto por el prefijo ex y seguido por el nmero del paso que produjo la excepcin, ms un punto seguido por un nmero entero positivo que se incrementar de uno en uno a partir de la unidad. Por ejemplo, ex12.3 identifica a la tercera excepcin que puede presentarse en el paso nmero 12 del curso normal. En la plantilla, el curso normal se vera de la siguiente forma: 12 <paso> {ex12.1;ex12.2;ex12.3} Siguiendo con el ejemplo, para poder continuar con el paso siguiente (paso 13), debern haberse evaluado cada una de las excepciones posibles. Las excepciones debern ser ordenadas por nmero de paso y excepcin, de menor a mayor y ser ubicadas dentro de la seccin etiquetada como Excepciones de la plantilla: Cdigode Excepcin N de paso SI [condicin] Paso (representado a travs de un Script)

Cada excepcin ser documentada con el cdigo, la condicin de excepcin (entre corchetes) y luego con idnticas caractersticas que un curso normal: ex12.1 SI [el usuario no existe] 1 <paso> 2 <paso>

Consideraciones de diseo
nicamente sern tomadas como consideraciones de diseo aquellas que sean sugerencias, mientras que las consideraciones de diseo que sean obligatorias debern ser documentadas como requerimiento funcional. Para indicar que existe una consideracin de diseo basta con colocar el cdigo entre parntesis, compuesto por el prefijo cd ms el nmero de paso en el que se encuentra la llamada y ms un punto seguido por un nmero entero positivo que se incrementar de uno en uno a partir de la unidad; por ejemplo (cd5.3). En la seccin de "Consideraciones de Diseo" se debern ordenar de manera creciente por nmero de paso y nmero de consideracin de diseo: Cdigo de Consideracin de Nombre de la Consideracin de Diseo Diseo Narracin de la consideracin de diseo

Diagramas y documentacin anexa


Adicionalmente a toda la descripcin textual del caso de uso, es conveniente adjuntar los diagramas necesarios que permitan complementar el modelado del proceso general. Los diagramas de actividad, de interaccin o de estados son herramientas adecuadas para tal fin. Tambin podra existir otra documentacin anexa de utilidad a los efectos de ampliar la informacin y mejorar la compresin del requerimiento que se est modelando. Para estos casos est prevista la siguiente seccin: Profesores: Gustavo J. Sabio/ Fernando Pinciroli Pgina 7 de 8

Cmo describir Casos de uso?

Casos de Uso

Numero de paso

Paso al que referencia

(documento/diagrama)

Nombre

(Diagrama de Actividad, Instructivo, etc.)

Tipo

(incluir extensin: .doc, .mdl, etc)

Nombre/Lugar

Observaciones
Esta seccin permite agregar los comentarios tiles no contemplados en las otras secciones de la plantilla y las observaciones temporales necesarias. Nmero de Paso Paso al que referencia Observacin

Cuando existe una observacin o comentario sobre un paso de un subflujo, el cdigo de la observacin debe constituirse anteponiendo el propio cdigo de la observacin ms el correspondiente al subflujo. Por ejemplo: Subflujo sf3.1 Este es un subflujo ejemplo 1 <paso> {ob1-sf3.1.2} Observacin ob1-sf3.1.2 Comentario El cdigo se debe leerse como la primera observacin del paso 2 del subflujo 1 del tercer paso del curso normal.

Consideraciones importantes
Todas las referencias debern ser escritas al final del paso a fin de facilitar su lectura y la rpida identificacin de las referencias, en un rengln nuevo cada categora de referencia, dejando una lnea en blanco luego de la descripcin del paso y en el siguiente orden: 12455Ejemplo: <paso> {rn-0020} {ex3.1 ; ex3.2} {ob3.1} Reglas de negocios Excepciones Consideraciones de Diseo Diagramas y documentacin anexa Observaciones

Profesores:

Gustavo J. Sabio/ Fernando Pinciroli

Pgina 8 de 8