Deteccin de Relaciones entre Casos de Uso

Natalia Dimu, Alejandro J. Friss de Kereki y Andrs Vignaga Universidad de la Repbica, Facultad de Ingeniera, Instituto de Computacin Montevideo, Uruguay {natandi,ajkereki}@adinet.com.uy y avignaga@fing.edu.uy
RESUMEN En el rea de Ingeniera de Software, la aparicin del concepto de caso de uso introdujo una nueva forma de estudiar las funcionalidades de un sistema. Diferentes propuestas metodolgicas incorporaron este enfoque sustituyendo el anlisis de requerimientos tradicional por el anlisis de casos de uso, por tener en un principio objetivos similares. El enfoque basado en casos de uso va ms all de la comprensin de los requerimientos y condiciona el proceso de desarrollo. En este contexto, descubrir relaciones de uso y extensin entre casos de uso es fundamental. En este trabajo se presenta una tcnica que vincula la definicin de requerimientos funcionales con la de los casos de uso con el objetivo de detectar en una etapa temprana del desarrollo las relaciones entre ellos. Palabras claves: Ingeniera de Software, Programacin Orientada a Objetos, Caso de Uso, Requerimiento Funcional

ABSTRACT The introduction of the idea of use case to the field of Software Engineering has made possible to approach the study of the system functionality from a new perspective. Proposed techniques have substituted the traditional requirements analysis for the use cases analysis, since they share, in principle, similar goals. An approach based on use cases goes beyond the understanding of functionality and drives the development process. In this context, detecting use and extend relationships among use cases is crucial. In this work, we introduce a technique that links the definition of functional requirements with that of use cases, allowing relationships between them to be detected in an early stage of the developing process. Keywords: Software Engineering, Object Oriented Programming, Use Case, Functional Requirement

INTRODUCCIN

Desde la aparicin del concepto de caso de uso [3], surgieron diferentes propuestas metodolgicas que incorporaron esta tcnica no solo para captar los requerimientos de los usuarios, sino tambin para guiar el desarrollo del producto de software. Los procesos de desarrollo utilizan los casos de uso como una forma de capturar las funcionalidades del sistema. En algunos casos este es el nico mecanismo empleado, aunque tambin existen propuestas que combinan el anlisis de casos de uso con un anlisis de requerimientos tradicional como el propuesto en [2]. A pesar de que ambas actividades tienen objetivos similares, la relacin entre ellas es escasa. Los procesos de desarrollo iterativos adems, utilizan a los casos de uso como unidad de asignacin en cada iteracin. En general, en cada iteracin se ataca el desarrollo completo de un caso de uso [4]. La complejidad que presenta el desarrollo de un caso de uso es notablemente inferior en comparacin con la que presenta el problema completo. Las relaciones extend y use entre los casos de uso juegan un papel importante en este contexto ya que permiten la identificacin de comportamiento comn entre casos de uso y la reutilizacin de las colaboraciones que los realizan. Inclusive, esta reutilizacin puede darse tambin a nivel de las proyecciones de dichas colaboraciones sobre las capas de presentacin y persistencia. Los casos de uso son definidos en una etapa previa a aquella en la que se producen las iteraciones, y usualmente el nivel de conocimiento del problema no es a ese punto suficientemente profundo como para poder detectar mentalmente las posibles relaciones entre los casos de uso. El nivel de conocimiento necesario para ello es obtenido en cada ciclo, donde se profundiza en aquella parte del problema relativa a cada caso de uso. En particular, una relacin de uso no evidente entre casos de uso se descubrira durante un ciclo recin al detectar comportamiento comn con un ciclo anterior, es decir demasiado tarde. Su implementacin estara embebida en la del caso de uso donde ocurri por primera vez, dificultando as la reutilizacin, objetivo principal de dicha relacin. En este trabajo se presenta una forma de estudiar los casos de uso tal que permite detectar posibles relaciones de uso y extensin entre ellos en una etapa temprana del proceso de desarrollo. En particular, se utiliza el anlisis de requerimientos tradicional en combinacin con el anlisis de casos de uso, y a partir de esta informacin se estudia su relacionamiento. La idea clave es que para este fin los casos de uso se entienden como una secuencia ordenada de requerimientos funcionales. Modelando esta informacin en forma adecuada, en nuestro caso mediante un grafo, es posible detectar intersecciones entre estas secuencias, que representan comportamiento comn entre los casos de uso. Esta tcnica no presenta inconsistencias con el resto de las actividades tpicas en un proceso de desarrollo, y define una relacin precisa entre casos de uso y requerimientos funcionales, haciendo explcita la correspondencia entre ellos. Adems permite verificar por ejemplo, que todos los requerimientos estn cubiertos por algn caso de uso. Finalmente, la informacin obtenida puede usarse adems como parmetro en la actividad de clasificacin y asignacin de casos de uso a ciclos de desarrollo, por ejemplo, priorizndose en la clasificacin aquellos casos de uso que puedan resultar complejos por incluir muchos otros, o dejando las extensiones para ciclos posteriores. Este trabajo est organizado de la siguiente forma. La segunda seccin contiene una definicin ms precisa del problema y los trminos que se utilizarn, y la presentacin del ejemplo que ser desarrollado a lo largo del artculo. En la tercera seccin se presenta en detalle la solucin propuesta. La conclusin del caso de estudio se muestra en la cuarta seccin. En la quinta seccin se presentan las conclusiones. 2 REQUERIMIENTOS FUNCIONALES Y RELACIONES ENTRE CASOS DE USO

