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

El modelado de casos de uso persigue capturar la funcionalidad del sistema visto desde el punto de vista de sus operadores -actores- por lo que es fundamentalmente una construcción de elementos de modelado comprensibles por los clientes -stakeholders- y no solo por los analistas.

Sin embargo, en ocasiones es conveniente introducir algunos pocos elementos que no sean directamente los conceptos que manejan los clientes. Por ejemplo, en aras de evitar la redundancia, es posible pensar en extraer algunos fragmentos que nos permita indicar en uno o más casos de uso este fragmento repetido, por referencia en lugar de repetirlo en cada caso.

A este proceso de extracción del fragmento repetido lo modelamos por medio de la relación de inclusión <<include>>, tal como se ve en el siguiente diagrama:

Fig. 1 - Relación de inclusión entre casos de uso

En la figura, el caso de uso “A” es un fragmento, que define un trozo de un flujo de eventos que es referido por el caso de uso “B”. En este tipo de relación, el caso incluido (el “A”) debe ser un fragmento, nunca un caso concreto, en tanto que el caso que incluye (el “B” del ejemplo) si ha de ser un caso de uso completo.

A diferencia de la relación de extensión, aquí ninguno de los casos de uso involucrados puede ser entendidos por completo como piezas aisladas. Por un lado, el caso incluido es solo un fragmento, por lo que no es posible considerarlo un caso de uso pleno; en tanto que el caso que incluye al hacer referencia a un fragmento externo tiene necesariamente que ser entendido en presencia del fragmento.

Formalmente, como para el glosario:

Relación de Inclusión <<include>> Un caso de uso concreto incluye a un fragmento de caso de uso, cuando como parte de su descripción breve o su flujo de eventos, se hace referencia al texto del fragmento; de forma tal que lo dicho en el fragmento pasa a ser parte de la especificación del caso de uso.

Para lograr que se entienda el concepto, nada mejor que un ejemplo. Supongamos que estamos hablando de un sistema de gestión de agenda de un empresas con gerentes y asistentes. En este sistema hemos identificado dos casos de uso:

Código: UC-0100.
Nombre: Acepta cita.
Actor: Gerente.
Descripción: El Gerente visualiza su calendario de citas y aprueba aquellas citas que desee aceptar.

Código: UC-0200.
Nombre: Coordina cita.
Actor: Asistente.
Descripción: El asistente busca un momento apropiado para las citas pendientes al visualizar el calendario de citas del Gerente. Indica para cada cita propuesta la descripción, el día y la hora.

Tabla 1 - Casos de uso del sistema

Como se nota, en ambos casos se requiere de visualizar la agenda. Es posible imaginar que esta función abarca no solo la visualización del calendario, sino también ciertas funciones de búsqueda y filtrado por criterios. Para especificar esta funcionalidad pero evitar hacerlo en cada uno de los flujos de eventos de los casos de uso ya definidos, se opta por crear un fragmento que contenta esos detalles e incluirlo en los casos de uso originales. La situación da lugar al siguiente diagrama:

Fig. 2 - Modelo de casos de uso con un
ejemplo de relación de inclusión

De esta forma, evitamos tener que definir en múltiples lugares una misma funcionalidad. Sin embargo, el fragmento que se incluye ha de ser visto siempre como lo que es: un fragmento sin significado completo. En verdad es una lastima que de momento no tengamos una forma de marcar a los fragmentos de manera que se diferencien a simple vista de los casos de uso. Sugiero que al menos, en tanto surge un estereotipo estándar para esta tarea, tengamos una serie de numeración particular para los fragmentos. O bien, tomar la iniciativa y definir un estereotipo de UML por nosotros mismos.

Naturalmente que a la hora de hacer la especificación detallada de los casos de uso, en particular en los flujos de eventos, debemos marcar muy claramente en que lugar se ha de realizar la inclusión de lo dicho en el fragmento.

La relación de inclusión es claramente diferente a la relación de extensión y espero que haya quedado claro. La inclusión es una relación entre un caso de uso concreto y un fragmento, en tanto que la extensión involucra casos de uso concretos.

