Casos de Uso Avanzados: Relación de Extensión

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:

  1. Hay cuando menos un caso base y un caso extendido.
  2. El caso base no se ve modificado por la existencia del caso extendido.
  3. El caso base es un caso concreto atado a cuando menos un actor.
  4. 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.

, , , , , , , , , , , , ,

  1. #1 por Ángel el 15-07-08 - 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)

  2. #2 por Rarenas el 18-08-08 - 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.

  3. #3 por Iván Garcerant el 18-08-08 - 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.

  4. #4 por Francisco Calderón el 7-11-08 - 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.

  5. #5 por Iván Garcerant el 8-11-08 - 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.

  6. #6 por Alvaro Martínez el 21-05-09 - 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 !…

  7. #7 por Iván Garcerant el 25-05-09 - 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.

    • #8 por Alvaro Martínez el 25-05-09 - 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 !…

      • #9 por Iván Garcerant el 25-05-09 - 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.

  8. #10 por Marcelo el 1-07-09 - 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.

  9. #11 por Miguel Jaramillo el 30-09-09 - 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

  10. #12 por Ángel Luis el 6-10-09 - 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.

    • #13 por Iván Garcerant el 19-10-09 - 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.

  11. #14 por makiolo el 1-12-09 - 8:53 am

    muchas gracias por tu explicación ;D

    • #15 por makiolo el 3-12-09 - 3:02 pm

      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.

      • #16 por Iván Garcerant el 5-12-09 - 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.

  12. #17 por Esteban Luengo el 3-03-10 - 6:07 am

    Hola Iván, he llegado a este post desde la wikipedia. La definición de extend que realizas no es del todo correcta y tampoco los ejemplos que proporcionas. He estado mirándome la especificación UML y consultando otras webs que te adjunto, incluido la definición de la wikipedia sobre casos de uso.
    http://en.wikipedia.org/wiki/Use_case_diagram#Extend
    http://www.sparxsystems.com/resources/tutorial/use_case_model.html
    http://www.agilemodeling.com/artifacts/useCaseDiagram.htm

    La definición dice que cuando un caso de uso B posee gráficamente una fecha con la etiqueta <<extend>> hacia un caso de uso A,
    <<extend>>
    (A) <—————– (B)
    lo que denota es que puedes, bajo ciertas circunstancias, ejecutar B como paso previo o durante la ejecución de A o dicho de otro modo, el caso de uso B puede ser ejecutado en algún momento cuando activas el caso de uso A pero no necesariamente siempre.
    Por ejemplo, en el primer enlace que se muestra un caso de uso Register (caso B) con una fecha hacia el caso de uso Login (Caso A) lo que significa es que durante el proceso de Login puede ser que necesites ejecutar el proceso Register porque no estás dado de alta en la Web.
    <<extend>>
    (Login) <—————– (Register)
    Otro ejemplo:
    <<extend>>
    (Modificar pedido) <———————— (Obtener aprobación)
    Obtener aprobación puede ser ejecutado bajo ciertas circunstancias de modificar un pedido, entonces obtener aprobación extiende modidicar pedido.
    Explicas que el caso de uso B extiende a A porque se incorpora la funcionalidad de A sin ser alterada cómo parte de B, pero eso no es cierto porque el caso de uso Login no se incorpora en el caso de uso Register ni el caso de uso Modificar Pedido se incorpora en Obtener aprobación. La relación de extend lo que denota es la ejecución condicional entre casos de uso bajo ciertas circunstancias. La relación de aprovechamiento de casos de uso es la relación <> que denota que siempre que ejecutas B ejecutas A pero A no depende de B (por ejemplo no usa variables de A), es decir reutilizas código:
    <<include>>
    (A) <——————– (B)
    (A) <——————– (C)

    Un saludo.

    • #18 por Iván Garcerant el 3-03-10 - 8:57 am

      Saludos Esteban.

      Primero, te quiero agradecer tu comentario y el visible esfuerzo que has puesto al argumentar tu punto de vista. Lo que has hecho es signo indudable de un buen profesional y de una persona propensa al análisis así como abierta al debate.

      Te comento, que en la industria del software vas a encontrar muchos conceptos que son relativos a la opinión y la práctica de cada uno. En este sentido los conceptos del blog están construidos de forma tal que funcionen juntos, como un todo orgánico, incluso si esto significa que se alejen de lo dicho en algunas fuentes de interés general.

      Sin embargo, en este punto particular, no me he alejado solo, o más bien, no me he alejado en una dirección escogida por mí. Estoy acompañando a Ivar Jacobson, figura importante en estos asuntos por haber inventado (él y su equipo) el concepto mismo de caso de uso.

      Si dedicas un tiempo a la lectura de un artículo de Jacobson, cuyo link te copio más abajo, encontrarás lo siguiente:

      A use-case model of a software system contains basically four kinds of use cases:

      •Concrete use cases that can be instantiated (abstract ones can’t).
      •Generalization use cases that support reuse of use cases.
      •Extension use cases that add behavior to an existing (or presumed) use case, without changing the original use case.
      •Inclusion use cases that add behavior to other use cases by changing them.

      Fuente: Use Cases: Yesterday, Today, and Tomorrow

      Lo que dice sobre los casos de uso extendidos y los casos de uso incluidos, corresponde a mis definiciones de extensión e inclusión de casos de uso.

      Es decir, si bien lo que has citado es correcto, corresponde a una visión “no tan avanzada” como la que señala Jacobson, al menos si damos por buena la opinión de este, y por otra parte, es mi opinión, que los conceptos que has copiado son inherentemente difíciles de aplicar, tienden a causar confusión y en general, desplazan la atención de los casos de uso de la especificación escrita al diagrama.

      De momento no puedo concluir mucho más. Mi posición es respaldada por mi investigación en fuentes primarias, la cual avala tanto mi definición como el uso que recomiendo dar a estos conceptos. Espero que lo veas como una postura abierta al debate, pero no menos de bien argumentada que la tuya.

      Espero que podamos seguir con el tema.

      • #19 por Esteban L. el 3-03-10 - 5:11 pm

        Ivan, creo que vamos a iniciar un interesante debate. Yo estoy de acuerdo con el enlace que apuntas de Jacobson pero sigo pensando que la definición que haces no es la misma. Él indica, cómo bien has puesto, que en la relación de extend se añade comportamiento a un caso de uso ya existente. Bajo esta premisa se tiene que tener en cuenta que este nuevo caso de uso, digámosle B, que añade comportamiento a un caso de uso, digámosle A, puede que se ejecute y puede que no. Está claro que el caso de uso A se puede ejecutar por si sólo y está claro que el caso de uso B puede que se ejecute pero puede que no lo haga. Sacando la definición que Jacobson hace.

        First you describe the basic (mandatory) behavior, and then you add extra (mandatory or optional) behavior.

        En la misma Web de IBM puedes encontrar una definición también que coincide con la Jacobson y que argumenta las razones por las cuales puedes usar extend.

        http://publib.boulder.ibm.com/infocenter/rtnlhelp/v6r0m0/index.jsp?topic=/com.ibm.xtools.modeler.doc/topics/cextend.html

        Concretamente cuando dice

        You can add extend relationships to a model to show the following situations:

        A part of a use case that is optional system behavior
        A subflow is executed only under certain conditions
        A set of behavior segments that may be inserted in a base use case

        Y fíjate el ejemplo del final que es basicamente parecido a los ejemplos que te indico:

        You are developing an e-commerce system in which you have a base use case called Place Online Order that has an extending use case called Specify Shipping Instructions. An extend relationship points from the Specify Shipping Instructions use case to the Place Online Order use case to indicate that the behaviors in the Specify Shipping Instructions use case are optional and only occur in certain circumstances.

        extend
        Place Online Order <————— Specify Shipping

        Es decir, tienes un caso de uso Place Online Order y añades comportamiento llamado Specify Shipping Instructions que puede que se ejecute y puede que no.

        Bajo esta investigación me induce a pensar que la relación de extend puede usarse para diferentes propósitos cómo argumentan en IBM en la documentación sobre UML en Rational y que te he indicado anteriormente, pero centrándonos en la definición que das, dices que:

        Un caso de uso extiende a otro cuando sin alterar a este, se incorpora su funcionalidad como parte integral del primero.

        Yo no creo que el objetivo sea incorporar funcionalidad de caso de uso base (A) en el caso de uso extendido (B) sino que el caso de uso B añade comportamiento para hacer más cosas pero no incorpora la funcionalidad, para mí no es lo mismo. Luego en la descripción de la funcionalidad comentas que:

        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”).

        Tampoco creo que sea correcto, puesto que A no se aprovecha en B sino que B simplemente, y vuelvo a repetirme, añade comportamiento y puede ejecutarse bajo ciertas circunstancias.

        Fíjate que Jacobson dice: Extensions are not just a technique for describing optional behavior (optional, that is, from the customer's point of view); they also describe mandatory behavior in a structured way.

        Exacto, el objetivo de extension es describir cuando un caso de uso es obligatorio y cuando otro puede ser opcional u obligatorio bajo ciertas circunstancias. Poniendo en la web de Jacobson el ejemplo que da:

        let us assume that the base use case is a bank transaction:Conduct Transaction. Every time a transaction fails, the bank wants to register this event to make it available to some other concrete use case.

        extend
        Conduct Transaction<————- Register Fail

        Register Fail añade comportamiento a Conduct Transaction porque puede ser ejecutado bajo ciertas circunstancias cuando se ejecuta Conduct Transaction, por ejemplo cuando se produce un fallo.

        En tu ejemplo, Compra masiva no se ejecuta bajo ciertas circunstancias cuando se ejecuta compra articulo por lo que considero que no debe tener una relación de extend a pesar de que es totalmente cierto que añade comportamiento a compra de articulo, pero cuando se compre un artículo por parte de un cliente final no se ejecutará compra masiva por lo que no añade comportamiento desde el punto de vista del Cliente Final y por ello no existe esta relación de extend.

        Un saludo y me alegra poder debatir sobre estos temas🙂

  13. #20 por Iván Garcerant el 4-03-10 - 2:21 am

    Saludos de nuevo Esteban.

    Aquí la idea clave creo yo, es el significado que debemos dar a “añadir funcionalidad”. Añadir lo has usado varias veces y creo que nuestras diferencias se resumen en como hemos de entender esa frase.

    Cuando tenemos un caso de uso concreto, es decir, cuando tenemos un caso de uso que es activado por un actor, debemos entender lo especificado en el caso de uso como un contrato. Y como todo contrato hemos de respetarlo y no adulterarlo de modo alguno.

    Entonces, cuando extendemos un caso de uso concreto, añadimos funcionalidad, pero dicha funcionalidad no puede afectar lo que hemos prometido al actor del caso base. Entonces, la funcionalidad añadida ha de estar necesariamente, en el caso extendido, disponible para ser activado por nuevos actores.

    Cuando tenemos un caso de uso A, que es extendido por un caso de uso B, lo que hemos añadido queda en B. Es decir entonces, que B se ha beneficiado de lo dicho en el caso de uso A, pudiendo ser visto como una forma de reutilización.

    Es interesante que el ejemplo que citas de Jacobson sea de hecho, parecido al que tengo en el post. Hay una operación comercial que ya esta definida, que se ha entendido por completo y que se ha prometido ya. En este ejemplo, el caso de uso “Compra artículo” es un contrato de funcionalidad, que nuestro cliente requiere este disponible para los compradores finales.

    Luego, se añade funcionalidad, por ejemplo, la posibilidad de programar compras a plazos, dicha funcionalidad añadida queda en el caso de uso “Compra masiva” y esta disponible para que alguien más la utilice (o bien el mismo actor). En mi ejemplo, el nuevo caso de uso construido parcialmente con lo dicho en el caso de uso “Compra artículo” es de interés para los compradores corporativos, pero no para los compradores finales.

    Dado que en el tiempo, el caso de uso “Compra masiva” se identifico y especifico luego que ya teniamos listo al caso de uso “Compra artículo”, pudimos aprovechar el trabajo ya hecho para facilitarnos la nueva definición.

    Es decir, hemos reutilizado la especificación del caso de uso que ya teniamos, para construir un nuevo caso de uso con funcionalidad añadida.

    Al menos así lo veo yo. Me es grato conversar de estos temas en detalle. Espero que también tengas a bien revisar mi post sobre la relación de inclusión para que veas como trabaja ella, y podamos tener una visión de conjunto.

  14. #21 por Esteban Luengo el 4-03-10 - 3:43 am

    Creo que ya veo nuestros puntos claros de discrepancia. Precisamente cuando dices:

    Cuando tenemos un caso de uso A, que es extendido por un caso de uso B, lo que hemos añadido queda en B. Es decir entonces, que B se ha beneficiado de lo dicho en el caso de uso A, pudiendo ser visto como una forma de reutilización.

    Para mi eso no es así. B, nada se aprovecha de A puesto que B es totalmente independiente de A. El que se aprovecha realmente es A, porque se añade comportamiento de forma separada sin alterar a A. Es el principio básico de la programación orientada a aspectos. Según Jacobson:

    Again, we need guidelines: We usually use the extend relationship only when the extension use case is completely separate from the extended base use case.

    Lo dice claro, B es completamente independiente de A. Es aquí donde creo que discrepamos, pero bueno, está bien tener puntos de vista diferentes porque enriquece. Gracias por el debate y enhorabuena por el blog. Me lo apunto en los blogs que sigo habitualmente😉

    • #22 por Iván Garcerant el 4-03-10 - 4:49 am

      Bueno, me alegra que tengamos la diferencia clara.

      Ahora, que no comprendo como el caso extendido “B” pueda añadir funcionalidad al caso “A”, pero a la vez, sin que esto signifique una violación del contrato o especificación que se había acordado originalmente en “A”.

      Otro problema que veo, es que en la aproximación que sugieres, el caso “B” queda como fragmento, pudiendo su contenido se activado o no por un actor. Esto hace la relación identica a la relación de inclusión, y si no hay diferencias reales entre estas dos, pues para que conservar ambas?

      Otro punto relacionado, que me gustaria que comentaras, es el ejemplo que pones de Jacobson y que copio a continuación:

      let us assume that the base use case is a bank transaction:Conduct Transaction. Every time a transaction fails, the bank wants to register this event to make it available to some other concrete use case.

      extend
      Conduct Transaction<————- Register Fail

      Register Fail añade comportamiento a Conduct Transaction porque puede ser ejecutado bajo ciertas circunstancias cuando se ejecuta Conduct Transaction, por ejemplo cuando se produce un fallo.

      Pienso que ese un claro ejemplo de mal uso de la relación de extensión. Incluso viniendo de Jacobson me parece un mal uso. Veo como más simple y más correcto, el poner el requisito de registrar la falla en alguna sección del caso de uso “Conduct Transaction”, beneficiandonos entonces de tener la especificación en un solo lugar y a la vez, teniendo un diagrama más simple.

      De obrar como digo, “Register fail” sería un flujo de eventos alternativo. Una solución que encuentro más simple y legible.

      Además tengo dudas sobre como se sabe que caso de uso es activado por un actor, en el enfoque que sugieres y que parece sugerir el ejemplo que comentamos, un “caso extendido” puede o no puede ser ejecutado por un actor y añade funcionalidad a un caso de uso existente sin respetar los posibles otros actores que instancien al caso de uso base.

      También en el mismo sentido, encuentro la frase “puede o no puede” algo poco firme. Es como no asegurar nada.

      Mi conclusión aquí, es que yo hago un uso más intenso de las partes de texto de los casos de uso, encontrando de esta forma que no necesito hacer anotaciones en mis diagramas. La otra posibilidad que me haces pensar encuentras atractiva, es intentar colocar los detalles en el propio diagrama UML, una tentativa que encuentro común pero que considero errada.

      Es decir, en nuestro debate, ahora te toca a ti el explicar tus ideas.🙂

  15. #23 por makiolo el 4-03-10 - 7:38 am

    Buenas:

    Hola Iván Garcerant , gracias por el comentario que me hiciste haya por diciembre.. Lo leí inmediatamente, pero al final por una cosas o por otros olvide darte las gracias.

    Os escribía este comentario para comentar que sigo atento vuestro hilo de batalla épica.

    No se trata de demostrar quien es el más gallito, se trata de argumentar un tema y que cada uno saque sus propias conclusiones.

    Un saludo. Ricardo

    • #24 por Esteban Luengo el 4-03-10 - 8:26 am

      Ricardo, gracias por tú interés. De verdad que no quiero aparentar si soy más gallito o no que Ivan y si esa es la imagen que damos pues lo siento porque no es mi intención. Creo que la idea precisamente es que cada uno tiene un enfoque de la relación extend diferente y creo que hemos dado cada uno ejemplos y argumentos para defender nuestra idea de lo que consideramos que es la relación extend, incluso sacando referencias directas de la propia definición del creador. No hay nada más.

      Un saludo.

    • #25 por Iván Garcerant el 5-03-10 - 2:50 am

      Saludos Makiolo.

      Yo espero que un debate basado en argumentos y que se mantiene civilizado sea visto como algo positivo y no como un conato de pelea.

      Si lo has visto como un intercambio aireado o negativo en alguna forma, pues no ha sido esa mi intención. Estoy con Esteban cuando digo esto, según leo en su respuesta a tu comentario.

      En todo caso, gracias por tu comentario.

  16. #26 por Adrian el 10-03-10 - 4:13 am

    Leyendo este artículo me surge una duda y es que si es posible tener como extendido un caso de uso, digamos que Eliminar reporte donde el caso base seria Mostrar Reporte. En Mostrar reporte se puede eliminar el mismo.

  17. #27 por Roussel el 26-10-10 - 2:39 pm

    Hola a todos mi nombre es Roussel , mi email es roussel@live.cl , este es el concepto claro de su debate .

    En todos se reutiliza el codigo

    Extensión: un “caso de uso extendido” se divide y se inserta por partes en un “caso de uso base”.
    por eso mismo se dice que se extiende la insercion
    la extension modifica implicitamente ya que tu decides en un mente donde hacerlo
    se puede modificar los atributos del caso de uso base

    Inclusión: un “caso de uso de inclusion” no se divide y se inserta completo en un “caso de uso base”.
    por eso mismo dice se incluye la insercion de una sola vez
    la extensión es explicito por que lo haces de una sola vez

    Generalizacion: un “caso de uso base o padre” hereda codigo a un “caso de uso de uso hijo” , y haces con las firmas lo que quieras.

  18. #28 por Johann Albert el 28-10-10 - 9:41 am

    muy buena explicacion…. gracias por la claridad se me resolvieron las dudas….

  1. Casos de Uso Avanzados: Relación de Inclusión « Tecnología y Synergix
  2. Ejemplo de caso de uso « Tecnología y Synergix
  3. Todo requisito debe ser preciso y legible « Tecnología y Synergix
  4. Los números de 2010 « Tecnología y Synergix

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: