Estoy haciendo un diagrama de caso de uso para un nuevo sistema. Me pregunto cuándo debería incluirse un sistema como actor en el diagrama de casos de uso.¿Cuándo se debe incluir un sistema como actor en el diagrama de casos de uso?
Gracias.
Como se indica en otra respuesta, un actor es un sistema o rol que interactúa con el sistema en desarrollo. Debe incluir un sistema como actor en un caso de uso si está fuera del sistema que está desarrollando y si interactúa directamente con el sistema que está desarrollando.
Esto es importante porque necesita definir el límite de su sistema, lo que significa su alcance e interfaces. Incluir un sistema como actor indicará claramente el requisito de que su sistema en desarrollo proporcione una interfaz adecuada para ese sistema actor.
¿La base de datos de el sistema ¿un caso de uso como almacena datos o un actor externo debido a que recibe entradas o da salidas al sistema? – commonSenseCode
Normalmente, la base de datos se considera dentro del límite del sistema, es decir, es una parte del recuadro negro que interactúa con el (los) actor (es) y no con el propio actor. Pero hay excepciones. Supongamos que diseña un nuevo sistema que está conectado a una base de datos existente que permanece tal cual, entonces podría considerar que db es un actor. Pero haga esto solo si es relevante para las partes interesadas que leen sus casos de uso. –
Diferentes personas tienen diferentes filosofías sobre cómo modelar correctamente en UML (lo cual no es sorprendente ya que UML fue estandarizado por el comité).
Utilizo actores para capturar cada "cosa" (tipo de persona, tipo de sistema) que puede interactuar con el sistema que estoy diseñando y los encuentro útiles para crear un entendimiento común entre todos los interesados acerca de cómo será el nuevo sistema interactuado con.
Sugiero crear un actor para todo lo que sabe que interactuará con el sistema, y rastrear ese actor a cada caso de uso que el actor puede ejecutar. De esa forma, obtienes una comprensión completa de quién puede hacer qué.
El sistema nunca es un actor en un modelo de caso de uso. Tienes que pensar en lo que está provocando que el sistema bajo investigación lleve a cabo un proceso. El sistema en sí es tonto y no puede desencadenarse en acción. Solo puede ser activado por un usuario o por Tiempo. Si crees que el sistema está desencadenando la acción, entonces probablemente sea Time el actor. Por ejemplo, se activa un proceso para que se reciba un mensaje electrónico. El proceso está completamente automatizado y no lo desencadena un usuario que le dice al sistema que el mensaje ha llegado, ¿quién es el actor? No es el sistema, sino el Tiempo. Lo que tienes que imaginar es que hay un proceso para buscar la llegada del mensaje electrónico y esto está viendo los intervalos de tiempo específicos, por ej. cada segundo o cada minuto o una vez al mes, etc. Por lo tanto, es el Tiempo el que desencadena el proceso que se ejecuta cuando se recibe el mensaje electrónico.
Se centró en la activación y Gabriel Ščerbák se centró en los límites y el alcance. Ambos señalaron buenas guías. – Alireza
Sí lo hace. La especificación establece claramente que puede descargarlo de OMG y verificarlo. Los sistemas externos se pueden representar como actores del diagrama de casos de uso. Y UML 2.5 define oficialmente que un caso de uso sin actores es desencadenado por el tema en el que está contenido (un trabajo programado, por ejemplo). – BonanzaOne
Este tema también podría ayudar a aclarar cuándo representar los sistemas como actores: [Diagramas de casos de uso de UML: Referencia] (http://msdn.microsoft.com/en-us/library/dd409432.aspx) –