Definimos Actor como…
Posted by: Iván Garcerant on: 25-07-08
- In: Casos de Uso| Glosario| Requisitos| UML
- Comment!
En teatro, un actor representa un papel según las indicaciones de un guión. Nosotros tomamos esa metáfora para indicar que un agente externo realiza una acción sobre el sistema, acción esta que puede ser capturada como un guión que sea parte de un caso de uso.
Es interesante observar que llamamos actor a toda entidad externa que demanda funcionalidad del sistema, ya sea un ser humano o un sistema de software; por lo cual el término usuario puede ser un poco limitado.
Normalmente representamos a los actores de nuestro sistema por medio de la simple imagen de una figura humana de rayas. pero dada la flexibilidad del UML es posible representarlo también como una clase estereotipada o bien, con una imagen provista por nosotros según algún criterio artístico.
La siguiente imagen ilustra las tres formas que he mencionado:
Fig. 1 – Tres formas de representar un Actor en un diagrama de UML
La especificación UML lidía con el lenguaje visual pero como en otras ocasiones esta no es más que una fracción de lo que queremos decir sobre nuestros modelos, en este caso, es de interes capturar información adicional de nuestros actores, para lo cual podemos pensar en tener una tabla como la siguiente para cada uno de ellos:
Nombre: Actor
Representado por: Nombre y datos de contacto del stakeholder que puede responder preguntas sobre este actor
Facilidades de comunicación: Protocolos o estilos de comunicación que el actor entiende.
Relación con otros actores: Relaciones de herencia o dependencia entre actores
Tabla 1 – Definición de un Actor
La definición anterior la podemos llevar en el cuerpo de comentarios de nuestro modelador UML y exportarlo a un documento de texto cada vez que sea necesario.
Los actores nos sirven para capturar a los usuarios del sistema pero también, son la forma en la que podemos expresar el contexto del mismo. Es decir, que los actores toman el lugar de cualquier entidad de interes con la que nuestro sistema interactua.
Pese a lo anterior, ciertas cosas generalmente vistas como externas al sistema no son considerados buenos actores. Los sistemas de persistencia como las bases de datos o los archivos, si bien externos, no son actores. Entre otras cosas, debido a que estos no demandan funcionalidad del sistema (son pasivos respecto a él) además, es de interes que estos elementos estén bajo la definición del diseño de nuestro sistema, por lo que puede resultar de más provecho considerarlos parte del mismo.
10 comentarios para "Definimos Actor como…"
[...] Un actor es cualquier entidad externa al sistema que demanda una funcionalidad de este. Con esta definición [...]
[...] hemos de identificar al actor. En este caso es claramente el operador o usuario del teléfono. Tendremos en cuenta siempre que [...]
[...] una presentación de las responsabilidades del sistema desde el punto de vista de cada uno de los actores que requieren los servicios del sistema. A esta forma de documentar los requisitos le llamamos Caso [...]
[...] sencillez, llamaremos actor a cada operador externo, tanto si es un sistema aparte del nuestro como si se trata de un operador [...]
[...] 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 [...]
[...] Un flujo de eventos consiste en enumerar los pasos que sucesivamente realizan los actores y el sistema en el contexto de un caso de uso. Es decir, que un flujo de eventos es en su forma [...]
17-10-08 a 10:25 pm
Saludos Oscar.
Primero que nada gracias por tu comentario.
No alcanzo a comprender plenamente lo que planteas. Las bases de datos no suelen ser representadas como actores, principalmente como digo en el post, por ser pasivas con respecto a él y por ser de interés que su diseño sea parte del diseño del sistema.
Ahora que decir que hay prohibición de modelar algo… pues claro que no. Es posible que representes a una base de datos como actor, pero surge la pregunta de como vas a lidiar con los problemas que te he mencionado.
¿Habrá algún caso de uso que no incluya alguna operación de datos? Posiblemente no. Por lo tanto quizás el actor “Base de Datos” va a estar constantemente involucrado en los casos de uso, casi sin importar cual sea el actor principal.
¿Será posible que la base de datos demande funcionalidad al sistema? Es decir, ¿hay casos de uso que sean activados por el actor “Base de Datos” pero no por nadie más?
Generalmente la respuesta a estas preguntas es no. Por eso se sugiere que no agotemos nuestra paciencia modelando constantemente lo que ya sabemos: que las bases de datos se usan intensamente en un sistema de información moderno y que dichas bases de datos son pasivas respecto al sistema.
Claro que si la abstracción que utilizas te hace pensar en que debes indicar los puntos en que se almacena información en la base de datos, entonces te sugiero que investigues la posibilidad de utilizar alguna otra notación. Quizás un diagrama de secuencia o incluso algún tipo de diagrama que no sea UML, te va a poder ayudar en expresar lo que quieres decir sin caer en terreno poco claro.
Si lo que quieres indicar no puede ser modelado elegantemente en un caso de uso entonces la respuesta es simple: no uses un caso de uso.
Hay otras formas de capturar requisitos, por lo que si tienes un montón de cosas que especificar en relación a tu base de datos entonces puedes intentar alguna otra aproximación.
No sé si te he aclarado la pregunta. Espero sí. Cualquier cosa no dudes en preguntar.
23-04-09 a 6:20 pm
Hola en que sentido se dice que el actor es una entidad, que sentido tiene la palabra entidad en la definición…es como decir es algo que se encuentra fuera del sistema y le requiere algo a dicho sistema? o es entidad en sentido mas técnico que desconozco. Gracias. Saludos.
23-04-09 a 10:50 pm
Saludos Martín.
Al menos en los límites de este artículo, la palabra entidad no tiene mayor significado técnico. Aquí, la redacción que te ha llamado la atención “llamamos actor a toda entidad externa que demanda funcionalidad del sistema” lo que quiere decir es que el nombre de “actor” se lo damos a cualquier cosa -entidad- que pueda en un momento dado ser diferente al sistema y sin embargo, demandar funcionalidad a este.
La palabra entidad en verdad es muy elegante. Si te he confundido por un momento te pido disculpas. Puedes leer “cualquier cosa” en su lugar y entender perfectamente lo que he querido decir.
Escribe un comentario
- Ejemplo de caso de uso
- Ejemplo de análisis de caso de uso
- Tipos de Diagramas en UML
- Plantillas: Documento de Visión del Sistema
- Plantillas: Plan de Desarrollo de Software
- Tipos de requisitos: Funcional vs. No Funcional
- Modelo de Dominio
- Casos de Uso Avanzados: Relación de Extensión
- Casos de Uso Avanzados: Relación de Inclusión
- Modelado de Casos de Uso
- Ismael Soto: Hola, Escribo para agradecerles el esfuerzo que han venido realizado en la publicación de este blog, y felicitarles por la calidad del mismo. S
- Marcelo: Muy buen artículo, simple y concreto que es lo necesario para comprender metodologías que en muchas ocaciones terminan siendo expuestas o muy vagame
- Iván Garcerant: Exacto! Estoy muy de acuerdo contigo. Un buen diagrama no estaría nada mal. :-) ... siempre y cuando los casos de uso estén correctamente documen
ClustrMaps
17-10-08 a 3:05 am
hola, tengo una duda sobre el modelo de base de datos como actores en uml, no he encontrado que en algun libro mencione que no se pueda modelar una base de datos como actor, lo que hice: puse como actor una base de datos en un modelo de casos de uso (el sistema) que interactuan a su vez con otros actores como son un administrador y usuarios, asi que mi duda es que es realmente imposible evitar modelar una bases de datos como un actor como parte del modelado de casos de uso?, es decir me gustaria modelar la base de datos asi como parte del sistema o es una restriccion o una prohibicion hacerlo, gracias por su atencion, saludos desde mexico.