Casos de Uso: Herencia de Actores

La propiedad de mayor interés de los actores, más allá de su identidad, es la relación que estos guarden con los distintos casos de uso de nuestro sistema – las líneas que unen a unos con otros. Es decir que las dos partes más expresivas de un actor son el nombre propio y la activación de un caso de uso.

Aceptado lo anterior, la herencia de actores va a ser la distribución a lo largo de una jerarquía de roles, de las actividades a realizar, representadas estas como casos de uso. O lo que es lo mismo, la herencia nace como una forma de organizar los enlaces entre actores y casos de uso a fin de simplificar los diagramas y reducir la necesidad de presentar información repetida.

Nuevamente pero algo más técnico: a lo largo de la jerarquía de herencia lo que vamos a organizar son las activaciones de casos de uso de cada actor con ayuda de categorías intermedias o actores abstractos.

A diferencia de la herencia de casos de uso, considero que la herencia de actores es una práctica básica y que no tiene mayor problema en ser entendido por los stakeholders ni mucho menos, presenta problemas a los analistas. La razón es que la dificultad de la herencia de los casos de uso es la definición detallada de como los múltiples elementos de información de un caso de uso se comporta durante la herencia, dificultad esta que no existe en la herencia de actores por ser estos tan sencillos.

Como dije antes, la herencia de actores es una forma legible de mejorar la presentación de nuestros modelos, por lo que ejemplo que daré tiene por motivación el mejorar la legibilidad de un por lo demás, muy sencillo modelo de casos de uso.

A efectos del ejemplo, supongamos que trabajamos con un sistema de ventas, que permite tanto a los promotores como a los empleados del departamento de ventas el visualizar las existencias de productos así como la consignación de mercancía, pero que excluye a los promotores de la posibilidad de aceptar devoluciones. La situación es presentada en el siguiente diagrama de casos de uso:

Ejemplo de modelo de casos de uso sin herencia

Fig. 1 – Ejemplo de modelo de casos de uso sin herencia

Si se observa con atención el diagrama 1, se ve como las líneas de activación se cruzan entre actores. Claro que podemos tratar de organizar un poco mejor el diagrama para evitar esto, pero hemos de reconocer que esto solo será una solución temporal. Conforme se incremente la cantidad de casos de uso nos encontraremos una y otra vez en esta situación. No es solo una cuestión de estética, de utilizar líneas segmentadas bien podríamos llegar a hacer el diagrama por completo ilegible. Es entonces necesario un enfoque alternativo.

Dicho enfoque alternativo naturalmente va a ser la herencia. En el segundo diagrama se ven exactamente los mismos casos de uso y los mismos actores, pero se ha establecido una relación de herencia con respecto a un actor abstracto u operador como estrategia para presentar la información sin tanto barullo de líneas.

Ejemplo de modelo de casos de uso con relación de herencia entre actores

Fig. 2 – Ejemplo de modelo de casos de uso con herencia entre actores

En este segundo diagrama hemos indicado que el operador puede realizar las dos tareas comunes, en tanto que por herencia hemos dicho que los empleados del departamento de ventas son los únicos autorizados a aceptar devoluciones de mercancías. Aquí hay que notar que no he establecido una relación de herencia entre promotor y ventas, sino que por el contrario he introducido un actor abstracto nuevo, que articula la presentación del modelo sin correr el riesgo de equivoco: promotor no es ventas y ventas no es promotor. El hecho que compartan dos casos de uso si es algo digno de mención pero sus identidades siguen por completo desligadas.

La presencia de un actor abstracto puede ser considerada una fuente de ruido a la hora de explicar el modelo, pero dado que es solo para simplificar las líneas de activación encuentro que la sobrecarga de información no es nociva. Por otra parte lo que hemos ganado en claridad es en mi opinión, mucho mayor a lo que hemos sacrificado al utilizar una notación un poco más técnica.

