Contenido introducción 1



Descargar 278,91 Kb.
Página6/7
Fecha de conversión12.01.2017
Tamaño278,91 Kb.
1   2   3   4   5   6   7

Actores y Casos de Uso Abstractos


Al modularizar la especificación, identificando relaciones de uso y extensión, puede pasar que extraigamos casos de uso que son accedidos por varios actores. Por ejemplo, el caso de uso buscando datos de producto es accedido por muchos actores (el empleado de ventas que ingresa un pedido, el gerente que quiere obtener estadísticas por producto, el supervisor que quiere consultar la información de algún producto, etc.). Ahora bien, como el caso de uso nunca se ejecuta fuera del contexto de otro caso de uso, decimos que es un caso de uso abstracto. Lo llamamos abstracto porque no es implementable por sí mismo: sólo tiene sentido como parte de otros casos.

De la misma forma, el actor que participa de este caso de uso, que reúne características comunes a todos los actores de los casos de uso que lo usan, es un actor abstracto. En nuestro ejemplo, si bien el nombre suena poco elegante, podemos decir que tenemos un actor abstracto “Buscador de Datos de Producto”. Los actores abstractos, entonces, son necesarios para no “dejar sin actores” a los casos de uso abstractos.





Figura 8 – El nombre de los actores abstractos suele no ser feliz

La duda ahora es cómo relacionar este actor abstracto con los actores concretos: los que sí existen en la realidad y ejecutan casos de uso concretos, como ingresando pedido y obteniendo estadísticas de ventas.



Para esto podemos usar el concepto de herencia, uno de los conceptos básicos de la orientación a objetos. Como todos los actores concretos también ejecutan el caso buscando datos de producto, a través de la relación de uso, podemos decir que los actores concretos heredan al actor abstracto.



Figura 9 – Herencia de Actores

La relación de herencia no necesariamente implica la existencia de un caso abstracto. Puede ocurrir que un actor ejecute todos los casos que ejecuta otro actor, y algunos más. En nuestro sistema, el supervisor de ventas puede hacer todo lo que hace el empleado de ventas, pero además puede autorizar pedidos. En este caso, podemos decir que el Supervisor de Ventas hereda al Empleado de Ventas, aunque el Empleado de Ventas no sea un actor abstracto. De esta forma, toda la funcionalidad que está habilitada para el Empleado de Ventas también lo está para el Supervisor.





Figura 10 – Relación de herencia entre actores concretos

Usando la herencia en el análisis de requerimientos evitamos redundancia y simplificamos la especificación y los gráficos de casos de uso.


1   2   3   4   5   6   7


La base de datos está protegida por derechos de autor ©absta.info 2016
enviar mensaje

    Página principal