CASO DE USO, ACTORES Y ROLES

CASO DE USO
En ingeniería del software, un caso de uso es una técnica para la captura de requisitos potenciales de un nuevo sistema o una actualización de software. Cada caso de uso proporciona uno o más escenarios que indican cómo debería interactuar el sistema con el usuario o con otro sistema para conseguir un objetivo específico. Normalmente, en los casos de usos se evita el empleo de jergas técnicas, prefiriendo en su lugar un lenguaje más cercano al usuario final. En ocasiones, se utiliza a usuarios sin experiencia junto a los analistas para el desarrollo de casos de uso.
En otras palabras, un caso de uso es una secuencia de interacciones que se desarrollarán entre un sistema y sus actores en respuesta a un evento que inicia un actor principal sobre el propio sistema. Los diagramas de casos de uso sirven para especificar la comunicación y el comportamiento de un sistema mediante su interacción con los usuarios y/u otros sistemas. O lo que es igual, un diagrama que muestra la relación entre los actores y los casos de uso en un sistema. Una relación es una conexión entre los elementos del modelo, por ejemplo la especialización y la generalización son relaciones. Los diagramas de casos de uso se utilizan para ilustrar los requerimientos del sistema al mostrar cómo reacciona a eventos que se producen en su ámbito o en él mismo.

Pasos para la Definición de un Caso de Uso:

• ID
• NOMBRE
• REFERENCIAS CRUZADAS
• CREADO POR
• ULTIMA ACTUALIZACION POR
• FECHA DE CREACION
• FECHA DE ULTIMA ACTUALIZACION
• ACTORES
• DESCRIPCION
• TRIGGER
• PRE-CONDICION
• POST-CONDICION
• FLUJO NORMAL
• FLUJOS ALTERNATIVOS
• INCLUDES
• FRECUENCIA DE USO
• REGLAS DE NEGOCIO
• REQUERIMIENTOS ESPECIALES
• NOTAS Y ASUNTO

ACTORES

Se le llama actor a toda entidad externa al sistema que guarda una relación con éste y que le demanda una funcionalidad. Esto incluye a los operadores humanos pero también incluye a todos los sistemas externos, además de entidades abstractas, como el tiempo.
En el caso de los seres humanos se pueden ver a los actores como definiciones de rol, por lo que un mismo individuo puede corresponder a uno o más Actores. Suele suceder sin embargo, que es el sistema quien va a tener interés en el tiempo. Es frecuente encontrar que nuestros sistemas deben efectuar operaciones automáticas en determinados momentos; y siendo esto un requisito funcional obvio, resulta de interés desarrollar alguna forma de capturar dicho requisito en el modelo de caso de uso final.

Tipos de relaciones

• ``comunica (<<communicates>>): Relación (asociación) entre un actor y un caso de uso que denota la participación del actor en dicho caso de uso.
• ``usa ( <<uses>>) (o <<include>> en la nueva versión de UML): Relación de dependencia entre dos casos de uso que denota la inclusión del comportamiento de un escenario en otro.
• ``extiende (<< extends>>): Relación de dependencia entre dos casos de uso que denota que un caso de uso es una especialización de otro. Por ejemplo, podría tenerse un caso de uso que extienda la forma de pedir azúcar, para que permita escoger el tipo de azúcar (normal, dietético o moreno) y además la cantidad en las unidades adecuadas (cucharadas o bolsas). Un posible diagrama se muestra en la figura

Se utiliza una relación de tipo <<extends>> entre casos de uso cuando nos encontramos con un caso de uso similar a otro pero que hace algo más que éste (variante). Por contra, utilizaremos una relación tipo << uses>> cuando nos encontramos con una parte de comportamiento similar en dos casos de uso y no queremos repetir la descripción de dicho comportamiento común.

En una relación << extends>>, un actor que lleve a cabo el caso de uso base puede realizar o no sus extensiones. Mientras, en una relación <<include>> el actor que realiza el caso de uso base también realiza el caso de uso incluido.

En general utilizaremos <<extends>> cuando se presenta una variación del comportamiento normal, y <<include>> cuando se repite un comportamiento en dos casos de uso y queremos evitar dicha repetición.

Por último en un diagrama de casos de uso, además de las relaciones entre casos de uso y actor (asociaciones) y las dependencias entre casos de uso (<<include>> y <<extends>>), pueden existir relaciones de herencia ya sea entre casos de uso o entre actores.

Llamamos modelo de casos de uso a la combinación de casos de uso y sus correspondientes diagramas. Los modelos de casos de uso se suelen acompañar por un glosario que describe la terminología utilizada. El glosario y el modelo de casos de uso son importantes puntos de partida para el desarrollo de los diagramas de clases.

Por último se debe tener en cuenta, que aunque cada caso de uso puede llevar a diferentes realizaciones, es importante reflejar en cada representación el motivo que nos ha llevado a descartarla, si es el caso.

ROLES

Los roles son agrupaciones de permisos. El rol más común es el de “miembro”. Podéis definir roles adicionales cuando necesitéis una unidad de permisos para formar un grupo.

Cuando se asigna un rol, a un usuario éste se mantiene en las carpetas inferiores (roles adquiridos).

Documentos / Archivos / Imagen / Carpetas

Rol de propietario
Tener éste rol sobre una carpeta implica poder visualizar y editar (siempre hablando del mismo nivel e inferiores) el contenido de la misma, tanto si son carpetas o archivos, sea cual sea su estado: Visible, Privado, Publicado.

También se puede acceder a las pestañas de contenidos, visualiza. Edita y comparte.

Si el estado de la carpeta, sobre la que se tiene el rol de Propietario es además privada (es decir su estado es privado), únicamente será visible para aquellos grupos que tengan el rol de Propietario.

Rol de Empleado
Tener el Rol de Empleado sobre una carpeta  implica poder visualizar todo su contenido en los estados Visible o Publicado, tanto si son carpetas o archivos. No se pueden visualizar en los elementos que se encuentren en estado Privado.
El estado en el que debería estar esta carpeta para asignarle un rol de empleado, y poder así visualizar dicho contenido, podria ser el de Visible o Publicado (en este caso no tiene mucho sentido asignar un rol a la carpeta), nunca Privado. 

Rol de Revisor
Tener el Rol de Revisor sobre una carpeta implica poder visualizar todo  su contenido, únicamente si el estado de esta carpeta en cuestión es Visible (o Publicado), si fuese Privada no la vería.

Rol de Gestor
 Tener el Rol de Gestor sobre una carpeta implica poder visualizar todo
 su contenido, tanto si el estado de esta carpeta en cuestión es Visible
 ó Privado, y tanto si el contenido de la misma: carpetas o archivos, es 
 Visible ó Privado.

Y al igual que con el rol de Propietario, se tiene también acceso a las pestañas de contenidos, visualiza. Edita y comparte, a las cuales no se puede acceder con el resto de Roles.

Rol de miembro
Tener el Rol de Miembro sobre una carpeta implica poder visualizar todo su contenido, siempre y cuando este contenido no sea Privado, y podré visualizar esta carpeta en cuestión siempre que el estado de la misma no sea Privado.

Rol de Responsable
Tener el Rol de Responsable sobre una carpeta implica poder visualizar todo su contenido, tanto si el estado de esta carpeta en cuestión es Visible ó Privado, y tanto si el contenido de carpetas o archivos es Visible ó Privado.