Un requerimiento funcional describe qu es lo que un producto de software hace, usando notacin informal, semiformal o formal [1]. El anlisis de requerimientos es una actividad del proceso de desarrollo de software que tiene el propsito de identificar y documentar las cualidades requeridas para la aplicacin en trminos de funcionalidad, pero adems en trminos de performance, facilidad de uso, portabilidad, etc. [1]. Un caso de uso es una forma posible de usar el sistema, y constituye una descripcin narrativa de un conjunto de secuencias de acciones que el sistema realiza y que conduce a un resultado de valor para un actor (agente externo) [3]. Una secuencia de acciones que ilustra un cierto comportamiento se denomina escenario [6]. Un caso de uso presenta entonces un conjunto de escenarios, uno de ellos representa el curso tpico de eventos, y los restantes 2

cursos alternativos. El curso tpico de eventos es el escenario ms comn del caso de uso y es el que se describe en la seccin principal del documento del caso de uso. Los dems escenarios se documentan en funcin de ste en una seccin aparte. Cuando se realiza el anlisis de requerimientos funcionales y luego el anlisis de casos de uso, es esencial verificar que ambas visiones sean coherentes, o sea que expresen las mismos funcionalidades, ya que el problema representado es el mismo en ambos casos.

En el ejemplo que ser desarrollado a lo largo de este trabajo, se describe la manera en que trabaja un cajero automtico, de manera muy simplificada y sin detallar todas sus posibilidades. Bsicamente, el trabajo del cajero consiste en brindar una manera prctica de manejar una cuenta bancaria sin necesidad de ir al banco y esperar un turno. Concretamente, brinda las funcionalidades de retirar dinero de una cuenta, consulta de estado de una cuenta y depositar dinero en dicha cuenta bancaria, correspondientes a los casos de uso Retiro, Consulta de Estado de Cuenta y Depsito respectivamente. Para ello, el sistema necesita una forma de identificar al usuario (en los cajeros reales, eso se realiza mediante una tarjeta con banda magntica y adems un cdigo numrico o PIN). La tabla de la fig. 1 muestra los requerimientos funcionales identificados para el ejemplo y las tablas de las figs. 2, 3 y 4 contienen los casos de uso definidos.

R.1 R.2 R.3 R.4 R.5 R.6 R.7 R.8 R.9 R.10 R.11

Identificacin del usuario Ofrecer opcin (consulta, retiro, depsito o salir) Consulta del estado de cuenta Retiro de dinero Depsito de dinero Entregar dinero Entregar comprobante Ofrecer sobre Entregar sobre Ofrecer la realizacin de otra operacin Devolucin de la tarjeta Figura 1: Requerimientos funcionales

Caso de uso: Actores: Tipo: Descripcin:

Cursos alternativos

Retiro Usuario Primario El usuario es identificado por el sistema (R.1), elige la opcin de retirar (R.2), realiza el retiro (R.4) y recibe el dinero (R.6) y comprobante (R.7). Ante la pregunta del sistema, responde que no quiere realizar otra operacin (R10), retira la tarjeta (R.11) y se retira. En el men inicial (R.2), eventualmente el usuario puede optar por salir del sistema, retirando previamente su tarjeta (R.11). Al final de la operacin, si responde que s desea realizar otra operacin, vuelve al men (R.2) donde puede elegir cualquier opcin. Figura 2: Caso de uso Retiro

Caso de uso: Actores: Tipo: Descripcin:

Cursos alternativos

Depsito Usuario Primario El usuario es identificado por el sistema (R.1), elige la opcin de depositar (R.2), el sistema le ofrece un sobre por si el usuario no tiene (R.8) y en ese caso le entrega uno (R.9). Posteriormente deposita el dinero (R.5) y recibe el comprobante (R.7). Ante la pregunta del sistema, responde que no quiere realizar otra operacin (R.10), retira la tarjeta (R.11) y se va. En el men inicial (R.2), eventualmente el usuario puede optar por salir del sistema, retirando previamente su tarjeta (R.11). Al final de la operacin, si responde que s desea realizar otra operacin, vuelve al men (R.2) donde puede elegir cualquier opcin. Figura 3: Caso de uso Depsito

Caso de uso: Actores: Tipo: Descripcin:

Consulta de estado de cuenta Usuario Primario El usuario es identificado por el sistema (R.1), elige la opcin de consultar (R.2), consulta el estado de cuenta (R.3) y recibe el comprobante (R.7). Ante la pregunta del sistema, responde que no quiere realizar otra operacin (R.10), y retira la tarjeta (R.11). En el men inicial (R.2), eventualmente el usuario puede optar por salir del sistema, retirando previamente su tarjeta (R.11). Al final de la operacin, si responde que s desea realizar otra operacin, vuelve al men (R.2) donde puede elegir cualquier opcin.

Cursos alternativos

Figura 4: Caso de uso Consulta de estado de cuenta

En la especificacin oficial de UML [5], se presenta ampliaciones al concepto bsico de caso de uso. Un punto de extensin es una referencia a una ubicacin dentro del caso de uso en la cual acciones de otros casos de uso pueden ser insertadas. A su vez, define algunas relaciones entre casos de uso: Una relacin use desde el caso de uso A al caso de uso B (A usa a B) indica que una instancia del caso de uso A contendr el comportamiento especificado en B. Este comportamiento es incluido en la definicin de A. Una relacin extend desde el caso de uso A al caso de uso B (A extiende B) indica que el comportamiento del caso de uso B puede ser aumentado (sujeto a condiciones particulares indicadas en el caso de uso) por el comportamiento especificado en A. Este comportamiento se inserta en el punto de extensin definido en B el cual es referenciado por la relacin extend.

Estas relaciones permiten planificar mejor el desarrollo, ya que al identificarlas se factoriza el problema. Adems, la deteccin del comportamiento comn provee de un mecanismo para la reutilizacin, como se indic anteriormente. Para poder aprovechar estas cualidades, las relaciones entre casos de uso deben ser detectadas en un momento temprano del proceso de desarrollo. En este punto y con la informacin disponible es posible determinar la relacin de ocurrencia mencionada previamente de manera informal entre casos de uso y requerimientos funcionales. 4

Esta relacin ahora se define de la siguiente forma: ocurre CU RF (A,R) ocurre el requerimiento funcional R ocurre en el caso de uso A donde un requerimiento funcional R ocurre en un caso de uso A si el comportamiento descrito por R aparece incluido en el comportamiento descrito por A. Esta correspondencia permite verificar que todo requerimiento aparezca al menos en un caso de uso. Sin embargo, las relaciones de uso y extensin entre los casos de uso con esta informacin no son evidentes. 3 DETECCIN DE RELACIONES ENTRE CASOS DE USO