, , , , , , , , , ,

  1. #1 por Christian Estay el 28-01-09 - 1:20 pm

    Gracias por el ejemplo, tenía la duda de como heredar entre actores.

  2. #2 por Estefania el 7-05-09 - 12:04 pm

    Me fue muy útil tu explicación…. Muchas gracias!!!

  3. #3 por Daimra Civil el 15-12-09 - 5:11 am

    Muy clara la idea del actor abstracto , me ha servido de mucho , gracias

  4. #4 por Isabel el 24-03-10 - 4:07 pm

    muchas gracias; has sido muy claro y conciso; precisamente lo que buscaba

  5. #5 por Alekxandre Verré el 9-05-10 - 3:41 pm

    …esto es una de las cosas por lo q la internet es herramienta muy interesante….

  6. #7 por juana el 27-05-10 - 11:52 am

    quiero un concepto y ejemplo de aplicacion de herencia a caso de uso

    • #8 por Iván Garcerant el 31-05-10 - 8:44 am

      Saludos juana.

      La herencia de casos de uso se merece su propio post. Espero incluir uno esta misma semana, ya que lo has pedido.

      De momento te digo que los casos de uso incluyeron originalmente el concepto de herencia como un intento de incorporar las características de orientación a objetos que ya eran populares en su día y que tan buenos resultados han dado en la programación.

      Sin embargo, como espero poner en claro en el post respectivo, la herencia introduce problemas graves en los casos de uso, por cuanto estos son principalmente documentos de textos y es difícil plantear los detalles de como “heredar” una descripción o un flujo de eventos. Se requiere de un fuerte soporte metodológico y esto hace que sea más simple el mantenerse lejos de la herencia y hacer uso en su lugar de otras formas de reutilización de casos de uso.

      Un ejemplo que considero claro y que tiene aplicación real, es la de utilizar la herencia para cambiar la naturaleza de un elemento referido en los casos de uso. Por ejemplo, heredar el caso de uso “Compra de libro” a partir del caso de uso ya especificado, “Compra de mercancía”.

      En este ejemplo, la herencia se ha utilizado con el propósito de sustituir “mercancía” por algo más concreto, como “libro”. Este tipo de sustituciones pueden implicar nuevas reglas de negocios, en una forma en que ni la relación de inclusión ni la relación de extensión soporten.

      Espero que te sirva un poco mi respuesta. En lo que pueda (espero que esta misma semana) publicaré un post más detallado con diagramas y explicaciones de como tomar en cuenta la herencia dentro de una especificación de caso de uso.

      Iván.

  7. #9 por paulina el 23-11-10 - 3:10 pm

    Hola, les hago una consultita…
    Tenngo 3 actores que necesitan ingresar al sistema, pero cuando ingresan . Para los CU iniciar sesion y cerrar sesion. tengo qe hacer herencia????

    • #10 por Iván Garcerant el 24-11-10 - 11:19 am

      Indicar un comportamiento común a un grupo de actores es justamente lo que se simplifica utilizando la herencia de casos de uso. En tu caso será ciertamente más simple introducir un nuevo actor, abstracto, llamado de alguna forma genérica, y hacer que tus tres actores concretos hereden de este.

      Sin embargo quiero que notes también, que las operaciones de “login” y “logout” no son buenos ejemplos de casos de uso. Dado que todos los sistemas sin excepción tienen esas operaciones, no aporta mucho valor el que incluyas esa información en el modelo. Se ha de modelar lo que se está capturando como requisito, pero concentrándonos en lo nuevo o único del sistema, no en sus partes comunes.

      Sin embargo, si estás en la necesidad de incluir estos casos, seguro que la herencia de actores es una buena opción para simplificar el diagrama.

  8. #11 por paulina el 25-11-10 - 11:49 am

    Hola, te hago otra consulta.
    si tengo eventos que realiza el sistema sin que nadie los instance, x ej. El calculo de personas conectadas al sistema. Es un evento qe no se instancia , se ejecuta cuando un contador llega a cero. Esta bien en el diagrama de CU poner la bola del CU sola.

  9. #12 por Mario el 13-12-10 - 4:04 pm

    Hay una herramienta open source que uso para mi trabajo, está en versión beta pero tiene varias
    caracteristicas remas

  10. #13 por Omar Hurtado el 22-04-13 - 8:17 pm

    Estoy de acuerdo con lo que se menciona en cuanto a la herencia entre actores, para cuando se quiere representar que dos o más actores usan el sistema de la misma manera. Pero la parte donde dos actores están asociados a un mismo caso de uso es diferente, no quiere decir que hagan lo mismo, lo que quiere decir es que un actor hace algo y el otro otra cosa para lograr el objetivo del caso de uso.

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: