AWOB Concepts Actor

MPDL,GAVO

= Actors - v0.5 =

In order to make distinction easier roles, and actors are denoted in italic, and bold face, respectively.
 * --Natasa 16:39, 9 February 2012 (CET) do not quite understand why we make difference between actors and roles; probably we should try to simplify e.g. Task Creator - we need at the moment to specify it only if this role would be explicitely assigned to a user (and not necessarily "Must have at least a Project Manager role in a project."). If we do not have independent Task Creator role in AWOB, then this is only a property of the Task. For example, Actors in Create Task Use case would in this case be "Project Lead" and "Project Manager" - which means only users with this role can perform this action; Same analogy for Project Creator and Project Lead.


 * -- JK and GerardLemson 08:50, 10 February 2012 (CET) This page aims/aimed to document the different actors occurring in at least one Use Cases. In principle these actors could all be defined in the Use Case(s) where they occur. There they would be linked to the concepts (roles, or properties) that can perform the acts. By listing them here, and linking to this page from the Use Cases, we thought we could make the naming of actors somewhat more homogeneous. Important is though that these actors are in general NOT in a 1-1 relation to the various (AWOB/Project/Task) roles. For example "Task Creator" is an actor in the "Create Task" use case. It is not a role, but indeed (as NB notices below) a property of Task. ALso, since the same role might occur multiple times in the same Use Case, e.g. "Project Member", one would need different Actor labels to refer to these, the single term "Project Member" would not suffice to distinguish them. Also actors may correspond to multiple roles. For example the actor "Project Member" would correspond to all individuals with role in {"Project Lead" (maybe not a role?), "Project Manager", Project Member"} etc.


 * --Natasa 13:48, 10 February 2012 (CET) would still prefer to not use Actors on this page combined with Roles - but only Roles and to reference "Roles" in the Use case headings which are entitled as "Actors". Do not actually understand the argumentation that same role might occur multiple times in same Use case. A single actor in a system may certainly have multiple roles, and within a single use case may act accordingly the actions allowed for these roles. There may be a case, that a same action is allowed in both roles on a resource, for example: uploading a resource to the task in real system is allowed to users who have the role of Task Lead, Task Manager and Task Member. Therefore, for a use case e.g. upload resource to the task all three roles shall be stated as actor.


 * Jkim 15:10, 10 February 2012 (CET) This page simply allows all possible actors to be gathered together with their definition so that this definition need not be repeated on Use Cases that use the same actor (conceptually). From this page you link to the separate page where roles are defined. Note, THIS page does NOT DEFINE the roles. That happens in that other page, as well as in the conceptual model. This page is an extra layer, that could be removed by having the Actors section on the Use Case page point to the Roles page. As to use cases where the same role occurs multiple times, an example could be a (so far hypothetical) Send message use case, where one AWOB member (the Sender") sends a message to another AWOB member (the "Receiver"). If this page is confusing, i will not use this page for new kinds of actors in use cases for future releases.
 * it is very confusing indeed - would suggest to use only Roles in the "Actors" section of the use cases. We need to define Roles on one place only - For each Role a short "human" description of what it can do (like done for some "Actors" on this page) is very useful. So I'd keep this page, but here I will provide a "short human description of the role" (will provide some text below). Also i'd like to suggest the following: roles are rarely specific to a single use case usually. If there is a case as provided with the sender/receiver example, then this is indeed more comfortable for the lower-level implementation design of a component (and not on this higher level of the functional specification). --Natasa 15:03, 13 February 2012 (CET)

Individual

 * is a person who has a valid e-mail address and has necessary qualifications to become an AWOB user.

Registered User

 * an Individual that has a user account within an AWOB instance
 * can sign-in to an AWOB instance with a username and a password
 * can edit its own 'user profile' in the system
 * has a personal dashboard.
 * can see all public AWOB content
 * can create a project(*).

Anonymous User

 * a User not known to the system (not authenticated)
 * can only access public parts of AWOB. ToBeDefined ...

Authenticated User

 * A Registered user who is signed-in with an AWOB instance.
 * Depending on permissions, an Authenticated User can perform different actions within an AWOB instance.

Project Creator

 * A user who creates a project
 * Must be a Registered User(*)
 * By default plays Project Lead Role. See AWOB_Task_006.

Project Member

 * Any individual related to a project
 * Must be a Registered User(*)
 * can create some new project content, e.g. wiki pages/upload files to the project.
 * can be assigned to a task. what project member can do in a task depends on the assigned task role.
 * can post message on project message board/mailing list.

Task Creator

 * A user who creates a task in a project.
 * Must have at least a Project Manager role in a project.
 * In Task related use cases, i.e. once a task is created, the Task Creator will in general be referred to as Task Lead.
 * why this difference between task lead and task creator in this case? --Natasa 16:19, 9 February 2012 (CET)

--Jkim 16:30, 9 February 2012 (CET)no difference. just called differently. I thought it might confuse people if actor 'task creator' is referred in task use cases other than 'create task'. If using two terms 'task creator', 'task lead' is confusing then I can remove 'task lead' from the actor list and use cases.

Task Member

 * A project member who is assigned to a task
 * can update task content including the wiki, private wall, resources of a task.

Task Manager

 * A task member plays a role of Task Manager or Task Lead.

Task Lead

 * A task member who is responsible for a task, and plays a role of Task Lead.
 * This is always the person who created the task.

ignore below

Co-I

 * Acronym for Co-Investigator
 * A Project Member
 * In terms of project site management Co-I and PI have almost the same actions/privileges except final saying in close project, release data, submit the paper(Ask scientists)(*)
 * can do the following in a project to which it belongs.
 * create tasks
 * edit 'most project content', though this depends on how we allow
 * can upload resources directly to the project.

PI

 * Acronym for Principal Investigator of project
 * a Co-I
 * can do the following in a project to which it belongs.
 * invite a user to the project.
 * remove a user from the project.
 * assign/change any awob project role to an accepted invitee of a project.
 * set/alter project status
 * close the project.

= Actors - DEMONSTRATOR =

Individual

 * is a person who has a valid e-mail address and has necessary qualifications to become an AWOB user.

Registered User

 * an Individual that has a user account within an AWOB instance
 * can sign-in to an AWOB instance with a username and a password
 * can edit its own 'user profile' in the system
 * has a personal dashboard.
 * can see all public AWOB content
 * can create a project(*).

Anonymous User

 * a User not known to the system (not authenticated)
 * can only access public parts of AWOB. ToBeDefined ...

Authenticated User

 * A Registered user who is signed-in with an AWOB instance.
 * Depending on permissions, an Authenticated User can perform different actions within an AWOB instance.

Project Member

 * Any individual related to a project
 * Must be a Registered User(*)
 * can create some new project content, TBD what in detail, e.g. wiki pages/upload files to the project.(*)
 * can be assigned to a task. when assigned to task can there do everything. In particular can up;oad resources ONLY through the task. TBD depends on decisions on task-roles.
 * can post message on project message board/mailing list

Co-I

 * Acronym for Co-Investigator
 * A Project Member
 * In terms of project site management Co-I and PI have almost the same actions/privileges except final saying in close project, release data, submit the paper(Ask scientists)(*)
 * can do the following in a project to which it belongs.
 * create tasks
 * edit 'most project content', though this depends on how we allow
 * can upload resources directly to the project.

PI

 * Acronym for Principal Investigator of project
 * a Co-I
 * can do the following in a project to which it belongs.
 * invite a user to the project.
 * remove a user from the project.
 * assign/change any awob project role to an accepted invitee of a project.
 * set/alter project status
 * close the project.

NOTE

 * (*) denotes that there is a difference b/w this version and the one in discussion.
 * This is a reminder for jaiwon only [[Media:MPDL_CDFS.txt|MPDL_CDFS.txt]]

Discussion
[GL+JK: 2011-12-08] At an early meeting in the project we decided we would try to use standard terms form scientific practice such as PI, Co_I when defining project roles. However this may actually be confusing. When we talk to scientists one gets lots of slightly different definitions that are often context dependent. For example in a big project/consortium with lots of sub projects multiple PIs may be defined. But in smaller projects with few close colleagues the concept of PI is too formal. We may want to reconsider the naming of the project roles and more closely allign them to their meaning withion an AWOB project, namely to rights the member has to perform certain actions within the AWOB project. We may therefore have: project creator, project admin, project member, project lead. Note, we still need to define the actual privileges related to these.