Autor: Carlos M. Macías Medina
Alias: Charlie Macías (México)
Nivel: Intermedio
Nivel: Intermedio
Lo que abordaremos aquí es, por derecho propio, una FAQ que bien vale la pena discutir porque les sorprendería la cantidad de libros, artículos y expertos confundidos al respecto.
En ocasiones es necesario que ciertas operaciones sean realizadas de manera periódica por un sistema de software. En UML, los procesos que lleva a cabo un sistema se representan como casos de uso. También hemos hablado de que cualquier caso de uso debe ser iniciada por un (y sólo un) actor primario, de aquí parte nuestro tema de discusión en esta ocasión.
Reportar a los clientes que han caído en mora a la fecha, reflejar en un sistema legado todos los comercios con terminales bancarias que se registraron durante el día o descargar los gases radiactivos de la planta del Sr. Burns, son ejemplos de casos de uso que implican tareas que se desarrollan de manera periódica. Pero ¿quien es el actor que dispara estos procesos? ¿un cron? ¿el "Padre Tiempo"? ¿o el drinking bird que uso Homero Simpson para presionar de manera periódica la tecla 'Y' en el episodio "King-Size Homer"? ¿Qué nombre le deberíamos dar al que desencadena esas tareas en el sistema?
La respuesta es simple si recurrimos a la definición de actor. Un actor representa un rol que asume alguien o algo que interactúa con (usa) el sistema pero que se encuentra fuera de su frontera, es decir, que el nombre adecuado para el actor será el del papel que juegue dicha entidad externa, desde la perspectiva del sistema. Entonces, si la descarga de los gases radiactivos es facultad del "Encargado de Seguridad Nuclear" independientemente que que este rol lo asuma Homero Simpson o el dirnking bird o un cron o servicio de un sistema operativo el nombre del actor modelado debería ser "Encargado de Seguridad Nuclear".
Lo importante es el rol no el individuo o cosa que dispara el proceso sino el papel que asume el individuo o cosa y, por cierto, el "Padre Tiempo" no es un actor en los sistemas.
En ocasiones es necesario que ciertas operaciones sean realizadas de manera periódica por un sistema de software. En UML, los procesos que lleva a cabo un sistema se representan como casos de uso. También hemos hablado de que cualquier caso de uso debe ser iniciada por un (y sólo un) actor primario, de aquí parte nuestro tema de discusión en esta ocasión.
Reportar a los clientes que han caído en mora a la fecha, reflejar en un sistema legado todos los comercios con terminales bancarias que se registraron durante el día o descargar los gases radiactivos de la planta del Sr. Burns, son ejemplos de casos de uso que implican tareas que se desarrollan de manera periódica. Pero ¿quien es el actor que dispara estos procesos? ¿un cron? ¿el "Padre Tiempo"? ¿o el drinking bird que uso Homero Simpson para presionar de manera periódica la tecla 'Y' en el episodio "King-Size Homer"? ¿Qué nombre le deberíamos dar al que desencadena esas tareas en el sistema?
La respuesta es simple si recurrimos a la definición de actor. Un actor representa un rol que asume alguien o algo que interactúa con (usa) el sistema pero que se encuentra fuera de su frontera, es decir, que el nombre adecuado para el actor será el del papel que juegue dicha entidad externa, desde la perspectiva del sistema. Entonces, si la descarga de los gases radiactivos es facultad del "Encargado de Seguridad Nuclear" independientemente que que este rol lo asuma Homero Simpson o el dirnking bird o un cron o servicio de un sistema operativo el nombre del actor modelado debería ser "Encargado de Seguridad Nuclear".
Lo importante es el rol no el individuo o cosa que dispara el proceso sino el papel que asume el individuo o cosa y, por cierto, el "Padre Tiempo" no es un actor en los sistemas.
0 comentarios:
Los comentarios nuevos no están permitidos.