En esta seccin se mostrar la forma de combinar la informacin proporcionada por un anlisis de requerimientos funcionales, como el de la fig. 1, con los documentos de casos de uso, como los de las figs. 2, 3 y 4, para detectar posibles relaciones de uso y extensin entre casos de uso. Para detectar relaciones de uso e inclusin entre casos de uso, se explota al mximo el vnculo existente entre ellos y los requerimientos funcionales. Para ello se considera una familia de relaciones de orden, indizada en los casos de uso, entre requerimientos definida de la siguiente forma: ordenA RF RF, con A CU (Ri,Rj) ordenA el requerimiento funcional Ri ocurre antes en el tiempo que el requerimiento Rj en el caso de uso A Estas relaciones determinan un orden entre los requerimientos segn su ocurrencia en el tiempo en un caso de uso y permiten representar a un escenario de un caso de uso como una secuencia de requerimientos funcionales. Por lo tanto, en trminos generales, un caso de uso completo es representado como un conjunto de secuencias de requerimientos. La familia de relaciones surge prcticamente como una consecuencia del proceso de definicin de la relacin ocurre, por lo que el esfuerzo extra que requiere su definicin no es, en general, significativo. El objetivo de entender los casos de uso como secuencias de requerimientos funcionales es facilitar la deteccin de comportamiento comn entre ellos. El comportamiento comn viene dado por las intersecciones que se produzcan entre dichas secuencias. Para poder determinar estas intersecciones es necesario utilizar una representacin adecuada. Para la eleccin de la representacin debe considerarse que: 1. 2. 3. Sern definidas varias secuencias en forma independiente (en particular, una por cada escenario). Los elementos que conforman cada secuencia (requerimientos funcionales) son tomados de un mismo conjunto (el conjunto de todos los requerimientos funcionales). Si un elemento aparece incluido en ms de una secuencia debe ser considerado el mismo elemento.

De acuerdo a las consideraciones anteriores, el modelo de grafo puede resultar adecuado para la representacin. Se define el grafo de ocurrencia y orden como un grafo dirigido y sin aristas mltiples, donde los nodos o vrtices representan los requerimientos funcionales, y una arista dirigida (Ri,Rj) representa la ocurrencia de los requerimientos Ri y Rj en forma consecutiva en un escenario de un caso de uso. De esta forma, los casos de uso son representados mediante un conjunto de caminos en el grafo. Debido a que una misma arista puede pertenecer a ms de un caso de uso, es necesario adjuntar informacin a cada arista del grafo. Esta informacin es el conjunto de casos de uso a los que la arista pertenece. La restriccin de no permitir aristas mltiples entre un par de vrtices, viene dada por la necesidad de notar, precisamente, si una arista pertenece a ms de un caso de uso. Se definen adems dos vrtices distinguidos I y F que representan el inicio y el fin de todos los caminos originales. La idea de que los cursos alternativos de eventos sean especificados en funcin del curso tpico sugiere que puede no ser necesario distinguir los diferentes escenarios de un mismo caso de uso, es decir, considerar cada camino por separado. En cambio, es posible superponer todos los caminos correspondientes a un mismo caso de uso. El resultado de esto es un grafo, que puede ser interpretado como el camino correspondiente al curso tpico de eventos, con ramificaciones que representan las variantes. De esta forma, el grafo que representa a un caso de uso es un subgrafo del grafo de ocurrencia y orden. Con este enfoque no existe prdida de informacin, ya que los 5

escenarios son representados por cualquier camino dirigido a travs del subgrafo, tal que comience en el vrtice I y finalice en el vrtice F. Para ilustrar las ideas explicadas, las mismas se aplicarn al ejemplo del Cajero Automtico para detectar posibles relaciones entre los casos de uso Retiro, Depsito y Consulta de estado de cuenta presentados en la seccin 2. De acuerdo a los requerimientos listados en la fig. 1, los subgrafos correspondientes a cada uno de los tres casos de uso de muestran en las figs. 5, 6 y 7 respectivamente. El grafo de ocurrencia y orden completo se muestra en la fig. 8.

R4

R6

R7

{A}

{A}

{A}

{A} R10 {A}

{A}

Figura 5: Camino correspondiente al caso de uso Retiro

R8

R5

R7

{B}

{B}

R9

{B}

{B}

{B}