Por otra parte, a diferencia de la relación de extensión, la inclusión en cierta forma modifica al caso que incluye, por cuanto el fragmento define una parte de la funcionalidad del caso de uso completo. Esto significa que el caso de uso que incluye no puede ser entendido por completo en ausencia del fragmento que se incluye; algo muy diferente a la situación en una relación de extensión.

About these ads

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

  1. #1 por Javier Seixas el 27-03-09 - 4:35 am

    Felicidades por este artículo y por los demás que tratan esta temática de los casos de uso. Están muy bien explicados y son fáciles de entender. Acabo de llegar a este blog desde la Wikipedia, y voy a agregar su rss a mi netvibes ahora mismo. Un cordial saludo!

  2. #2 por Guillermo Lengemann el 22-04-09 - 5:22 pm

    Saludos, te felicito por el contenido del blog, es de gran ayuda. Ademas, quisiera recomendar el cambio del color de la fuente del texto, me ocurre que después de un rato es algo incomodo leer.

  3. #3 por Alvaro Martínez el 21-05-09 - 6:51 pm

    La explicación de la relación inclusión es muy clara, según el libro de UML y Patrones lo importante cuando se modela casos de uso son los flujos de eventos mas que desgastarse en construir un gráfico de casos de uso y relaciones, en la práctica puede es conveniente adoptar esta metodología ???, y para terminar: cuando se construye un diagrama de casos de uso, se recomienda, cuando se intenta modelar las relaciones, comenzar con las de inclusión y extensión y por último las de asociación, con este proceso logramos una mejor especificación ???, de antemano mil gracias por tus explicaciones y estaré pendiente a tus artículos, °-)

  4. #4 por Iván Garcerant el 25-05-09 - 3:42 am

    Saludos Alvaro.

    Efectivamente, la parte realmente importante de un caso de uso es su descripción breve y su flujo de eventos. Contar con un buen diagrama es un recurso agradable pero jamás será la parte primordial de un caso de uso bien construido.

    Por lo mismo, al modelar requisitos con casos de uso, se debe comenzar por identificar a los actores, planteando para cada uno de ellos la pregunta “¿qué debe hacer el sistema para atender las necesidades de este actor?”. A cada una de las posibles respuestas las llamaremos caso de uso.

    En este punto, tendríamos un grupo de actores y algunos casos de uso para cada uno de estos. Es decir entonces, que tendríamos el modelo de caso de uso a medio hacer y no tendríamos ni una sola relación de inclusión ni de extensión.

    ¿Cuando tienen sentido las relaciones de inclusión y extensión? Es la siguiente pregunta lógica.

    Mi respuesta a esta pregunta es muy simple: solo cuando la situación real lo exija. No es posible prever una regla universal sobre la aplicación de estas relaciones, salvo reconocer que suelen ser sobre utilizadas por los analistas novatos y algunos profesores desorientados.

    Para que tengas alguna guía, te digo que el modelo de casos de uso jamás es su diagrama. Siempre lo más importante son las descripciones breves y flujos de eventos de cada uno, quedando los diagramas como una forma agradable de estructurar el conjunto. Por lo tanto, no intentes expresar tus ideas por medio de relaciones de inclusión o extensión, hasta en tanto no hayas agotado las posibilidades de expresarlas por medio de la descripción breve y el flujo de eventos de tus casos de uso.

    • #5 por Alvaro Martínez el 25-05-09 - 9:28 pm

      Miles de gracias por despejarme mi duda, y ojalá pueda colaborar en este espacio con algunos aportes, saludos !…

  5. #6 por Juan Ramirez el 7-09-09 - 2:13 pm

    Gracias por facilitar la informacion, me ha servido de mucha ayuda a mi proyecto!! Dios les bendiga, Cristo les ama!!!

  6. #7 por Jess el 20-12-09 - 2:09 pm

    Serian tan gentiles de decirme si un caso de uso puede incluir a un caso de uso de otro actor? Un ejemplo, por favor. Gracias!!!

    • #8 por Iván Garcerant el 20-12-09 - 7:47 pm

      Saludos Jess.

      Un caso de uso es un escenario de interacción entre un ente externo al que llamamos actor y el sistema. Se representa con un ovalo y sus partes más importantes son la descripción breve y el flujo de eventos, que son elementos de texto que no se ponen en los diagramas.

      Todo esto lo digo para que veas que los casos de uso hasta cierto punto, son reutilizables entre diversos actores. Se puede dar el caso en que hagas un diagrama donde pones un actor y un caso de uso y que luego de tiempo, te encuentres haciendo otro diagrama con el mismo caso de uso pero con un actor diferente.

      Si te pasa lo anterior, lo que estarás haciendo es reutilización, algo que en líneas generales es siempre bueno.

      Si estas reutilizando, te aconsejo que hagas diagramas diferentes para cada actor, esto a fin de evitar la posible confusión de quien vea tu diagrama. Recuerda que el conjunto de casos de uso son un modelo y que los modelos pueden tener muchos diagramas.

      Ahora que si te refieres específicamente a la relación de inclusión, tendrás que decidir si sigues mi concepto de fragmento, en cuyo caso tendrías que incluir siempre un fragmento que como en el diagrama de ejemplo de este post, no puede ser activado por un actor.

      Si abandonas la idea de fragmento, seguro podrías incluir un caso de uso activado por otro actor. Pero en este caso nada evita que venga alguien más y haga lo mismo, pero con la relación de extensión…

      Espero me haya podido dar a entender. Cualquier cosa por favor pregunta de nuevo.

      Iván.

  7. #9 por Marina el 23-01-10 - 2:04 pm

    Buenas tardes, justamente eso es lo que quisiera determinar, si los casos de uso extendidos e incluidos no se relacionan con los actores nunca….es decir, no existe una relacion entre el actor y estos casos???….la relacion solo seran con sus clase bases?…Gracias

    • #10 por Iván Garcerant el 25-01-10 - 1:01 pm

      Saludos Marina.

      Si sigues mi política de utilizar solo fragmentos de casos de uso a la hora de incluir, y solo casos de uso concretos a la hora de extender, la respuesta sería muy simple:

      Si se usa <<include>> el fragmento incluido no puede guardar relación con un actor.

      Si se usa <<extend>> el caso de uso extendido puede guardar relación con un actor.

      Espero te quede claro. Cualquier cosa, no dudes en dejar un comentario.

      Iván.

      • #11 por Marina el 25-01-10 - 1:44 pm

        Qdo Clarisimo :)….gracias por su tiempo :)…..DIOS LO BENDIGA

  8. #12 por Dariana el 25-01-10 - 1:48 pm

    Hola, quisiera por favor me diga si un CU: Imprimir Reporte, puede ser considerado como tal….cuando si o cuando no…y si es un caso de uso extendido de otro………………gracias!!!!!!!!!!!!!

    • #13 por Iván Garcerant el 25-01-10 - 2:03 pm

      Saludos.

      En líneas generales, un buen caso de uso es un tanto más general. Funcionalidades tales como “Imprimir Reporte” son en verdad muy especificas y se corre el riesgo de dedicar mucho tiempo a modelar cosas que ya todos sabemos, como “Abrir Archivo” o “Cerrar Sesión”.

      Esto es en líneas generales, claro. Casi siempre nos conviene que los casos de uso sean más generales.

      Ahora bien, puede suceder que nuestros clientes encuentren importante el detalle de la impresión del reporte. Quizás es una necesidad apremiante de un negocio especifico o haya alguna otra razón que justifique el dedicar un caso de uso a lo que por otra parte hubiera sido una funcionalidad obvia. Si se da esta situación, entonces habrá de tener un caso de uso “Imprimir Reporte” ya que captura una necesidad de negocio… una necesidad que por alguna razón que ahora no alcanzamos a imaginar, preocupa a nuestros clientes.

      Luego, decidir si es una extensión es cosa de saber con que contamos. De tener un caso de uso base ya desarrollado, podemos pensar en reutilizar este por medio de la extensión de casos de uso. De igual forma, de tener un fragmento que nos pueda servir, podremos hacer una relación de inclusión. Lo que es oportuno decir aquí, es que tanto la relación de extensión como la de inclusión, son mecanismos para la reutilización de algo que ya tengamos. Si estos ya existen y nos son útiles, los podemos usar de nuevo, pero si nos los tenemos, entonces empezamos de cero y nos quedaremos con un caso de uso simple, sin relaciones exóticas que nos compliquen la vida.

      Cualquier cosa, me avisas si te quedan dudas.

      Iván.

  9. #14 por Dariana el 25-01-10 - 7:08 pm

    Hola GRACIASSSSSSSSSSSSS!!! por tu respuesta, pero en base a ella se me vino la sgte interrogante: si mi cu “imprimir solicitud” es un caso base, entonces podria decir que podria tener un cu “buscar solicitud” que sea una inclusion a mi caso base????…….

    Es decir, como sé cuando un CU se incluye a otro y no se esta cometiendo un error….xq para efectos, yo podria decir que para imprimir debo previamente buscar aquello que voy a imprimir (q en mi caso seria la solicitud) y eso me diria que tengo una relacion de inclusion……pero acaso dentro del flujo propiamente dicho de la impresion es necesario esta busqueda???….no sera que estoy forzando el contexto tratando de crear una relacion que realmente no existe……esas dudas saltan en mi….ojala me pueda contestar. GRACIASS!!

    • #15 por Iván Garcerant el 26-01-10 - 3:18 pm

      Saludos Dariana.

      Por definición, y quiero comenzar recordando la definición, un caso de uso es un escenario de interacción entre un sistema y un ente externo al que llamamos actor. Dicho escenario se documenta por medio de una descripción breve, con ayuda de un flujo de eventos, quizás sea necesario indicar precondiciones o postcondiciones y ciertamente será útil ponerle un nombre.

      Solo luego de recordar esto, quizás entonces tengamos tiempo de hacer un bonito diagrama utilizando UML, y en tal caso, tendremos un dibujo con el cual documentar nuestros casos de uso, los cuales como ya dije, son fundamentalmente descripciones en texto.

      Quiero que tengamos presente esta definición, para que nos podamos entender que a la hora de expresar un requisito, debemos agotar las posibilidades de expresión de la descripción breve, el flujo de eventos y demás partes de un caso de uso. Cosas como “buscar reporte” quizás sean mejor y más simplemente expresadas con unas pocas frases dentro de la descripción, que por medio de un ovalo en un diagrama.

      Es decir, creo que un caso de uso como “buscar solitud” es demasiado especifico… y que solo tiene sentido cuando debes decir que la solicitud ha de ser buscada pero no has recordado escribir este hecho, sino que pretendes decirlo en el diagrama.

      Plantear nuestras ideas con ovalos y relaciones de inclusión es una forma incorrecta de usar los casos de uso. Primero debes escribir la descripción y demás elementos que te he indicado antes, y solo entonces, cuando tengas casos de uso completos, pensar en posibles relaciones entre ellos.

      En conclusión: escribe “buscar solicitud” como parte del caso de uso “imprimir solicitud”, pero no lo separes en un caso de uso aparte. No te hace falta.

      Iván.

  10. #16 por Dariana el 26-01-10 - 5:43 pm

    Gracias! por su explicacion…..empezare entonces a hacer la descripcion de mis CU antes que todo…….:D

    Ahhh!!! y debo agregar que esta buenisimo su blog…:)

  11. #17 por zarmaitq el 20-04-10 - 12:15 pm

    Excelente explicación, ejemplos muy sencilos de entender gracias :)

  12. #18 por samantha el 13-06-10 - 2:59 pm

    Hola que tal, tengo unos problemillas con mis diagramas de casos de uso, ya tengo la descripcion de cada uno pero el problema es que no se cuando usar la relacion de inclusion y la de extend, es decir tengo 3 casos de uso base y de cada uno de ellos se desprenden mas o menos 5 casos de uso mas, entonces cual debo usar? Agradezco tu respuesta.

    • #19 por Iván Garcerant el 13-06-10 - 9:19 pm

      Saludos.

      No saber cuando usar include y cuando extends es una buena razón para no usar ninguna de ellas. El modelado ha de entenderse bien, sobre todo por aquellas personas que son ajenas al mundo del software como lo son nuestros clientes, por lo que si uno que es el analista no entiende bien cuando va include y cuando extends mucho menos lo van a entender ellos.

      Es decir, trata de simplificar tu modelo de casos de uso hasta el punto en que no necesites características avanzadas como la relación include.

      Ahora, estas relaciones pasan a ser interesantes y muy útiles cuando se trata de reutilizar casos de uso viejos, ya entendidos y bien establecidos. En este nuevo contexto, el de la reutilización, utilizaremos extends cuando partamos de un caso de uso concreto (uno que es activado por un usuario) y utilizaremos include cuando partamos de un fragmento de caso de uso (uno que sale de aislar comportamiento común a dos o más casos de uso concretos)

      Finalmente vuelvo a insistir en que los casos de uso son descripciones de una interacción entre el sistema y un ente externo al que llamamos actor. Dichas descripciones son construidas basicamente con elementos de texto, como la descripción breve y el flujo de eventos; quedando el diagrama UML como una ayuda visual interesante pero que contiene poca información.

      Espero haberte ayudado, cualquier cosa no dudes en volver a preguntar.

      Iván.

      • #20 por samantha el 15-06-10 - 10:45 pm

        muchas gracias!!!!, queda entendido ahora a terminar los diagramas, saludos!!!

  13. #21 por andres el 26-09-10 - 2:16 pm

    me parece que se contradicen ustedes mismos al decir en este post, en el último parrafo:

    Esto significa que el caso de uso que incluye no puede ser entendido por completo en ausencia del fragmento que se incluye; algo muy diferente a la situación en una relación de extensión.

    y en el post de relación extends:

    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.

  14. #22 por Felix el 24-02-11 - 7:47 pm

    Esto no me servio porq estoy en grado 4ºa xD

  15. #24 por Manuel el 17-12-11 - 11:24 pm

    Una pregunta: En la Universidad me dijeron para poder hacer una relación de Inclusión se tiene que tener como mínimo 2 casos de uso Base que necesitan de ese caso de Uso <>, por eso se le llama factorización, Mi consulta es que si lo que me dijeron es correcto, porque yo antes hacia mis diagramas de casos de uso y exactamente mis inclusiones sólo con un caso de Uso que lo necesite y cuando tenia 2 casos de uso Base hacia la factorización. Para complementar me dijeron también que sólo con un caso Base lo necesita no se hace include y eso es tratado sólo como una tarea del Caso de Uso Base.

    • #25 por Iván Garcerant el 5-01-12 - 11:42 am

      Me gusta lo que te han dicho en la universidad. Lo considero correcto, si bien creo que lo has entendido un tanto mal. Por lo que nos cuentas, entiendes a la factorización como algo distinto a la relación de inclusión y la verdad, es que en ingeniería del software se hace la inclusión con el fin de alcanzar un cierto efecto al cual, por analogía a la matemática, se puede llamar factorización.

      Es decir, lo mejor será reservar nuestros intentos de usar la relación de inclusión a la situación de tener al menos, dos casos bases. Si lo hacemos así, el ahorro que obtenemos lo podemos llamar, si queremos, “factorización”, en referencia a lo que hacemos en matemáticas cuando sacamos factores primos comunes de una suma.

      Si solamente tenemos un caso base, en lugar de hacer un nuevo caso de uso e incluirlo, lo mejor es dejar esas actividades como una tarea más del caso base. Justo como te han dicho en la universidad.

      • #26 por Manuel el 5-01-12 - 4:35 pm

        Gracias amigo por la respuesta y confirmación.

  1. Casos de Uso Avanzados: Relación de Extensió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

Deja un comentario

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

Seguir

Recibe cada nueva publicación en tu buzón de correo electrónico.

%d personas les gusta esto: