Casos de Uso Avanzados: Relación de Extensión
Posteado por: Iván Garcerant en: 5-06-08
- En: Casos de Uso| Requisitos| UML
- ¡Comentar!
En muchas ocasiones el uso de características avanzadas de los casos de uso generan dudas en los equipos de desarrollo. La razón básica es que estos modelos deben ser claros antes que cualquier otra cosa, lo que lleva a evitar el uso de las relaciones de inclusión y extensión, entre otras características.
Sin embargo, por muy de acuerdo que podamos estar con el deseo de claridad y sencillez, existen situaciones en que hacer uso de una relación avanzada entre casos de uso mejora en lugar de reducir, la claridad del modelo de requisitos. De ahí por tanto que todo analista de requisitos debe comprender perfectamente el significado de estas relaciones. En el presente post abordamos la relación de extensión <<extend>>.
Técnicamente como para el glosario, la relación de extensión <<extend>> se define como:
Relación <<extend>> Un caso de uso extiende a otro cuando sin alterar a este, se incorpora su funcionalidad como parte integral del primero. Se denota con una relación que apunta del caso extendido al caso base y la conexión se hace o bien al principio del flujo de eventos principal del caso base o en alguno de los puntos de extensión que este haya definido.
La notación gráfica es la siguiente:
Fig. 1 - Relación de extensión <<extend>>
La relación del ejemplo significa que un caso de uso ya existente (el caso “A”) se aprovecha en la definición de un segundo caso (el caso “B”). Dado que la reutilización que requerimos agrega funcionalidad pero no altera al caso base, se ha optado por la relación de extensión. Dicha relación se ha denotado gráficamente con una flecha de dependencia desde el caso extendido (el caso “B”) al caso base (el caso “A”). La dependencia la hemos estereotipado con <<extend>> para que quede claro lo que pretendemos decir.
A nivel de los flujos de eventos, se podría decir que el flujo principal del caso base no se ve alterado, pero que en cambio, el flujo de eventos del caso extendido hace referencia al primero, de manera tal que no puede ser entendido en ausencia de los pasos del caso base.
A fin de contar con un ejemplo completo, consideremos un sistema de compras electrónico. Digamos que este sistema va a atender tanto a clientes finales como a clientes corporativos, permitiendo que adquieran productos en nuestra tienda en línea. La diferencia será que los clientes corporativos hacen compras masivas, quizás programando la entrega a lo largo de un periodo de tiempo de lo que compraron. Esta visión la podemos expresar en el siguiente diagrama:
Fig. 2 – Ejemplo de relación <<extend>> en un sistema
de tienda electrónica en Internet
Ahora si vamos al caso de uso base “Compra artículo (UC-0100)” podríamos tener la funcionalidad de escoger el artículo a comprar y el de pagar con tarjeta de crédito, por ejemplo. Esta funcionalidad esta disponible a los clientes finales, tal como se ve en el diagrama.
Por su parte, los clientes corporativos pueden escoger el artículo a comprar y el modo de pago: digamos tarjetas de crédito. Además el caso de uso captura también la funcionalidad de programar la entrega parcial de lo comprado a lo largo de un periodo de tiempo. Dado que gran parte del caso de uso “Compra masiva (UC-0200)” es idéntica a la encontrada en el caso del cliente final, optamos por reutilizar la especificación por vía de la relación de extensión.
Los criterios a aplicar para saber si la relación de extensión es aplicable son los siguientes:
- Hay cuando menos un caso base y un caso extendido.
- El caso base no se ve modificado por la existencia del caso extendido.
- El caso base es un caso concreto atado a cuando menos un actor.
- El caso extendido incorpora al caso base por completo.
La relación de extensión guarda relación con todos los restantes tipos de reutilización que están definidas para los casos de uso; en particular la relación es muy intima con la relación de inclusión <<include>> sin embargo la diferencia primordial entre <<extend>> e <<include>> es la modificación del caso base. Extensión no implica cambio, en tanto que la inclusión añade funcionalidad al caso base.
Otra relación, la herencia, es similar también a la extensión. En este caso la diferencia es que la herencia cambia o puede cambiar, la naturaleza de lo dicho en el caso base. Por ejemplo, podemos decir que aquello que fue llamado “artículo” en el caso base es ahora referido más detalladamente como “libro” o “juguete”. La herencia de casos de uso reutiliza al caso base sí, pero nos permite alterar la semántica de los detalles; algo que la relación de extensión (ni la de inclusión) pueden hacer.
Por tanto concluyamos: la relación de extensión permite reutilizar una especificación pero sin modificar al caso base.
16 comentarios para "Casos de Uso Avanzados: Relación de Extensión"
[...] diferencia de la relación de extensión[3], aquí ninguno de los casos de uso involucrados puede ser entendidos por completo como piezas [...]
[...] es todo. Mucho más se puede decir sobre los casos de uso: características avanzadas como la relación de extensión y la relación de inclusión; pero en casi todos los casos priva que mientras más sencillo [...]
18-08-08 a 3:26 pm
Realizando cierto analisis con “casos de uso” se me presentó la siguiente consideración de la cual me gustaría conocer vuestra opinión.
Supongamos que multiples analistas realizan en sus procesos particulares “casos de uso” de generacion de datos para estadistica. Cada uno debe proceder a “describir” su logica particular para obtener sus datos, asi como que datos son relevantes para su proceso. Sin embargo, otro analista debe llevar adelante un proceso central para “consultar” toda estadistica del sistema. Entonces, dada su experiencia como desarrollador de software, decide que sus compañeros deberan “implementar” la interfaz “consultable” a todos sus casos de uso. Pero “implementar” no es algo que pertenesca estrictamente a los elementos de Casos de uso, mas bien a “diagrama de clases”. ¿Como podria plasmarse que estos Casos de Uso “implementan” la interfaz requerida?
Recordando que la interfaz consultable, solo define ciertas “funcionalidades” que deben tener los Casos de uso, pero nunca el “como” lo haran.
18-08-08 a 6:04 pm
Saludos.
Estoy de acuerdo con lo que planteas. Ciertas consideraciones que los clientes pueden hacer son en verdad elementos de la solución técnica más que requisitos puros que podamos capturar en un caso de uso.
En otras palabras, así como lo has planteado, lo que el “Analista con experiencia” nos ha indicado es una visión sobre un mecanismo de implementación: la interfaz común “consultable”; mecanismo este que es expresado muy naturalmente en un diagrama de clases.
¿Como podamos recoger este “requisito” mal concebido en nuestro modelo de casos de uso? Hay que recordar primero que la mayor utilidad de los casos de uso es su naturaleza informal. Es posible agregar secciones a nuestras descripciones sin mayor formalismo que poner un título a la misma.
Es decir entonces, que podemos colocar como un requisito suplementario a esta idea de la interfaz “consultable”, a nivel de los casos de uso podemos tener una sección “requisitos adicionales” u otra con nombre similar y de esta forma recoger lo que el “Analista con experiencia” nos pide.
Si hay muchos casos de uso con esta necesidad de expresar la idea de interfaz consultable, entonces es posible recoger esta información ya no como parte del modelo de casos de uso, sino como parte del documento de “Requisitos Suplementarios”. Creo que tengo una plantilla para dicho documento aquí en el blog.
En conclusión: si queremos capturar un requisito debemos recordar que no todo lo que nos dicen es un requisito funcional susceptible a ser expresado en un modelo de casos de uso. En ocasiones y es probable que en tu caso, hay requisitos que son mejor expresado en otros tipos de artefactos.
Y es que en mi opinión, el decir que deben implementar una interfaz determinada, es un requisito no-funcional y de ahí, que no quede bien modelada ni con un extend ni con un include de caso de uso.
[...] profesores tengan la presión de explicar métodos y técnicas avanzadas, como las relaciones de extensión e inclusión de casos de uso, forzando al estudiante a adoptar estar técnicas en forma demasiado [...]
7-11-08 a 12:58 pm
Consulta, un caso de uso puede tener multiples escenarios y podria decir que “un escenario es a un caso de uso, como un objeto es a una clase” considerando lo expuesto podria decir que ¿Un escenario que no es el principal es una extensión del caso de uso?
de antemano muchas gracias.
8-11-08 a 5:03 am
Saludos Francisco, primero que nada gracias por el comentario.
Por definición, un caso de uso es un (1) escenario de interacción entre un ente externo al que llamamos actor y el sistema. Así la cosa no se puede hablar de múltiples escenarios para un mismo caso de uso, no al menos, si con “escenario” queremos referirnos a la especificación de funcionalidad de un sistema.
Por otra parte, llamo “escenario de análisis” a la representación de la interacción entre las partes de un sistema con miras a satisfacer lo dicho en un caso de uso. Bajo este otro significado, un caso de uso bien puede tener más de un “escenario de análisis” si es muy complejo o si queremos representar múltiples posibilidades de interacción o distintas vías en que esta puede presentarse.
Agotados los significados conocidos por mí del concepto “escenario” para un caso de uso, creo que mi respuesta será que “no”, no se pueden representar múltiples escenarios por medio de extensiones de caso de uso.
Analizando lo que preguntas, veo que existe un concepto de caso de uso que bien puede ser oportuno mencionar, la herencia de casos de uso. Yo no la he explicado aún en el blog, pero la idea es recurrir a la herencia de un caso de uso para hacer reutilización de formas más libres que las permitidas por la inclusión o la extensión. Quizás en este nuevo contexto si pueda hablarse en los términos que mencionas, pero entonces las variaciones al caso de uso original serían casos de uso derivados en una relación de herencia, como en una clase y sus clases hijas, y no una relación de construcción de instancias, como entre objeto y clase.
Finalmente, interpretando libremente lo que comentas, si definimos las cosas como has hecho en tu comentario, entonces veo un detalle sobre el método: si hay varios casos de uso relacionados muy íntimamente, nos conviene tenerlos entonces en uno solo, recurriendo a flujos de eventos alternativos o a bifurcaciones dentro de estos. Es decir entonces, que aún si definimos las cosas como has hecho tú, tendría que recomendar no utilizar la extensión para el propósito que mencionas. Nos iría mejor con flujos de eventos alternativos para cada uno de los “escenarios de caso de uso” que mencionas.
Hay que recordar también, que en casos extremos o muy puntuales, el modelado puede verse complicado… por lo que es necesario tener mucha prudencia. Es obvio al menos para mí, que llegado al punto de discutir un caso de uso al nivel que lo estamos haciendo ya hace mucho que hemos perdido la posibilidad de discutir este con el cliente, o dicho de otra forma, que hace ya rato que debidos dejar la especificación en paz y proceder a expresar nuestras ideas en otro tipo de modelo, digamos el modelo e análisis o el de diseño.
Lo sencillo se entiende más y la especificación de un sistema ha de entenderse bien. Si tenemos que ser tan finos en los detalles como para recurrir a técnicas abstractas como la extensión de casos de uso, nos conviene evaluar hasta que punto perdemos claridad solo por un poco de elegancia ganada.
21-05-09 a 6:30 pm
Muchas gracias por tu explicación sobre la relación de extensión, es muy clara, mi duda es la siguiente, estoy diseñando un sistema en donde el usuario tiene que logearse para poder utilizar los servicios de un sistema, es conveniente modelar un caso de uso etiquetado como presentar opciones del sistema CU-2 y otro autenticar usuario CU-1 y una relación de inclusión de CU-2 a CU-1 ??? y finalmente, si en una interfaz gráfica existen por ejemplo las opciones de crear usuario, modificar usuario, cada una de ellas serían casos de uso que extienden la funcionalidad de la GUI que las contiene ???, de antemano, mil gracias por la respuesta a mis dudas !…
25-05-09 a 3:27 am
Saludos Alvaro. Muchas gracias por tu comentario.
Me planteas dos situaciones. Ambas no dejan de ser interesantes, si bien son diferentes entre ellas.
La primera situación que mencionas es la necesidad de indicar las operaciones de autenticación de usuarios en el sistema. Por regla general, todos los sistemas cuentan con algún sistema de usuarios y permisos por roles, por lo que es muy común no especificar nada de esto en un modelo de casos de uso. Verás Alvaro, dado que siempre lo hacemos ya no vemos valor en especificar “una vez más” algo que siempre es igual: que los usuarios se autentifican antes de utilizar la funcionalidad del sistema.
Por otra parte, si solo una porción de los casos de uso representan funcionalidad que debe contar con autenticación (“loggeo”) y el resto del sistema esta libre de esta, entonces sí vale la pena indicar de alguna forma esta diferencia. Sin embargo, yo lo haría con una nota en la sección de prerequisitos del caso de uso.
Una forma más liberal y menos común, y esto solo si me viera obligado a hacerlo en un diagrama, sería tener una relación prerequisito entre los casos de uso que mencionas (CU-1, CU-2), en lugar de una relación de inclusión. De hacer esto, recuerda definir en un glosario u otro documento, el significado de la relación “prerequisito”.
De entre estas dos posibilidades, me gusta más la primera.
En cuanto a la segunda situación que mencionas, me gustaría que notaras que los bocetos y prototipos de GUIs no son creados en modelos de casos de uso. Sé que puede parecer tonto, pero estos prototipos no están en nuestro modelador de UML por lo que no los podemos utilizar en una relación de cualquier tipo con un caso de uso del modelo.
Lo que si podemos, es documentar los bocetos de las GUIs como requisitos no funcionales, ya que efectivamente son requisitos a cumplir.
Es por lo anterior Alvaro, que los modelos de casos de uso no pueden seguir el patrón o la distribución de las interfaces gráficas que eventualmente van a estar implantadas en el sistema.
Dicho de otro modo, yo tendría un caso de uso por cada funcionalidad importante del sistema y quitaría todos los casos de uso que hayan venido de imaginar pantallas y opciones de menú.
Hay una cierta tendencia a construir los modelos de casos de uso como diseños modulares, fuertemente basados en las ideas top-down del pasado. Esto, aunque popular, es incorrecto. Los diseños modulares son eso: diseño. Por lo que los casos de uso no pueden reflejar la idea de módulo y submódulo. De la misma forma, un modelo de casos de uso no puede reflejar la idea de una pantalla principal que “incluye” un grupo de opciones representadas como casos de uso.
25-05-09 a 9:29 pm
Mil gracias por tu explicación, ya despejé mis dudas y voy a seguir tus consejos, sin duda lo importante de los casos de uso es su descripción de los flujos de eventos, pero un buen diagrama no estaría mal, saludos !…
25-05-09 a 11:25 pm
Exacto! Estoy muy de acuerdo contigo. Un buen diagrama no estaría nada mal. 
… siempre y cuando los casos de uso estén correctamente documentados en su descripción breve y su flujo de eventos.
1-07-09 a 2:26 pm
Muy buen artículo, simple y concreto que es lo necesario para comprender metodologías que en muchas ocaciones terminan siendo expuestas o muy vagamente o de manera confusa.
Lo único que me cabe acotar es que no explicas la diferencia entre extender y generalizar un caso de uso, cosa que suele generar dudas al momento de decidir.
30-09-09 a 7:42 pm
Cordial saludo, soy nuevo en este blog, y me ha parecido muy didáctico, me gustaría ver mas ejempos para concretar los conceptos, deseables en la parte comercial.
Gracias
6-10-09 a 10:22 am
Hola, muchas gracias por el esfuerzo.
No veo claro la relación de extensión dibujada como está. Yo creo que la flecha debe apuntar al revés. Según lo expresado el CU Compra Articulo es una funcionalidad que extiende la funcionalidad definida en el CU Compra Masiva.
El cliente corporativo podrá utilizar ambas opciones, podemos pensar que su opción principal es la Compra Masiva pero que opcionalmente puede utilizar la Compra de Artículos.
Para mí, como he dicho, el CU Compra Artículo extiende al CU Compra Masiva.
Espero vuestros comentarios.
Muchas gracias.
19-10-09 a 5:04 am
Saludos Ángel. Gracias por el comentario.
He revisado mi post y tu comentario en detalle. En un primer momento pensé que pudieras estar señalando una incongruencia entre la definición y el ejemplo, pero luego de revisar me he dado cuenta que tienes en mente algo distinto.
Vayamos por partes.
Ya es claro que no lo vemos de la misma forma. En el post he dado una definición y el ejemplo esta construido de acuerdo con esta.
Según dicha definición, el caso de uso base no se modifica, en tanto que el caso de uso que extiende tiene una flecha que apunta al caso base. El diagrama muestra justamente las flechas en ese sentido.
Si lo que me señalas es que el concepto esta mal, entonces espero tengas a bien partir de un concepto que puedas compartir conmigo, para que juntos podamos ver las coincidencias y las diferencias, así como los pros y contras de cada definición.
En tanto, me parece interesante que digas que el actor que activa el caso de uso extendido puede tener también el derecho a activar el caso de uso base. Esto es curioso y rompe con mi interpretación sobre la activación y sobre el papel que puede jugar la herencia de actores en la organización de un modelo de casos de uso.
Según como yo lo veo, una relación entre casos de uso no compromete que actor puede o no, utilizar estos. Hacer lo contrario llevaría a un modelo de casos de uso donde algunos actores activan funcionalidad sin que se exprese claramente, lo cual lleva a problemas de legibilidad.
Quizás lo que ocurre es que tienes una idea radicalmente diferente sobre la relación de extensión, por lo que te vuelvo a invitar a que compartas tu definición de esta, sobre todo a la luz de una exposición coherente del método completo, como lo intento yo.
Si yo adoptará el concepto tal como creo que lo tienes tú, veo una cierta redundancia o superposición con la relación de inclusión.
Verás, las reglas que doy, según las cuales la relación de extensión siempre es entre casos de uso concretos, en tanto que la relación de inclusión es entre un caso de uso concreto y un fragmento, son reglas que buscan dar un orden a los modelos y evitar la duda sobre cuando es posible utilizar una u otra relación.
Entonces, espero podamos seguir conversando sobre este tema.
Escribe un comentario
ClustrMaps
15-07-08 a 6:05 am
Jo, habeis explicado una cosa sencilla de una forma sencilla y entretenida. Es la explicación más clara que he leido hasta ahora (la gran mayoría, aburridas y confusas)