{B} R10 {B}

{B}

Figura 6: Camino correspondiente al caso de uso Depsito

R3

R7

{C}

{C}

{C} R10 {C}

{C}

Figura 7: Camino correspondiente al caso de uso Consulta

R11

R1

R2

{C}

{C}

{C}

{C}

R11

R1

R2

{B}

{B}

{B}

R11

R1

R2

{A}

{A}

{A}

{A}

{B}

R8

R4

R6

{A,B,C} R1

R10

{A,B,C}

Figura 8: Grafo de ocurrencia y orden

Una vez construido el grafo y definidos los subgrafos que representan a cada caso de uso, es posible comenzar el estudio de la deteccin de relaciones entre los mismos. 3.1 Relacin Use Por simplicidad, en esta subseccin se asume los casos de uso sin cursos alternativos ya que este hecho solo aporta complejidad a la discusin. Un caso general se tratara en forma idntica. Por lo tanto y en este contexto, un caso de uso es representado en el grafo simplemente por un camino. Segn la definicin dada para la relacin use entre casos de uso, un caso de uso que use a otro debe incluir completamente su comportamiento. En trminos del grafo, esta situacin se traduce en que el camino que representa al caso de uso usado est incluido en el camino que representa al caso de uso que lo usa. De esto se concluye la condicin necesaria para una relacin use: si el caso de uso B usa el caso de uso A, entonces el camino correspondiente al caso de uso A est contenido en el camino correspondiente al caso de uso B. Es un detalle no menor comprender que el recproco no necesariamente se cumple. La relacin use entre casos de uso es ms bien conceptual, esto indica que su aplicacin efectiva a un caso concreto depende del contexto y de la intencin del analista. En otras palabras, un caso que potencialmente permita aplicar esta relacin puede ser desestimado, por ejemplo en situaciones donde el reuso sea mnimo. Por lo tanto, la presencia de un camino contenido en otro puede no implicar la definicin de una relacin de uso entre los casos de uso. Debido a que el objeto del estudio es el grafo, esta consideracin tiene la implicancia de que no todos los casos descubiertos sern considerados finalmente como una relacin de uso. De cualquier forma, es preciso estudiar todos los casos que generen una potencial relacin de uso. La fig. 9 muestra los caminos correspondientes a dos casos de uso; el camino correspondiente al caso de uso A est contenido en el camino correspondiente al caso de uso B. Esto podra dar lugar a una relacin de uso del caso de uso B al caso de uso A.
{A} {A} {A,B} {A} {A}

{B}

{B}

Figura 9: Un camino contenido completamente en otro

R11

{A,B,C} R2

R3

{C}

{C}

{A,B,C}

R7

{A}

{A}

R5

{B}

R9

{B}

{B}

{B}

{B}

{A}

{A,B,C}

{A,B,C}

{A,B,C}

Una vez fijada la idea, se puede estudiar el caso ms comn en que se presenta una relacin de uso; cuando dos casos de uso comparten un mismo comportamiento. Lo usual aqu sera considerar a este comportamiento como un tercer caso de uso (abstracto) y especificar que los dos originales lo usan. En trminos del grafo, esta situacin se traduce en que los caminos correspondientes a dos casos de uso independientes entre s tienen parte en comn. La aparicin del tercer caso de uso requiere la actualizacin del grafo, ya que al estudiar los dems casos de uso se desear compararlos con el nuevo y no contra los dos que lo originaron. La fig. 10 muestra un caso como el descrito donde el caso de uso A comparte parte de su camino asociado con el del caso de uso B. La fig. 11 ilustra la actualizacin realizada sobre el grafo con el nuevo caso de uso C.

{A}

{A} {A} {A,B}

{A}

{A}

{B}

{B}

{B}

Figura 10: Dos casos de uso comparten parte de un camino

{A}

{A} {A}

{(A,C),(B,C)}

{A}

{A}

{C}

{B}

{B}

{B}

Figura 11: Actualizacin con la relacin use

