BZFlagWiki - User contributions [en]

GMS: Architecture

2011-06-13T09:37:41Z

Grans Remedy: New page: {{DesignDocument}} A three-tier architecture was chosen to allow the interface to be changed independently of the application/business logic, and to allow the data storage technology to be...

{{DesignDocument}}
A three-tier architecture was chosen to allow the interface to be changed independently of the application/business logic, and to allow the data storage technology to be changed (database, LDAP etc) without impacting the application/business logic layer.

[[Image:GMS_Architecture.png|Depiction of the Group Management System architecture]]

== Smarty Templates ==
The [http://www.smarty.net Smarty] PHP Template Engine will be used to cleanly separate the application logic from the presentation code. Smarty uses place-holder tags which are replaced with live content at run-time.

Note that Smarty version 3 requires PHP version 5.0 or later, however an earlier version Smarty 2 will work on PHP version 4.

== Database Abstraction ==
The ''Active Data Objects DataBase'' [http://http://adodb.sourceforge.net/index.html ADODB] database abstraction library will be used to 'insulate' the application logic from the underlying database server (MySQL). Using this abstraction layer will enable the underlying database technology to be changed from MySQL to some other database (eg FireBird, PostgreSQL, LDAP etc) without requiring a change to the application logic.

Note that PHP version 5.0 or later is required.

== GMS Controllers ==
These are objects providing functions within the application logic, and may be implemented as methods.

== GMS PHP Pages ==
These are objects providing the core application logic.

== Data Access Components ==
These are objects providing access to underlying database tables, reading values from tables into objects, storing values etc.

== Zend PHP Engine ==
This is the engine on the my.bzflag.org web server which interprets PHP code.

Back to [[Group management system functional requirements]]

File:GMS Architecture.png

2011-06-13T08:37:19Z

Grans Remedy: BZFlag Group Management System: Architecture

BZFlag Group Management System: Architecture

GMS: Functional Requirements

2011-06-13T07:45:02Z

Grans Remedy:

{{DesignDocument}}
The functional requirements for the Group Management System will be detailed in the following sections with [http://en.wikipedia.org/wiki/Use_case Use Cases] and other [http://en.wikipedia.org/wiki/Unified_Modeling_Language UML] models.

== Actors ==
An actor is a representation of a role performed when interacting with the system.

[[Image:Actors_Model.png|Description of actors of the group management system]]

== Use Case Overview ==
This overview shows the use cases able to be completed by each actor. It describes which types of actors will be able to carry out specific tasks or objectives supported by the system.
[[Image:Use_Cases_Overview.png|Use cases]]

== Use Cases ==
Use Cases describe the functional requirements of the system from the end users perspective, where each use case is a goal or purpose the user has in using the system.

1. [[Register Group Namespace]] 
2. [[View Groups]] 
3. [[Join Group]] 
4. [[Search for Groups]] 
5. [[Update Membership Request]] 
6. [[Assign User to Group]] 
7. [[Remove User from Group]] 
8. [[Assign Group Manager]] 
9. [[Remove Group Manager]] 
10. [[Create Group]] 
11. [[Change Group]] 
12. [[Delete Group]] 
13. [[Assign co-founder]] 
14. [[Remove co-founder]] 
15. [[Verify Player]] 
16. [[Get Player Groups]] 
17. [[Make System Change]] 

== Architecture ==
The proposed architecture for the Group Management System follows the proven 3-tier model, with the separation of concerns of presentation, application logic and data access.

[[GMS Architecture]]

== Detailed Design ==
The detailed design will be modelled with UML Sequence diagrams for each Use Case, showing a view of participating classes and the messages sent to each class. A class model of the database schema will detail the physical table structure, and show the ''proposed'' integration with the BZFlag forum database for user management.

Note: this integration is needed to provide a 'single-sign-on' to the Group Management System, where a registered player will not need a separate set of credentials to use the GMS.

[[GMS Detailed Design]]

GMS: View Groups

2011-04-29T04:30:27Z

Grans Remedy: Changes to requirements and rules

{{DesignDocument}}

== Introduction ==
This use case describes the process of viewing the groups the actor is associated with. These are groups the actor is a member of, or those they are the group manager of, and those which they have created. The actor can also retrieve a member list from those groups.

[[Image:UseCase_View_Groups-sml.png|Use case diagram of viewing groups]]

== Pre-conditions ==
None

== Post conditions ==
The list of groups the actor is in has been displayed to the actor.

== Requirements and rules realized ==
'''RQ5 Private groups are hidden from players''' 
The system shall prevent players from viewing the group name and members of private groups they are not a member of. 
* ''BR2 Members of private groups'' 
A member of a private group can see who the other members of that group are. 
* ''BR3 Public groups visible to all players'' 
The group name and members of public groups can be viewed by all players 

'''RQ6 Founders able to view all groups and members''' 
The founder, and any co-founders, of a group namespace shall be able to view all groups and group members associated to that namespace. 

'''RQ7 Group managers can view the list of members''' 
The system shall enable group managers to view the list of members in any group they manage.

'''RQ32 Display groups and roles''' 
The system shall display the groups a player is in, the roles which have been assigned to them, and the groups the actor has created. 
* ''BR39 Separate roles from membership'' 
The system shall display the roles a player has separately from the groups they are a member of. 
* ''BR12 Sort results in ascending alphabetical order'' 
The system shall sort the result set into ascending alphabetical order using namespace, then group name. 

== Flow of events ==
The flow of events describes the main actor actions and system responses in the execution of the use case.

[[Image:Activity_View_Groups-sml.png|Activity diagram of viewing groups]]

== Messages ==
<properties>
Step:= EX-1
Condition:= Player not in any groups
Message Number:= Msg 3
Message Text:= No groups found: you are not a member of any groups.
</properties>

File:Activity View Groups-sml.png

2011-04-29T04:17:40Z

Grans Remedy: uploaded a new version of "Image:Activity View Groups-sml.png": Minor change to step BF-2

Activity diagram describing the flow of events in viewing player groups.

GMS: View Groups

2011-04-29T04:12:20Z

Grans Remedy: /* Introduction */

File:UseCase View Groups-sml.png

2011-04-29T04:07:47Z

Grans Remedy: uploaded a new version of "Image:UseCase View Groups-sml.png": Added rules for displaying roles (co-founder, group manager).

View the groups a player is a member of.

GMS: Remove co-founder

2011-04-29T03:46:17Z

Grans Remedy: New page: {{DesignDocument}} == Introduction == This use case describes the process a founder will use to remove a co-founder from a namespace. [[Image:UC_Remove_co-founder.png|Use Case diagram]...

{{DesignDocument}}

== Introduction ==
This use case describes the process a founder will use to remove a co-founder from a namespace.

[[Image:UC_Remove_co-founder.png|Use Case diagram]]

The diagram shows the requirements and rules the use case is responsible for (via the <<requirement>> stereotype).

== Pre-conditions ==
None

== Post conditions ==
The system has withdrawn the co-founder role from the player indicated by the actor.

== Extended Use Cases ==
[[View Groups]]

== Requirements and rules realized ==
'''RQ31 Founders manage co-founders''' 
The system shall prevent any player other than the founder of a namespace, from assigning or removing co-founders from that namespace. 

'''RQ26 Notify founder changes''' 
The system shall notify a namespace founder of any changes according to rules: BR36, BR38 
* ''BR38 Changes to namespaces'' 
The system shall notify the namespace founders and co-founders when a co-founder has been assigned or removed from a namespace. 

'''RQ19 Notify players of changes in membership''' 
The system shall notify a player if they have been added to, or removed from any group or granted or forfeited any role. 
* ''BR28 Player notification format'' 
The system shall use a forum private message, email message, and a message displayed on the 'my groups' page to alert players of changes to their membership and roles. 

== Flow of events ==
The flow of events describes the main actor actions and system responses in the execution of the use case.

[[Image:Activity_Remove_co-founder.png|Activity diagram showing flow of events]]

== Messages ==
<properties>
Step:= EX-1
Condition:= Actor is not a founder or co-founder of any namespace
Message Number:= ERR-1
Message Text:= You cannot make changes to a namespace because you are not a founder/co-founder.
</properties>

----

<properties>
Step:= AF-1
Condition:= Selected player is a co-founder of selected namespace
Message Number:= MSG-1
Message Text:= Player <player name> is not a co-founder of the <namespace name> namespace
</properties>

----

<properties>
Step:= BF-12
Condition:= Successfully removed co-founder.
Message Number:= MSG-2
Message Text:= Successfully removed player <player name> as co-founder of <namespace name> namespace.
</properties>

File:Activity Remove co-founder.png

2011-04-29T03:40:57Z

Grans Remedy: BZFlag Group Management System: activity diagram for Remove Co-founder use case.

BZFlag Group Management System: activity diagram for Remove Co-founder use case.

File:UC Remove co-founder.png

2011-04-29T03:37:03Z

Grans Remedy: BZFlag Group Management System: Remove Co-founder use case diagram

BZFlag Group Management System: Remove Co-founder use case diagram

GMS: Assign co-founder

2011-04-29T02:12:08Z

Grans Remedy: /* Extended Use Cases */

{{DesignDocument}}

== Introduction ==
This use case describes the process a founder will use to assign a player as a co-founder for a namespace.

[[Image:UC_Assign_co-founder.png|Use Case diagram]]

The diagram shows the requirements and rules the use case is responsible for (via the <<requirement>> stereotype).

== Pre-conditions ==
None

== Post conditions ==
The system has granted the player indicated by the actor a co-founder role for the selected namespace.

== Included Use Cases ==
[[Search for Player]]

== Requirements and rules realized ==
'''RQ31 Founders manage co-founders''' 
The system shall prevent any player other than the founder of a namespace, from assigning or removing co-founders from that namespace. 

'''RQ26 Notify founder changes''' 
The system shall notify a namespace founder of any changes according to rules: BR36, BR38 
* ''BR38 Changes to namespaces'' 
The system shall notify the namespace founders and co-founders when a co-founder has been assigned or removed from a namespace. 

'''RQ19 Notify players of changes in membership''' 
The system shall notify a player if they have been added to, or removed from any group or granted or forfeited any role. 
* ''BR28 Player notification format'' 
The system shall use a forum private message, email message, and a message displayed on the 'my groups' page to alert players of changes to their membership and roles. 

== Flow of events ==
The flow of events describes the main actor actions and system responses in the execution of the use case.

[[Image:Activity_Assign_co-founder.png|Activity diagram showing flow of events]]

== Messages ==
<properties>
Step:= EX-1
Condition:= Actor is not a founder or co-founder of any namespace
Message Number:= ERR-1
Message Text:= You cannot make changes to a namespace because you are not a founder/co-founder.
</properties>

----

<properties>
Step:= AF-1
Condition:= Selected player is already a co-founder of selected namespace
Message Number:= MSG-1
Message Text:= Player <player name> is already a co-founder of the <namespace name> namespace
</properties>

----

<properties>
Step:= BF-12
Condition:= Successfully assigned co-founder.
Message Number:= MSG-2
Message Text:= Successfully assigned player <player name> as co-founder of <namespace name> namespace.
</properties>

GMS: Assign co-founder

2011-04-29T02:10:49Z

Grans Remedy: New page: {{DesignDocument}} == Introduction == This use case describes the process a founder will use to assign a player as a co-founder for a namespace. [[Image:UC_Assign_co-founder.png|Use Ca...

{{DesignDocument}}

== Introduction ==
This use case describes the process a founder will use to assign a player as a co-founder for a namespace.

[[Image:UC_Assign_co-founder.png|Use Case diagram]]

The diagram shows the requirements and rules the use case is responsible for (via the <<requirement>> stereotype).

== Pre-conditions ==
None

== Post conditions ==
The system has granted the player indicated by the actor a co-founder role for the selected namespace.

== Extended Use Cases ==
[[Search for Player]]

== Requirements and rules realized ==
'''RQ31 Founders manage co-founders''' 
The system shall prevent any player other than the founder of a namespace, from assigning or removing co-founders from that namespace. 

'''RQ26 Notify founder changes''' 
The system shall notify a namespace founder of any changes according to rules: BR36, BR38 
* ''BR38 Changes to namespaces'' 
The system shall notify the namespace founders and co-founders when a co-founder has been assigned or removed from a namespace. 

'''RQ19 Notify players of changes in membership''' 
The system shall notify a player if they have been added to, or removed from any group or granted or forfeited any role. 
* ''BR28 Player notification format'' 
The system shall use a forum private message, email message, and a message displayed on the 'my groups' page to alert players of changes to their membership and roles. 

== Flow of events ==
The flow of events describes the main actor actions and system responses in the execution of the use case.

[[Image:Activity_Assign_co-founder.png|Activity diagram showing flow of events]]

== Messages ==
<properties>
Step:= EX-1
Condition:= Actor is not a founder or co-founder of any namespace
Message Number:= ERR-1
Message Text:= You cannot make changes to a namespace because you are not a founder/co-founder.
</properties>

----

<properties>
Step:= AF-1
Condition:= Selected player is already a co-founder of selected namespace
Message Number:= MSG-1
Message Text:= Player <player name> is already a co-founder of the <namespace name> namespace
</properties>

----

<properties>
Step:= BF-12
Condition:= Successfully assigned co-founder.
Message Number:= MSG-2
Message Text:= Successfully assigned player <player name> as co-founder of <namespace name> namespace.
</properties>

File:Activity Assign co-founder.png

2011-04-29T02:08:40Z

Grans Remedy: uploaded a new version of "Image:Activity Assign co-founder.png": Added success message

BZFlag Group Management System: activity diagram for Assign Co-founder use case.

File:Activity Assign co-founder.png

2011-04-29T01:58:19Z

Grans Remedy: BZFlag Group Management System: activity diagram for Assign Co-founder use case.

BZFlag Group Management System: activity diagram for Assign Co-founder use case.

File:UC Assign co-founder.png

2011-04-29T01:50:00Z

Grans Remedy: BZFlag Group Management System: Assign co-founder use case diagram

BZFlag Group Management System: Assign co-founder use case diagram

GMS: Delete Group

2011-04-29T00:16:43Z

Grans Remedy: New page: {{DesignDocument}} == Introduction == This use case describes the process a founder or co-founder will use to delete a group. Note: ''This use case does not include removing players fro...

{{DesignDocument}}

== Introduction ==
This use case describes the process a founder or co-founder will use to delete a group.

Note: ''This use case does not include removing players from a group, or removing a group manager.'' See those individual use cases for details.

[[Image:UC_Delete_Group.png|Use Case diagram]]

The diagram shows the requirements and rules the use case is responsible for (via the <<requirement>> stereotype).

== Pre-conditions ==
None

== Post conditions ==
The system has deleted the group.

== Extended Use Cases ==
[[View Groups]]

== Requirements and rules realized ==
'''RQ30 Only founders can delete groups''' 
The system shall prevent any player other than the founder or co-founder of a namespace, from deleting a group within that namespace. 

'''RQ29 Track changes to groups''' 
The system shall store and track all changes to a group's name, description and membership policy. 

'''RQ26 Notify founder changes''' 
The system shall notify a namespace founder of any changes according to rules: BR36 
* ''BR36 New, re-named or deleted groups'' 
The system shall notify the namespace founder when a new group has been created, an existing group changed, or a group deleted from within the namespace. 

== Flow of events ==
The flow of events describes the main actor actions and system responses in the execution of the use case.

[[Image:Activity_Delete_Group.png|Activity diagram showing flow of events]]

== Messages ==
<properties>
Step:= EX-1
Condition:= Actor is not a founder or co-founder of any namespace
Message Number:= ERR-1
Message Text:= You cannot make changes to a group because you are not a founder/co-founder.
</properties>

----

<properties>
Step:= BF-8
Condition:= Successfully deleted group.
Message Number:= MSG-1
Message Text:= Successfully deleted group <group name>
</properties>

File:Activity Delete Group.png

2011-04-29T00:10:55Z

Grans Remedy: BZFlag Group Management System: activity diagram for Delete Group use case

BZFlag Group Management System: activity diagram for Delete Group use case

File:UC Delete Group.png

2011-04-29T00:06:16Z

Grans Remedy: BZFlag Group Management System: Delete Group use case diagram

BZFlag Group Management System: Delete Group use case diagram

GMS: Change Group

2011-04-27T09:12:02Z

Grans Remedy: New page: {{DesignDocument}} == Introduction == This use case describes the process a founder or co-founder will use to modify (edit) the name, description or membership policy of an existing group...

{{DesignDocument}}

== Introduction ==
This use case describes the process a founder or co-founder will use to modify (edit) the name, description or membership policy of an existing group.

Note: ''This use case does not include adding players to, or removing players from, a group, nor does it include assigning or removing a group manager.'' See those individual use cases for details.

[[Image:UC_Change_Group.png|Use Case diagram]]

The diagram shows the requirements and rules the use case is responsible for (via the <<requirement>> stereotype).

== Pre-conditions ==
None

== Post conditions ==
The system has recorded the change to the group.

== Included Use Cases ==
[[View Groups]]

== Requirements and rules realized ==
'''RQ8 Groups have a membership policy''' 
A groups membership policy determines whether a player can join the group or not. 

'''RQ28 Group descriptions mandatory''' 
The system shall require a founder to provide a description of each group they create or change. 

'''RQ29 Track changes to groups''' 
The system shall store and track all changes to a group's name, description and membership policy. 

'''RQ26 Notify founder changes''' 
The system shall notify a namespace founder of any changes according to rules: BR36 
* ''BR36 New, re-named or deleted groups'' 
The system shall notify the namespace founder when a new group has been created, an existing group changed, or a group deleted from within the namespace. 

'''RQ27 Group names unique''' 
The system shall require a group name to be unique within its namespace. 
* ''BR37 Group names are case insensitive'' 
When determining whether a group name is unique, the system shall ignore the case of the characters, so that for example, COP and cop shall be treated as identical. 

'''RQ23 Founders and co-founders assign group managers''' 
The system shall prevent any player other than the namespace founder or co-founder, from creating or changing groups or assigning group managers within that namespace. 

== Flow of events ==
The flow of events describes the main actor actions and system responses in the execution of the use case.

[[Image:Activity_Change_Group.png|Activity diagram showing flow of events]]

== Messages ==
<properties>
Step:= EX-1
Condition:= Actor is not a founder or co-founder of any namespace
Message Number:= ERR-1
Message Text:= You cannot make changes to a group because you are not a founder/co-founder.
</properties>

----

<properties>
Step:= AF-1
Condition:= Group name empty or existing, group description missing, or no membership policy selected.
Message Number:= MSG-1
Message Text:= Cannot change the group - the name is empty or identical to an existing name, the description is missing or no membership policy selected.
</properties>

----

<properties>
Step:= BF-10
Condition:= Successfully changed group.
Message Number:= MSG-3
Message Text:= Successfully changed group <group name>
</properties>

File:Activity Change Group.png

2011-04-27T09:02:47Z

Grans Remedy: BZFlag Group Management System: activity diagram for Change Group use case.

BZFlag Group Management System: activity diagram for Change Group use case.

File:UC Change Group.png

2011-04-27T08:17:36Z

Grans Remedy: BZFlag Group Management System: Change Group use case diagram

BZFlag Group Management System: Change Group use case diagram

GMS: Functional Requirements

2011-04-27T08:13:29Z

Grans Remedy: /* Use Cases */

File:UC Create Group.png

2011-04-27T08:10:50Z

Grans Remedy: uploaded a new version of "Image:UC Create Group.png": Two additional rules

BZFlag Group Management System: Create Group use case diagram

GMS: Create Group

2011-04-27T06:50:54Z

Grans Remedy: New page: {{DesignDocument}} == Introduction == This use case describes the process a founder or co-founder will use to create a new group. Use Case diagram The diag...

{{DesignDocument}}

== Introduction ==
This use case describes the process a founder or co-founder will use to create a new group.

[[Image:UC_Create_Group.png|Use Case diagram]]

The diagram shows the requirements and rules the use case is responsible for (via the <<requirement>> stereotype).

== Pre-conditions ==
The namespace for the group must have been registered previously.

== Post conditions ==
The system has created the new group.

== Requirements and rules realized ==
'''RQ8 Groups have a membership policy''' 
A groups membership policy determines whether a player can join the group or not. 

'''RQ26 Notify founder changes''' 
The system shall notify a namespace founder of any changes according to rules: BR36 
* ''BR36 New, re-named or deleted groups'' 
The system shall notify the namespace founder when a new group has been created, an existing group re-named, or a group deleted from within the namespace. 

'''RQ27 Group names unique''' 
The system shall require a group name to be unique within its namespace. 
* ''BR37 Group names are case insensitive'' 
When determining whether a group name is unique, the system shall ignore the case of the characters, so that for example, COP and cop shall be treated as identical. 

'''RQ23 Founders and co-founders assign group managers''' 
The system shall prevent any player other than the namespace founder or co-founder, from creating groups or assigning group managers within that namespace. 

== Flow of events ==
The flow of events describes the main actor actions and system responses in the execution of the use case.

[[Image:Activity_Create_Group.png|Activity diagram showing flow of events]]

== Messages ==
<properties>
Step:= EX-1
Condition:= Actor is not a founder or co-founder of any namespace
Message Number:= ERR-1
Message Text:= You cannot create a new group because you have not registered any namespaces.
</properties>

----

<properties>
Step:= AF-1
Condition:= Group name empty or existing, group description missing, or no membership policy selected.
Message Number:= MSG-1
Message Text:= Cannot create group - the name is empty or identical to an existing name, the description is missing or no membership policy selected.
</properties>

----

<properties>
Step:= BF-8
Condition:= Successfully created new group.
Message Number:= MSG-2
Message Text:= Successfully created group <group name>
</properties>

File:Activity Create Group.png

2011-04-27T06:40:52Z

Grans Remedy: BZFlag Group Management System: Activity diagram for Create Group use case.

BZFlag Group Management System: Activity diagram for Create Group use case.

File:UC Create Group.png

2011-04-27T06:32:30Z

Grans Remedy: BZFlag Group Management System: Create Group use case diagram

BZFlag Group Management System: Create Group use case diagram

GMS: Assign Group Manager

2011-04-27T01:18:56Z

Grans Remedy: New page: {{DesignDocument}} == Introduction == This use case describes the process a founder or co-founder of a namespace will use to assign a player as the manager of one or more groups within th...

{{DesignDocument}}

== Introduction ==
This use case describes the process a founder or co-founder of a namespace will use to assign a player as the manager of one or more groups within that namespace.

Group Management is a role any player can be assigned by the founder of a namespace, and they do not have to be a member of the group(s) they manage. The sole function of a group manager is to manage the maintenance of that group by adding and removing players to it.

[[Image:UC_Assign_Manager.png|Use Case diagram]]

The diagram shows the requirements and rules the use case is responsible for (via the <<requirement>> stereotype).

== Pre-conditions ==
None

== Post conditions ==
The system has assigned the player indicated by the actor to a group management role for one or more groups.

== Included Use Cases ==
[[Search for Player]]

== Requirements and rules realized ==
'''RQ6 Founders able to view all groups and members''' 
The founder, and any co-founders, of a group namespace shall be able to view all groups and group members associated to that namespace 

'''RQ24 Notify players of changes in roles''' 
The system shall notify a player of any change in role they perform for a namespace. 
* ''BR28 Player notification format'' 
The system shall use a forum private message, email message, and a message displayed on the 'my groups' page to alert players of changes to their membership and roles. 

'''RQ25 Track changes to roles''' 
The system shall store and track changes in the namespace roles assigned to players according to rule BR35. 
* ''BR35 Record details of role changes'' 
The system shall record the founder who made the change, player, role, group, namespace and date when any role is assigned to or removed from a player. 

'''RQ23 Founders and co-founders assign group managers''' 
The system shall prevent any player other than the namespace founder or co-founder, from creating groups or assigning group managers within that namespace. 

== Flow of events ==
The flow of events describes the main actor actions and system responses in the execution of the use case.

[[Image:Activity_Assign_Manager.png|Activity diagram showing flow of events]]

== Messages ==
<properties>
Step:= EX-1
Condition:= Actor is not a founder or co-founder of any namespace
Message Number:= ERR-1
Message Text:= You cannot assign a group manager because you are not the founder or co-founder of any namespace.
</properties>

----

<properties>
Step:= AF-1
Condition:= Player indicated by Actor is already group manager or founder of current group
Message Number:= MSG-1
Message Text:= Player <player name> skipped: already a group manager or founder of group <group name>.
</properties>

----

<properties>
Step:= BF-10
Condition:= Successfully assigned player to role of group manager for group list
Message Number:= MSG-2
Message Text:= Successfully assigned player <player name> as manager of <group list>.
</properties>

File:Activity Assign Manager.png

2011-04-27T01:01:46Z

Grans Remedy: BZFlag Group Management System: activity diagram for Assign Manager use case

BZFlag Group Management System: activity diagram for Assign Manager use case

File:UC Assign Manager.png

2011-04-27T00:55:48Z

Grans Remedy: BZFlag Group Management System: Assign Manager use case diagram

BZFlag Group Management System: Assign Manager use case diagram

GMS: Remove User from Group

2011-04-26T04:56:33Z

Grans Remedy: New page: {{DesignDocument}} == Introduction == This use case describes the process a group manager will use to remove a player from a group they manage. [[Image:UC_Remove_player_from_group.png|Us...

{{DesignDocument}}

== Introduction ==
This use case describes the process a group manager will use to remove a player from a group they manage.

[[Image:UC_Remove_player_from_group.png|Use Case diagram]]

The diagram shows the requirements and rules the use case is responsible for (via the <<requirement>> stereotype).

== Pre-conditions ==
None

== Post conditions ==
The system has removed the player from a group.

== Included Use Cases ==
[[View Groups]]

== Requirements and rules realized ==
'''RQ7 Group managers can view the list of members''' 
The system shall enable group managers to view the list of members in any group they manage. 
* ''BR33 Managers cannot remove founders'' 
The system shall prevent a group manager from removing a player from a group where the player is also the groups founder or co-founder. 

'''RQ19 Notify players of changes in membership''' 
The system shall notify a player if they have been added to, or removed from, any group. 
* ''BR28 Player notification format'' 
The system shall use a forum private message, email message, and a message displayed on the 'my groups' page to alert players of changes to their membership. 

'''RQ20 Track changes to group memberships''' 
The system shall store and track the details of changes in membership of each group, according to rules: BR26 
* ''BR26 Record details'' 
The system shall store the date, player, manager and group for each change in membership. 
* ''BR34 Provide reason for removal'' 
The system shall require a manager to provide a reason for removing a player from a group. 

== Flow of events ==
The flow of events describes the main actor actions and system responses in the execution of the use case.

[[Image:Activity_Remove_player_from_group.png|Activity diagram showing flow of events]]

== Messages ==
<properties>
Step:= BF-6
Condition:= Successfully removed player from group
Message Number:= MSG-1
Message Text:= Player <player name> has been removed from Group <group name>.
</properties>

File:Activity Remove player from group.png

2011-04-26T04:54:03Z

Grans Remedy: BZFlag Group Management System: Activity diagram for Remove Player from Group use case.

BZFlag Group Management System: Activity diagram for Remove Player from Group use case.

File:UC Remove player from group.png

2011-04-26T04:46:09Z

Grans Remedy: BZFlag Group Management System: Remove player from group use case diagram

BZFlag Group Management System: Remove player from group use case diagram

GMS: Search for Player

2011-04-26T00:14:28Z

Grans Remedy: New page: {{DesignDocument}} == Introduction == This use case describes the process a group manager will use to search for a player, during the process of adding a player to one or more groups they...

{{DesignDocument}}

== Introduction ==
This use case describes the process a group manager will use to search for a player, during the process of adding a player to one or more groups they manage.

[[Image:UC_Search_for_player.png|Use Case diagram]]

The diagram shows the requirements and rules the use case is responsible for (via the <<requirement>> stereotype).

== Pre-conditions ==
None

== Post conditions ==
The system has displayed details of the player the actor has indicated.

== Requirements and rules realized ==
'''RQ21 Search for player''' 
The system shall enable managers to search for players matching a callsign (name) they provide. 
* ''BR9 Search for exact match then partial'' 
The system shall use the criteria supplied by the actor to search for an exact match. If no exact matches are found then the system shall use a partial match method to find names which are similar. 

'''RQ22 Result set contents''' 
For each player found, the system shall display information in rules BR31 and BR32. 
* ''BR10 Indicate partial match separately'' 
The system shall indicate exact matches and partial matches separately. 
* ''BR29 Sort result set'' 
The system shall sort the result set into ascending alphabetical order using callsign (name). 
* ''BR31 Result list summary'' 
For each player found, the system shall display the player's callsign (name), rank, and the date the callsign was registered. 
* ''BR32 Result detail '' 
The system shall display the following information about the player the actor indicates: the player's callsign (name), rank, the date the callsign was registered, their avatar, and their signature. 

== Flow of events ==
The flow of events describes the main actor actions and system responses in the execution of the use case.

[[Image:Activity_Search_for_Player.png|Activity diagram showing flow of events]]

== Messages ==
<properties>
Step:= EX-1
Condition:= Invalid search criteria or no callsign provided
Message Number:= ERR-1
Message Text:= Please provide a player callsign to search for.
</properties>

File:Activity Search for Player.png

2011-04-26T00:09:44Z

Grans Remedy: BZFlag Group Management System: Activity diagram for Search for Player use case.

BZFlag Group Management System: Activity diagram for Search for Player use case.

File:UC Search for player.png

2011-04-26T00:01:50Z

Grans Remedy: BZFlag Group Management System: Search for Player Use Case diagram

BZFlag Group Management System: Search for Player Use Case diagram

GMS: Assign User to Group

2011-04-25T23:59:13Z

Grans Remedy: minor format changes

{{DesignDocument}}

== Introduction ==
This use case describes the process a group manager will use to add a player to one or more groups they manage.

[[Image:UC_Assign_user.png|Use Case diagram]]

The diagram shows the requirements and rules the use case is responsible for (via the <<requirement>> stereotype).

== Pre-conditions ==
None

== Post conditions ==
The system has added the player to one or more groups.

== Included Use Cases ==
[[Search for Player]]

== Requirements and rules realized ==
'''RQ18 Group managers assign players''' 
The system shall enable group managers to assign players to a group they manage, regardless of the groups membership policy. 
* ''BR27 Prevent duplicates'' 
The system shall prevent a player from being added to a group they are already a member of. 

'''RQ19 Notify players of changes in membership''' 
The system shall notify a player if they have been added to, or removed from, any group. 
* ''BR28 Player notification format'' 
The system shall use a forum private message, email message, and a message displayed on the 'my groups' page to alert players of changes to their membership. 

'''RQ20 Track changes to group memberships''' 
The system shall store and track the details of changes in membership of each group, according to rules: BR26 
* ''BR26 Record details'' 
The system shall store the date, player, manager and group for each change in membership. 

== Flow of events ==
The flow of events describes the main actor actions and system responses in the execution of the use case.

[[Image:Activity_Assign_user.png|Activity diagram showing flow of events]]

== Messages ==
<properties>
Step:= AF-1
Condition:= Player already a member of indicated group
Message Number:= MSG-1
Message Text:= Group <group name> skipped - player <player name> is already a member.
</properties>

----

<properties>
Step:= BF-8
Condition:= Added player to groups
Message Number:= MSG-2
Message Text:= Successfully added <player name> to groups <group list>.
</properties>

GMS: Assign User to Group

2011-04-25T23:57:47Z

Grans Remedy: /* Included Use Cases */

GMS: Assign User to Group

2011-04-25T06:08:56Z

Grans Remedy: New page: {{DesignDocument}} == Introduction == This use case describes the process a group manager will use to add a player to one or more groups they manage. [[Image:UC_Assign_user.png|Use Case ...

{{DesignDocument}}

== Introduction ==
This use case describes the process a group manager will use to add a player to one or more groups they manage.

[[Image:UC_Assign_user.png|Use Case diagram]]

The diagram shows the requirements and rules the use case is responsible for (via the <<requirement>> stereotype).

== Pre-conditions ==
None

== Post conditions ==
The system has added the player to one or more groups.

== Included Use Cases ==
Search for Player

== Requirements and rules realized ==
'''RQ18 Group managers assign players''' 
The system shall enable group managers to assign players to a group they manage, regardless of the groups membership policy. 
* ''BR27 Prevent duplicates'' 
The system shall prevent a player from being added to a group they are already a member of. 

'''RQ19 Notify players of changes in membership''' 
The system shall notify a player if they have been added to, or removed from, any group. 
* ''BR28 Player notification format'' 
The system shall use a forum private message, email message, and a message displayed on the 'my groups' page to alert players of changes to their membership. 

'''RQ20 Track changes to group memberships''' 
The system shall store and track the details of changes in membership of each group, according to rules: BR26 
* ''BR26 Record details'' 
The system shall store the date, player, manager and group for each change in membership. 

== Flow of events ==
The flow of events describes the main actor actions and system responses in the execution of the use case.

[[Image:Activity_Assign_user.png|Activity diagram showing flow of events]]

== Messages ==
<properties>
Step:= AF-1
Condition:= Player already a member of indicated group
Message Number:= MSG-1
Message Text:= Group <group name> skipped - player <player name> is already a member.
</properties>

----

<properties>
Step:= BF-8
Condition:= Added player to groups
Message Number:= MSG-2
Message Text:= Successfully added <player name> to groups <group list>.
</properties>

File:Activity Assign user.png

2011-04-25T05:51:05Z

Grans Remedy: BZFlag Group Management System: Assign player to group Activity Diagram

BZFlag Group Management System: Assign player to group Activity Diagram

File:UC Assign user.png

2011-04-25T05:42:32Z

Grans Remedy: BZFlag Group Management System: Assign player to a group Use Case diagram

BZFlag Group Management System: Assign player to a group Use Case diagram

GMS: Functional Requirements

2011-04-25T03:41:30Z

Grans Remedy: /* Use Cases */

File:Use Cases Overview.png

2011-04-25T02:49:42Z

Grans Remedy: uploaded a new version of "Image:Use Cases Overview.png": Removed 'request membership' use case (obsolete). Added bzflag client and server actors and their use cases.

GMS: Update Membership Request

2011-04-25T02:44:27Z

Grans Remedy: New page: {{DesignDocument}} == Introduction == This use case describes the process a group manager will use to approve or decline a request from a player to join a group. [[Image:UC_Update_Membe...

{{DesignDocument}}

== Introduction ==
This use case describes the process a group manager will use to approve or decline a request from a player to join a group.

[[Image:UC_Update_Membership_Request.png|Use Case diagram]]

The diagram shows the requirements and rules the use case is responsible for (via the <<requirement>> stereotype).

== Pre-conditions ==
None

== Post conditions ==
The membership request has been updated.

== Requirements and rules realized ==
'''RQ11 Track the status of membership requests''' 
The system shall store and track the status of membership requests. 
* ''BR19 Record change in request status'' 
The system shall record the change in status from 'pending' to 'actioned', and optionally a note, for each request when one of the groups managers has indicated the outcome of the request. 
* ''BR20 Record request result'' 
The system shall record the result of each request which shall be either 'approved' or 'declined', along with the date of the decision, the manager who made it and optionally a note. 
* ''BR21 Membership request information'' 
The system shall record the player, date, group and optionally a note from the player for each membership request. 
* ''BR25 Actioned requests cannot be updated'' 
The system shall prevent a request which has already been actioned from having its result changed. 

'''RQ14 Viewing membership requests''' 
The system shall enable players to view the requests they have submitted. 
* ''BR22 Group managers view all requests'' 
The system shall enable group managers to view all requests, both pending and actioned, for the groups they manage. 

'''RQ16 Format of request list''' 
The system shall format the list of membership requests according to the following rules: BR23, BR24 
* ''BR23 Group by namespace'' 
The system shall enable the actor to view the requests belonging to each namespace separately. 
* ''BR24 Filter by status'' 
The system shall enable the actor to filter the requests by status; viewing only those 'pending', 'resulted', or both. 

'''RQ15 Notify player of changes''' 
The system shall notify the player who submitted the request of any change in its status. 

== Flow of events ==
The flow of events describes the main actor actions and system responses in the execution of the use case.

[[Image:Activity_Update_Membership.png|Activity diagram showing flow of events]]

== Messages ==
<properties>
Step:= BF-3
Condition:= Actor indicated update request
Message Number:= MSG-1
Message Text:= Please confirm that you want to <approve | decline> this request.
</properties>

----

<properties>
Step:= BF-7
Condition:= Request updated
Message Number:= MSG-2
Message Text:= The membership request has been updated, and the player notified of the result.
</properties>

File:Activity Update Membership.png

2011-04-25T02:24:08Z

Grans Remedy: BZFlag Group Management System: Activity Diagram for Update Membership use case.

BZFlag Group Management System: Activity Diagram for Update Membership use case.

File:UC Update Membership Request.png

2011-04-25T02:21:41Z

Grans Remedy: BZFlag Group Management System: use case diagram for update membership request.

BZFlag Group Management System: use case diagram for update membership request.

GMS: Functional Requirements

2011-04-24T23:40:14Z

Grans Remedy: /* Use Cases */

GMS: Join Group

2011-04-24T23:34:47Z

Grans Remedy: /* Requirements and rules realized */

{{DesignDocument}}

== Introduction ==
This use case describes the process a player will use to join a group. Some groups permit anyone to join them, others require that a request be approved by one of the groups managers (or founders).

[[Image:UC_Join_Group.png|Use Case diagram]]

The diagram shows the requirements and rules the use case is responsible for (via the <<requirement>> stereotype).

== Pre-conditions ==
None

== Post conditions ==
The actor has joined a player group or requested membership in a group.

== Included use cases ==
[[Search for Groups]]

== Requirements and rules realized ==
'''RQ10 Private groups are always closed''' 
The system shall prevent the actor from joining a private group. 

'''RQ8 Groups have a membership policy''' 
A groups membership policy determines whether a player can join the group or not. 
* ''BR4 Open groups'' 
The system shall enable any player to join a public group with an open membership policy. 

* ''BR5 By Request groups'' 
The system shall enable any player to request membership of a public group with a by-request membership policy. 

* ''BR6 Closed groups'' 
The system shall prevent any player from joining, or requesting to join, a public group with a closed membership policy. 

'''RQ11 Track the status of membership requests''' 
The system shall store and track the status of membership requests. 
* ''BR7 Alert group managers'' 
The system shall notify group managers of a membership request for a group they manage. 

* ''BR9 Notification format'' 
They system shall use a forum private message, email message, and a message displayed on the group management system main page to alert group managers of pending requests. 

* ''BR10 Prevent duplicate requests'' 
The system shall prevent players from requesting to join a group where they have a request for the same group pending, or a previous identical request was actioned within the last 30 days. 

== Flow of events ==
The flow of events describes the main actor actions and system responses in the execution of the use case.

[[Image:Activity_Join_Group.png|Activity diagram showing flow of events]]

== Messages ==
<properties>
Step:= BF-9
Condition:= Player added to group
Message Number:= Msg 4
Message Text:= You were successfully added to the following group(s) <<added group list>>. Additionally, your requests to join the following groups <<request group list>> have been sent to the respective group managers.
</properties>

GMS: Join Group

2011-04-24T23:33:13Z

Grans Remedy: Added notification format and duplicate request rules

{{DesignDocument}}

== Introduction ==
This use case describes the process a player will use to join a group. Some groups permit anyone to join them, others require that a request be approved by one of the groups managers (or founders).

[[Image:UC_Join_Group.png|Use Case diagram]]

The diagram shows the requirements and rules the use case is responsible for (via the <<requirement>> stereotype).

== Pre-conditions ==
None

== Post conditions ==
The actor has joined a player group or requested membership in a group.

== Included use cases ==
[[Search for Groups]]

== Requirements and rules realized ==
'''RQ10 Private groups are always closed''' 
The system shall prevent the actor from joining a private group. 

'''RQ8 Groups have a membership policy''' 
A groups membership policy determines whether a player can join the group or not. 
* ''BR4 Open groups'' 
The system shall enable any player to join a public group with an open membership policy. 

* ''BR5 By Request groups'' 
The system shall enable any player to request membership of a public group with a by-request membership policy. 

* ''BR6 Closed groups'' 
The system shall prevent any player from joining, or requesting to join, a public group with a closed membership policy. 

'''RQ11 Track the status of membership requests''' 
The system shall store and track the status of membership requests. 
* ''BR7 Alert group managers'' 
The system shall notify group managers of a membership request for a group they manage. 

* ''BR9 Notification format'' 
They system shall use a forum private message, email message, and a message displayed on the group management system main page to alert group managers of pending requests. 

* ''BR10 Prevent duplicate requests'' 
The system shall prevent players from requesting to join a group where they have a request for the same group pending, or their previous request was actioned within the last 30 days. 

== Flow of events ==
The flow of events describes the main actor actions and system responses in the execution of the use case.

[[Image:Activity_Join_Group.png|Activity diagram showing flow of events]]

== Messages ==
<properties>
Step:= BF-9
Condition:= Player added to group
Message Number:= Msg 4
Message Text:= You were successfully added to the following group(s) <<added group list>>. Additionally, your requests to join the following groups <<request group list>> have been sent to the respective group managers.
</properties>

File:Activity Join Group.png

2011-04-24T23:24:08Z

Grans Remedy: uploaded a new version of "Image:Activity Join Group.png": Corrected rules in step AF-2

Activity diagram for flow of events in the Join Group use case

File:Activity Join Group.png

2011-04-24T23:20:32Z

Grans Remedy: uploaded a new version of "Image:Activity Join Group.png": Alternate flow changed to creating request and notifying group managers.

Activity diagram for flow of events in the Join Group use case