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.
19 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.
1-12-09 a 8:53 am
muchas gracias por tu explicación ;D
Una pregunta, vengo de un examen de Ing. del software el cual creo que he aprobado, pero estudiando me ha quedado una duda.
¿Cual es la diferencia entre la extensión y la herencia/generalización?
Es decir, la extensión es una dependencia con un estereotipado. En el origen digamos que esta el caso de uso base y en el destino esta el caso de uso que:
a) añade comportamiento sin modificar el comportamiento del origen
b) añade comportamiento y puede modificar el comportamiento de origen.
La extensión es el a ¿verdad?, si fuera el b, no veo ninguna diferencia con la generalización de casos de uso.
La inclusión la tengo claro.
Otra duda parecida, si no es molestia:
En el diagrama de clases, podemos unir las clases mediante:
1- herencia / generalización, flecha
2- dependencia, linea discontinua
3- asociación, linea continua
¿No es cierto que toda herencia supone dependencia? ¿Cuando se usa la dependencia sin estereotipo alguno? Es decir, por lo que veo, en los diagramas de clase, normalmente se usa el 1 y 3, es ¿asi?
Y ya para rayarme finalmente, la asociación indica navegabilidad entre 2 clases, ¿eso no es tambien dependencia?
Me dio por pensar que la dependencia se puede usar para cuando depende del interfaz de la clase, y tener verificado y controlado el efecto onda al modificar una clase.
En fin, aprobaré el parcial sobre esto, pero no estoy seguro si he aprendido aún xD
un saludo.
5-12-09 a 4:47 am
Makiolo, vaya que pregunta la que haces. Preguntas como las tuyas me dicen que vas a salir muy bien en tu examen. Tener la capacidad de ver críticamente un asunto académico es vital para hacer la transición hacia ser un buen profesional.
Vamos a abordar tu pregunta por pedazos.
¿Qué diferencia la extensión de la herencia de casos de uso?
Verás, aquí lo primero que debes tener en cuenta es que primero fue la herencia. Cuando la técnica de casos de uso se popularizó por primera vez, la idea era dotarla de los conceptos propios de la orientación a objetos, tales como instanciación y herencia, con el fin de alinearla la técnica de gestión de requisitos por casos de uso con el análisis y diseño orientado a objetos, que era popular en aquellos días.
Esto significa que la relación de herencia se incorporó a los casos de uso no como reacción a una necesidad de la técnica, sino como un impulso de hablar en los mismo términos que el resto de la industria. Por esto no nos debe sorprender que seamos capaces de ver problemas e incoherencias en el modelado de casos de uso cuando hablamos de la herencia.
Explicado esto, mi punto de vista es que originalmente toda reutilización de un caso de uso se debiera hacer por medio de la herencia. Sin embargo aquí surge un problema práctico. Ya que lo casos de uso son principalmente elementos de textos, a saber: la descripción breve, nombre propio, el flujo de eventos, las precondiciones y las postcondiciones; se debe explicar de que forma estos elementos interactuan a la hora de la herencia. Es decir, se debe proveer una explicación clara y completa de que hacer con los flujos de eventos y demás elementos del caso “madre” a la hora de escribir el caso “hija”.
Además, por la propia interpretación que se tiene de lo que es la herencia, lo casos de uso derivados podían hacer tanto como quisieran con la información del caso madre, de forma tal que no era posible saber a priori lo que se había hecho. Esto le resta legibilidad a los diagramas de casos de uso, ya que dos casos de uso ligados por herencia pueden en verdad, tener cualquier relación que se nos pueda ocurrir.
De cierta forma, la relación de herencia es demasiado poderosa y a la vez, muy poco precisa, como para utilizarla frente a los clientes con sus casos de uso.
Es por esto que con el paso del tiempo, la especificación de un caso de uso ha migrado, del uso de la herencia al uso de relaciones más limitadas, como la extensión.
Siguiendo en esta línea, es probable que veamos también cambios en las relaciones de extensión e inclusión en los próximos años.
En lo personal, solo utilizo la relación de herencia entre casos de uso cuando quiero cambiar la naturaleza de un artículo o elemento que se ha nombrado en el caso base. Por ejemplo, el caso de uso “comprar artículo” le puedo aplicar herencia para obtener el caso de uso “comprar periódico”. Pero incluso en este caso, sería preferible enfocar el problema de otro modo.
Sobre las relaciones entre clases.
Los modelos de clases son construidos con dos elementos fundamentales: las clases y las relaciones entre estas. En el UML se tiene el supuesto que todo modelo puede ser creado como relaciones entre pares de clases, un supuesto que en la práctica se sostiene bien, pues nuestros modelos suelen ser redes de clases conectadas de a pares.
Ahora bien, no es lo mismo “ser” que “tener”. Esta diferencia propia de la lógica humana se representa en los modelos de clases por medio de las relaciones de herencia y agregación, siendo ambas, formas especializadas de dependencias entre clases.
Es decir, según el estándar de UML, tanto la herencia como la agregación/composición son dependencias de un cierto tipo especial.
Si partimos de la relación de dependencia, veremos que efectivamente todas las demás relaciones significan cierta dependencia. Siendo la herencia la relación con el tipo más fuerte de dependía posible. Disculpen el uso repetitivo de la palabra dependencia.
Por otra parte, la mera dependencia no puede suplir el rol de una relación de herencia.
Es interesante también ver el desarrollo de la ingeniería del software en relación con este punto. Hoy en día, con todas las teorías de patrones de diseño y frameworks de desarrollo, se suele preferir el uso de la relación de agregación/composición por sobre la herencia. Al tener la agregación/composición un menor grado de dependencia, se dice que también tiene un menor grado de acoplamiento, por lo que las propiedades del diseño resultante son mejores para las necesidades de la ingeniería.
Quizás, a medida que avancemos, podamos ver un uso cada vez más preferente de la dependencia simple. Cierto es que esta tendría un menor acoplamiento aún, pero aún se requiere el desarrollo de ambientes más abstractos que lo permitan. Quizás un día podamos especular un poco más al respecto.
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)