Ntese que en la informacin asociada a la arista comn, se agreg el caso de uso C pero se eliminaron los casos de uso A y B. La razn de ello es que el comportamiento representado por C fue separado de A y B a causa de la relacin de uso. Ahora, tanto el camino etiquetado con A como el etiquetado con B se ven interrumpidos. Para no perder informacin es necesario especificar, en el vrtice donde se produce la interrupcin, por cul camino deben continuar. La interrupcin adems corresponde directamente con el salto producido en un caso de uso al insertar el comportamiento del caso de uso usado. En resumen, el problema de detectar una posible relacin de uso entre dos casos de uso A y B se puede expresar en trminos del grafo como el problema de hallar un subcamino maximal comn a los caminos que representan a ambos casos de uso. De ser hallado un subcamino, este representara un nuevo caso de uso C, objeto de una relacin de uso por parte de los otros dos. La razn por la que el grafo debe ser actualizado con el nuevo caso de uso, de ser considerado como tal, es que es preciso explorar la existencia de relacin entre l y los otros casos de uso. Comparar el camino del nuevo caso de uso C con los dems, permite descubrir si algn otro caso de uso, aparte de A y B, lo usan. 3.2 Relacin Extend Una relacin de extend entre casos de uso, segn la definicin dada, indica que el comportamiento de un caso de uso puede ser condicionalmente aumentado con el comportamiento de otro. En particular, si un caso de uso B extiende a otro A, el caso de uso A incorpora el comportamiento del caso de uso B. El aumento se produce nicamente si una cierta condicin es satisfecha. En el caso de uso A debe estar definido un punto de extensin PE, encontrndose asociada a l la condicin mencionada. Al alcanzarse el punto de extensin, se inserta el comportamiento del caso de uso B, y una vez finalizado se retoma el caso de uso A en el punto donde ste haba quedado. Si la condicin no es satisfecha, el comportamiento del caso de uso A no se ve afectado. La fig. 12 ilustra este funcionamiento, donde Apre y Apost representan el comportamiento del caso de uso A que tiene lugar antes y despus del punto de extensin respectivamente. 8

Apre si condicin del PE es satisfecha entonces B Apost Figura 12: Funcionamiento de una relacin extend

De acuerdo con esto, resulta natural pensar en los cursos alternativos de un caso de uso como extensiones al caso de uso constituido nicamente por el curso tpico. Sin embargo, notar que si el punto de extensin no se encuentra en el extremo final del curso tpico, un caso particular de curso alternativo podra ser una desviacin sin retorno. Por lo tanto no todo curso alternativo constituye una posible extensin, porque puede no corresponder con el funcionamiento antes descrito. En los trminos de la fig. 12, notar que si el punto de extensin se encuentra a lo ltimo de A, el hecho de que B represente una desviacin sin retorno no afecta ya que Apost sera vaco y el curso alternativo B puede ser efectivamente considerado como una extensin de A. En trminos del grafo esta situacin se traduce en que tanto el curso tpico como la variante son caminos (principal y alternativo). Debe existir una arista dirigida entre el vrtice del camino principal que contiene al punto de extensin, y el vrtice inicial del camino alternativo. Adems, debe existir arista entre el vrtice final del camino alternativo y el sucesor del que contiene el punto de extensin, como se ilustra en la fig. 13. Ntese que en particular este vrtice puede ser F si el punto de extensin se encuentra en el ltimo vrtice del camino principal, siendo un ejemplo de una extensin sin retorno pero vlida.
{A} {A}

{A}

{A} {A}

{A}

Figura 13: Camino alternativo que agrega comportamiento al tpico

En forma anloga al caso de la relacin use, se puede expresar la condicin necesaria para una relacin extend: si el caso de uso B extiende al caso de uso A, entonces el camino correspondiente al caso de uso B representa un camino de largo mayor que 1 entre dos vrtices consecutivos (siendo el primero un punto de extensin) en el camino del caso de uso A. En forma similar al caso anterior, el recproco no es necesariamente cierto. Al detectar una relacin de extensin, es necesario tambin realizar una actualizacin en el grafo. Al camino opcional que constituye el caso de uso que extiende le es asignado un nombre diferente como se muestra en la fig. 14, ya que la extensin es separada como un nuevo caso de uso. Para no perder informacin es necesario reflejar la relacin en el grafo. Asociado al vrtice que contiene el punto de extensin debe especificarse el nombre del caso de uso que extiende. Es posible que varios casos de uso hagan referencia al mismo punto de extensin, por lo tanto en el caso general, esta informacin asociada debe ser el conjunto de nombres de los casos de uso extensores.

