Uses vs. Extends Roberto Barriga Rodríguez Aitana Giner Martín Facultad de Informática – Universidad Politécnica de Valencia Email: robarrod@inf.upv.es, aigimar@inf.upv.es
1. Resumen Un caso de uso es una típica interacción entre un usuario y un sistema de computador. La esencia de los casos de uso es capturar los requerimientos de un sistema, detallando todos los escenarios que el usuario construya. Se
pueden
organizar
casos
de
uso
especificando
relaciones
de
generalización, include y extend entre otros. Se aplican esas relaciones para factorizar un comportamiento común (tomando tal comportamiento de otros casos de uso que lo incluyan) y variantes (asignando tal comportamiento en otros casos de uso que lo extiendan). 2. Introducción Durante mucho tiempo en todos los desarrollos OO las personas usaban los escenarios para ayudarse a entender los requerimientos. Sin embargo los escenarios eran tratados muy informalmente. Jacobson es conocido por cambiar esto. Mejoró la visibilidad del caso de uso (su nombre para el escenario) hacia el extends que llegó a ser un elemento fundamental en el desarrollo de proyectos y en la planificación. El objetivo de este trabajo es aclarar las diferencias que existen entre el uses y el extends y conocer otros nuevos conceptos como son el invokes y el precedes. 1 Laboratorio de Sistemas de Información Facultad de Informática Universidad Politécnica de Valencia
En primer lugar se describe brevemente el concepto de caso de uso para centrar al lector en el tema. A continuación se expone el tema, desde el punto de vista de varios autores, mediante ejemplos: Martin Fowler con Kendall Scott y Doug Rosenberg con Kendall Scott. Al final del trabajo se ha incluido la opinión de otros autores 3. ¿Qué es un caso de uso? Un caso de uso es una secuencia de acciones que ejecuta un actor dentro de un sistema para lograr un objetivo particular. El resultado de la modelización de un caso de uso debe ser que todos los requerimientos funcionales del sistema queden descritos. Un factor importante al crear casos de uso, es que se realizan sin detallar como se implementaron. Por ejemplo, se puede especificar como un sistema ATM se comportaría estableciendo en los casos de uso la manera en la que los usuarios van a interactuar; no es necesario tener conocimiento sobre la parte interna. Los casos de uso especifican el comportamiento deseado, no determinan como se llevará a cabo. Algo muy importante acerca de esto es que permiten (al usuario final y experto del dominio) comunicarse con los desarrolladores (quien construye los sistemas que satisfagan los requerimientos) sin caer en detalles; los casos de uso permiten enfocarse a los resultados. Un actor representa un papel que un usuario puede jugar dentro de un sistema o una entidad. El conjunto de actores dentro de un modelo de caso de uso refleja todo lo que se necesita para intercambiar información con el sistema. Por ejemplo en un hospital algunos actores podrían ser: Médicos, Administrativos... Un usuario puede ser más de un tipo de actor. Por ejemplo, una enfermera puede hacer también el trabajo de un administrativo. Del mismo modo más de un usuario puede aparecer como un actor.
2 Laboratorio de Sistemas de Información Facultad de Informática Universidad Politécnica de Valencia
Dentro de un diagrama de casos de uso, los casos de uso aparecen como óvalos, generalmente en medio del diagrama; los actores aparecen como figuras a la derecha y a la izquierda. Durante la elaboración, esto es todo lo que se necesita para empezar, no hay que tratar de capturar al principio todos los detalles correctamente, sólo cuando se necesiten. Si se cree que el caso de uso dado tiene grandes ramificaciones arquitectónicas será necesario dar más detalles. Muchos casos de uso pueden ser detallados cuando se construyen.
3 Laboratorio de Sistemas de Información Facultad de Informática Universidad Politécnica de Valencia
4. Uses y Extend por Martin Fowler y Kendall Scott Además de las relaciones entre actores y casos de uso, hay otros dos tipos, las que existen entre el uses/extends y los casos de uso. Se utiliza la relación extends cuando se tiene un caso de uso que es similar a otro pero hace algo más.
Analyze Risk Price Deal
Trader
<<Usses>>
<<Usses>>
Valuatio n
Capture Deal <<Extends>>
Actor
Limits Exceeded Caso de uso
Figura 1 En el ejemplo de la figura 1, el caso de uso básico es Capture Deal. Este es el caso en el que todo va bien, sin embargo hay cosas que pueden alterar el buen funcionamiento. Una de estas cosas es cuando se exceden algunos límites Limits Exceeded. Aquí no se representa el comportamiento usual asociado con el caso de uso dado; se ha llevado a cabo una variación.
4 Laboratorio de Sistemas de Información Facultad de Informática Universidad Politécnica de Valencia
Podemos poner esta variación dentro del caso de uso Capture Deal. Sin embargo esto puede abarrotarlo con mucha lógica, que oscurecería el flujo normal. Otra manera de introducir la variación es poner el comportamiento normal en un caso de uso y el comportamiento inusual en otro sitio. Los pasos a seguir son los siguientes:
1. Capturar primero el caso de uso básico. 2. En todos los pasos que se realicen en este caso de uso preguntarse “¿qué puede ir mal aquí?” y “¿cómo afecta a la forma de trabajar?” 3. Dibujar todas las variaciones como extensiones. Pueden ser un número bastante grande. El caso de uso se puede hacer en dos fases, la de elaboración y la de construcción. En la elaboración, a menudo se parte de cualquier caso de uso que sea complicado. Sin embargo, hay casos de uso cuya complejidad es muy grande, y entonces no se introducen hasta la construcción. Si no se puede construir completamente el caso de uso en una sola iteración hay que separar, en la construcción, el proyecto en etapas. Se divide un caso de uso complejo en un caso de uso normal y unas pocas extensiones y luego se construye el caso de uso normal en una iteración y las extensiones como parte de una o más iteraciones siguientes. Las relaciones uses ocurren cuando se tiene una buena parte del comportamiento que es similar que alcanza más de un caso de uso y no se quiere conservar copias de la descripción del comportamiento. Por ejemplo, tanto en Analyze Risk como en Price Deal se realizan operaciones similares. La descripción de estas operaciones es muy extensa, y resulta odioso copiar y pegar. Así que lo mejor 5 Laboratorio de Sistemas de Información Facultad de Informática Universidad Politécnica de Valencia
es derivar un caso de uso separado Valuation para esta situación y hacer referencia a él desde el caso de uso original. Existen semejanzas y diferencias entre extends y uses. En ambos hay que sacar fuera el comportamiento común de la mayoría de los casos de uso a un caso de uso simple que es usado, o extendido por otros muchos casos de uso. Sin embargo, el propósito es diferente. Los dos tipos de relaciones implican diferentes cosas en sus conexiones con los actores. En el caso del extends, los actores tienen una relación con el caso de uso que está siendo extendido. Se asume que el actor podrá trabajar con el caso de uso base y con todas las extensiones. Con una relación de uses, a menudo no hay actores asociados con el caso de uso común. Para saber cuando hay que utilizar uses y cuando extends aplicar las siguientes regla: 1. Usar
extends
cuando
se
describa
una
variación
en
un
comportamiento normal. 2. Usar uses cuando se produzca una repetición en dos o más casos de uso separados y se quiera evitar.
5. Invokes y Revokes por Doug Rosenberg y Kendall Scott UML ( United Modeling Language ) establece la relación uses vista anteriormente con el nombre de includes, de cuyo contenido semántico obtenemos que un caso de uso es incluido en otro. Este constructor es predefinido como un estereotipo que podemos añadir a nuestro diagrama de casos de uso. Existe cierta confusión respecto el nombre de este estereotipo, algunos autores como por ejemplo Doug Rosenberg, nombran al estereotipo con el nombre de uses, en vez de 6 Laboratorio de Sistemas de Información Facultad de Informática Universidad Politécnica de Valencia
includes ya que dice que “includes fue el nombre que se le dio en el libro original de Jacobson en las tempranas versiones de UML”[2]. La relación extends permite extender un caso de uso dentro de otro. La idea principal detrás de este constructor es que podemos usarlo para definir comportamientos opcionales del sistema o comportamientos bajo ciertas condiciones. Extends también es predefinido como un estereotipo. UML define un caso de uso como un formulario de una clase generalizada. Sin embargo, existen diversos autores que no generalizan los casos de uso, debido a que la generalización es usado por casos de uso abstractos, es decir, para organizar requerimientos que no están enlazados directamente, estos autores prefieren el uso de otros estereotipos debido a que tanto uses como includes, o extends, guardan una estrecha relación en su significado semántico, de manera que es más fácil cometer una equivocación a la hora de decidir que estructura usar en nuestros casos de uso. A diferencia de UML, OML (Open Modeling Language) no utiliza los estereotipos uses o (includes), ni extends, OML define nuevos conceptos como el invokes y el precedes. Estos nuevos conceptos, toman la forma de estereotipo definido por el usuario en los diagramas de caso de uso. En OML, la idea de invokes está basada en que un caso de uso llama a otro caso de uso, de la misma manera que una función principal llama a una subfunción. Por otra parte, precedes es definido por OML para indicar que un caso de uso necesita preceder a otro dentro de una secuencia lógica en un diagrama de casos de uso. El uso de precedes nos ayuda a mantener el foco en lo que hay dentro del caso de uso. Es decir, que acción o acciones se deben llevar a cabo antes un caso de uso en concreto, así como invokes ayuda a especificar en nuestro diagrama de casos de usos que casos deben ser invocados por al realizar un determinado caso de uso. Existe mucha controversia dentro del campo de casos de uso sobre que es mas eficiente a la hora de diseñar un diagrama de casos de uso, si la utilización de los estereotipos uses / extendes, o los nuevos estereotipos definidos por OML invokes y precedes. Veamos un ejemplo de invokes / precedes en un diagrama de casos de uso para poder establecer mejor criterios de comparación.
7 Laboratorio de Sistemas de Información Facultad de Informática Universidad Politécnica de Valencia
.
Precedes
Entrada Orden Compra
Ejecutar Entrada Orden
Precedes Figura 2
Entrada Orden Venta
En la Figura 2 podemos observar el uso de precedes en las acciones “Entrada Orden Compra” y “Entrada Orden Venta”, las cuales van precedidas de la opción “Ejecutar Entrada Orden”. Esto nos indica que la ejecución de una orden, viene precedida por la entrada de una orden bien sea de compra o de venta, por esta razón usamos el estereotipo precedes, para indicar dicha precedencia. Ahora veamos un ejemplo del estereotipo invokes: Supongamos que al introducir una orden de entrada en nuestro sistema anterior (figura 2), introdujéramos un cliente el cuál no existe en nuestra base de datos, el sistema debería permitir la creación de dicho cliente en ese estado de nuestro sistema, es decir, el sistema debería llamar a la función de adición de clientes. Esto queda reflejado en la figura 3, lo cual nos indica que no siempre será ejecutado el módulo Definir Clientes, solo cuando el sistema cumpla unas determinadas condiciones, en nuestro caso, que el cliente no exista.
8 Laboratorio de Sistemas de Información Facultad de Informática Universidad Politécnica de Valencia
.
Ejecutar Entrada Orden
invokes Definir Clientes
Figura 3 Observemos como quedaría nuestro diagrama de caso de uso usando invokes y precedes y añadiendo otro opción en nuestro diagrama de caso de uso en la cual el usuario podría optar o bien por ejecutar una entrada de una orden, o bien por acceder directamente al mantenimiento de los clientes para poder definir un cliente en el sistema.
.
Precedes Ejecutar Entrada Orden
Precedes
invokes
Entrada Orden Compra
Entrada Orden Venta
Definir Clientes Ejecutar Mantenimiento Clientes
Precedes
Figura 4 En la figura 4, podemos observar la nueva opción para el usuario “Ejecutar Mantenimiento Clientes”, la cual precederá a “Definir Clientes” debido a la inclusión de la cláusula precedes. Esto indica que cuando se ejecute “Definir Clientes”, siempre irá precedido de “Ejecutar Mantenimiento Clientes”, excepto cuando sea invocado por “Ejecutar Entrada Orden” tal y como está indicado en el diagrama de casos de uso por la cláusula invokes.
9 Laboratorio de Sistemas de Información Facultad de Informática Universidad Politécnica de Valencia
6. Otros puntos de vista: •
“La diferencia entre uses y extends parece muy clara y relevante, es todo un asunto de integración. El extends construye informes de desarrollo para la integración entre casos de uso que es uno a uno. Los uses constituyen informes de desarrollo para la integración que es uno a muchos. Cuando decidimos entre uses y el extends hay que hacerse una pregunta: ¿Cuántos casos de uso podrán estar llamando a este caso de uso? si la respuesta es uno, entonces usa extends, sino uses.” Doug Rosenberg con Kendall Scott
Otros sin embargo tienen puntos de vista totalmente diferentes, por ejemplo: •
“La elección entre uses y extends tiene poco que ver con cuantos casos de uso están involucrados. Más bien tiene que ver sobre lo que sabe un caso de uso de otro. En el caso de uses, la utilización del caso de uso sabe sobre el caso de uso utilizado. Esto es como la llamada a una función; muchos casos de uso pueden “usar”el caso de uso utilizado. En el caso del extends el caso de uso extendido contiene una serie de eventos primarios, pero no tiene idea sobre la existencia de casos de uso extendidos. La extensión del caso de uso sobrescribe secciones del caso de uso extendido. Así pues la extensión del caso de uso actúa como una especie de editor, cambiando solo ciertas partes del caso de uso extendido. Así cuando el caso de uso cambie, todos los casos de uso extendidos heredarán estos cambios sin ser afectados”.
10 Laboratorio de Sistemas de Información Facultad de Informática Universidad Politécnica de Valencia
Estas razones son demasiado complicadas para muchas personas. Las últimas dos propuestas llevan al autor a intentar cambiar la forma de pensar entre precedes e invokes. •
La mayoría de nosotros preferimos las relaciones Uses/extends por las siguientes razones: o Uses/extends llevan asociados múltiples definiciones de términos. o La semántica adicional que diferencia el uses del extends.
7. Conclusiones Tras realizar este trabajo hemos comprendido mejor la diferencia entre que hay entre uses-extends, includes-extends e invokes-precedes según cada autor. Además para centrar el tema hemos tenido que repasar conceptos básicos sobre los diagramas de casos de uso. Como nuestro trabajo abarca una pequeña parte de UML otros posibles trabajos podrían estar centrados en otros aspectos importantes que ayuden a los alumnos a entender mejor el funcionamiento de UML, como por ejemplo un estudio sobre diagramas de clases, diagramas de secuencias, diagramas de colaboración, diagramas de distribución, etc, etc... 8. Referencias [1] Martin Fowler, Kendall Scott, UML Distilled Applying the Standard Object Modelling Language. [2] Doug Rosenberg, Kendall Scott, Use Case Driven Object Modeling With UML A practical Approach.
11 Laboratorio de Sistemas de Información Facultad de Informática Universidad Politécnica de Valencia