{B} {(A,B)} {A} {A} {A}

{B}

{A}

Figura 14: Actualizacin con la relacin extend

Puede considerarse que una relacin de extensin no propicia en forma directa el reuso, sino que explicita un curso alternativo que no representa necesariamente una situacin de error. La oportunidad de reuso aparece s cuando adems se detecta una relacin de uso. Por ejemplo considrese la siguiente situacin: sean dos casos de uso A y B tales que en un principio no se detect ninguna relacin entre ellos. Sea A la nica extensin de A y B la nica de B. Segn la actualizacin presentada anteriormente, A y B son ahora los cursos tpicos de los casos originales. Supngase adems que es posible detectar una relacin de uso entre ambos. Esta relacin podra ser tal que A y B coincidan, renombrndolos en C, por claridad. Finalmente, los casos de uso originales podran reescribirse como los casos de uso A y B extendiendo al caso de uso C. Un caso particular que resulta de inters, es aquel donde la condicin asociada al punto de extensin es evaluada nuevamente al finalizar el caso de uso que extiende, permitiendo una nueva ocurrencia del mismo. Este caso se puede denominar extensin cclica y su funcionamiento se ilustra en la fig. 15. Apre mientras condicin de PE sea satisfecha B Apost Figura 15: Funcionamiento de extensin cclica

En trminos del grafo, esto corresponde a que la arista con origen en el ltimo vrtice del camino correspondiente al caso de uso que extiende incida en el vrtice donde se inici la extensin, como se muestra en la fig. 16.

{B}

{B} {(A,B)} {A} {A}

{B}

{A}

{A}

{A}

Figura 16: Camino alternativo con extensin cclica 4 CASO DE ESTUDIO En esta seccin se presenta la conclusin del ejemplo del Cajero Automtico que fuera introducido en la seccin 2 y desarrollado en la siguiente. El grafo de correspondencia y orden fue mostrado en la fig. 8. En l, los casos de uso Retiro, Depsito y Consulta son identificados con las letras A, B y C respectivamente. A partir de la informacin contenida en el grafo es posible detectar varias situaciones que se discuten a continuacin. 1) En los tres casos de uso se detecta una situacin similar al ejemplo de combinacin de relaciones de uso y extensin dado en la subseccin 3.2. Se define el caso de uso Ingreso/Salida identificado con la letra D, compuesto por los requerimientos R.1, R.2 y R.11 en ese orden, y los casos de uso Retirar, Depositar y Consultar que extienden al caso de uso Ingreso/Salida, identificados por las letras A, B y C respectivamente. Estos casos de extensin corresponden a la extensin cclica vista en la subseccin 3.2. 2) En el caso de uso Depositar se detecta un camino opcional correspondiente a la aceptacin de un sobre. Este camino se lo considera una extensin regular del caso de uso Depositar, dando lugar al caso de uso Aceptar sobre, identificado con la letra B. 3) Los casos de uso Depositar, Retirar y Consulta, tienen en comn la entrega del comprobante de la transaccin y la consulta al usuario de si desea realizar otra operacin. Este comportamiento comn se denomina Comprobante y nueva operacin, consistente en los requerimientos R.7 y R.10 en ese orden, e identificado con la letra E. 10

La fig. 17 ilustra las actualizaciones realizadas sobre el grafo de ocurrencia y orden original a causa de las relaciones detectadas anteriormente.

{B''} {(B',B'')} R8

R9

{B''}

R5 {B'} {(A',E),(B',E),(C',E)}

{B'}

R4

R6

{B'}

R10

{(D,A'),(D,B'),(D,C')} {D}

Figura 17: Grafo actualizado Finalmente, la fig. 18 muestra un diagrama de casos de uso que refleja la totalidad de los casos de uso definidos y las relaciones detectadas entre ellos.

Recibir sobre extend

use

Depositar

extend

Comprobante y otra operacin

use

Retirar

extend

Ingreso/Salida

use

Consultar

extend

Figura 18: Diagrama de casos de uso

Resulta interesante observar que en el punto 1 de la discusin consider a los casos de uso Depositar, Retirar y Consultar como extensiones del caso de uso Ingreso/Salida. Esto resulta contraintuitivo, ya que dara lugar a suponer que entonces Ingreso/Salida representa por s solo el curso tpico de eventos en el uso de un cajero automtico, cuando en realidad no lo es. Por el contrario, las relaciones de extensin surgieron del estudio de la estructura del grafo y sin considerar la semntica asociada a cada caso de uso. Dejando de lado la idea de que una extensin es menos importante que el curso tpico, puede apreciarse que la solucin presentada es una buena descripcin del comportamiento de un cajero automtico. Por otra parte, el caso de uso Ingreso/Salida es equivalente al caso Login/Logout tratado en [3], en el que se considera que todos lo casos de uso podran representarse como extensiones a l.

11

R11

R1

R2

{D}

{D}

R3

{C'}

{C'}

{A',B',C'}

R7

{A'}

{A'}

{A'}

{E}

{A',B',C'}

{D}

CONCLUSIONES

En este trabajo se present una tcnica que permite detectar posibles relaciones de uso y extensin entre casos de uso. Basndose en la idea de que el comportamiento de un caso de uso puede ser descrito tambin mediante una secuencia de requerimientos funcionales, se defini una representacin para el conjunto de secuencias sobre la cual es posible detectar ciertos patrones que sugieren la existencia de relaciones de uso y extensin entre los casos de uso. Lo interesante de esta tcnica es que la informacin requerida para su aplicacin consiste, adems de la definicin de los requerimientos funcionales y los casos de uso, en un estudio de la correspondencia entre unos y otros, lo que significa que es posible realizar su aplicacin en una etapa temprana del proceso de desarrollo. Tambin se mostr que siguiendo este enfoque es posible definir una relacin precisa entre los casos de uso y los requerimientos funcionales, que a su vez permite integrar las actividades del anlisis de casos de uso con la del anlisis de requerimientos. Una extensin interesante a este trabajo puede ser la definicin de algoritmos que procesen en forma eficiente el grafo de ocurrencia y orden. Dado que, por un lado el objetivo de la tcnica es generar informacin que sea de ayuda y no complicar innecesariamente el proceso de desarrollo, y por otro que una solucin ptima podra derivar en una cantidad abrumadora de informacin sin utilidad en ciertos casos particulares, la aplicacin de heursticas puede constituir una solucin aceptable. Los objetivos principales de este tipo de trabajos futuros son, en primer lugar, lograr una descripcin precisa de una metodologa para la aplicacin de la tcnica presentada, y en segundo lugar, la posibilidad de la implementacin de una herramienta que automatice en forma total o parcial el procesamiento del grafo. Para ello es posible definir criterios de poda en la bsqueda de las posibles relaciones, por ejemplo definir un largo mnimo de un subcamino comn para que la relacin de uso sea considerada factible, o en general definir patrones que permitan descartar aquellas relaciones potenciales que se sepa de antemano que no interesa que sean consideradas. Finalmente, esta tcnica puede ser costosa de aplicar manualmente en proyectos de porte mediano-grande, pero en vista de la utilidad de la informacin generada puede valer el tiempo y el esfuerzo dedicado ya que se aplica una nica vez. REFERENCIAS [1] C. Ghezzi, M. Jazayeri y D. Mandrioli. Fundamentals of Software Engineering. Prentice-Hall, 1991 [2] IEEE. Software Requirements Specification, Std 830. IEEE, 1984. [3] I. Jacobson, M. Christerson, P. Jonsson y G. vergaard. Object-Oriented Software Engineering: A Use-Case Driven Approach. Addison Wesley, 1992 [4] C. Larman. Applying UML and Patterns. Prentice-Hall, 1998 [5] Object Management Group. OMG Unified Modeling Language Specification, version 1.3. 1999. Ver documento en http://www.omg.org [6] J. Rumbaugh, I. Jacobson y G. Booch. The Unified Modeling Language Reference Manual. Addison Wesley, 1999.

12