JACK——TeamsMaual6 Team Formation

来源：http://aosgrp.com/

 

6 Team Formation

 

This chapter describes team formation. It includes a description of the process that occurs when sub-teams are attached to the role obligation structure of a containing team. During the process of attachment/detachment, the associated role instances pass through various states. This process of attachment is carried out during the initialisation phase when the team is constructed. In addition, it is possible to have sub-teams dynamically attached/detached to the role obligation structure while the application is running.

Teams have a capability, TeamCap. This capability includes plans that handle the initial team formation with the sub-tasking and default handling of a TeamFormationEvent, and the posting of a StartTeamEvent. The initialisation process is triggered automatically as part of the team instance construction.

An application may override the handling of a TeamFormationEvent simply by defining a plan that handles the event (the default plan is of precedence rank 0, and therefore a new plan – with standard rank 5 – will have higher precedence.)

The TeamCap capability also includes handling of RoleControl events. These events are posted by the application level to assign or revoke a sub-team as a role performer. When they are posted, the infrastructure layer posts additional events that result in any negotiation and detachment/attachment required to connect a sub-team to a containing team. The application layer may include plans that are involved in the negotiation and/or react to the success or failure of attachment/detachment. The RoleControl events therefore allows dynamic modification of role obligation structures during the lifetime of an application.

If the application layer requires a non-JACK agent/team (e.g. an agent written in an alternative language) to perform a role, the application code would need to carry out the attachment and negotiation on both sides of the relationship without the use of RoleControl events.

 

6.1 RoleType Instance State Management

A RoleType instance can be in one of three states (INACTIVE, ACTIVE or DETACHED). When the RoleType object is created, it is initially in the ACTIVE state. However, it will not be available/visible until it is actually added to a role container. The posting of a RoleControl event constructed using the assign posting method results in an attempt to add the RoleType object to the specified role container. If the object is successfully added to the role container, then the object will be in the ACTIVE state.

When the team revokes a role, the RoleType object is placed in the DETACHED state. This means that any plans that already have access to the object can continue to access the object but no new activity should be allowed access the object. It is the users responsibility to check the state of the RoleType object.

The RoleType object will change from the DETACHED to the INACTIVE state when the team filling the role finishes processing all tasks associated with the role. It will also be removed from the role container at that point.

The interaction diagram in the following figure illustrates the interaction between a tendering team and a suggested role performer for processing an ASSIGN action.

Figure 6-1: Interactions for adding a role performer

On the tendering team side, the ASSIGN action is initiated via a RoleControl(ASSIGN) event, that asks for the addition of a role performer to a given RoleContainer. This is a synchronous request, and the RoleControl handler does not return control to the invoking task after having issued the SubTeamProtocol(ASSIGN) message, but waits until the actor team has processed and replied to it.

On the (suggested) performer side, the infrastructure layer queries the application level whether the suggested addition is to be accepted. This is done by sub-tasking a RoleEvent(QUERY) event, to be handled by the application level and passed or failed. If the event handling fails, the suggested action is understood as rejected, and a SubTeamProtocol(REJECT) message is sent to the tendering team. This results in a transition for the RoleType instance to Void state (i.e. the RoleType instance is marked as Detached and it is removed from the RoleTypeContainer). Further, a RoleEvent(REJECTED) is posted on the tenderer team side, so as to allow application level reasoning about the rejected addition.

If the handling of the RoleEvent(QUERY) event succeeds, the suggested action is understood as accepted, and a SubTeamProtocol(ACCEPT) message is sent to the tendering team. This results in a RoleType instance state transition to Active, and the posting of a RoleEvent(ASSIGNED) event, so as to allow application level reasoning about the accepted addition. On the performer side, a RoleEvent(ASSIGN) event is posted to notify about a successful assignment.

The following figure illustrates the interaction between a tendering team and a suggested role performer for processing a REVOKE action.

Figure 6-2: Interactions for removing a role performer}}

On the tendering team side, the REVOKE action is initiated via a RoleControl(REVOKE) event, that asks for the removal of a role performer from a given RoleContainer. This is a synchronous request, and the RoleControl handler does not return control to the invoking task directly after having issued the SubTeamProtocol(REVOKE) message, but waits until the actor team has processed and replied to it. First, however, the RoleType instance concerned is marked as Detached, to block subsequent attempts to issue further team tasks to the role performer.

On the performer side, the infrastructure then waits until all tasks under the role have been completed before returning a SubTeamProtocol(CONFIRM) message to the role tendering team. As application level notifications, RoleEvent(REMOVE) and RoleEvent(REMOVED) events are posted on the performer and tendering sides respectively.

 

6.2 Role Handling Events and Messages

SubTeamProtocol [sent and handled event]

The SubTeamProtocol event is used for the role handling protocol between teams. This is an infrastructure message event that is not used at application level.

RoleControl [handled event]

The RoleControl event is posted by the application level for assigning or revoking a sub-team to be a role performer. The same event type is used for both ASSIGN and REVOKE actions, and it is defined with a range of posting methods.

      event RoleControl extends Event {

          #posted as

          assign(String role, String container, String actor)

          // role is the role type

          // container is the reference to the role container

          // actor is the team name (to be assigned)

          #posted as

          revoke(String role, String container, String actor)

          // role is the role type

          // container is the reference to the role container

          // actor is the team name (to be revoked)

      }

RoleControl(ASSIGN)

The ASSIGN action event is constructed through the assign posting method. This is handled by the infrastructure, resulting in the team interaction to establish the given actor as role filler. For example:

        import martian.Crew;

        teamplan RescueMartian extends TeamPlan {

            #handles event Rescue re;

            #posts event RoleControl rc;

            #uses interface Team team;

            body()

            {

               // post a RoleControl event to add a sub-team

               // to the role obligation structure

               if(@subtask(rc.assign("martian.Crew", "cr", re.name)))

                   System.out.println("rescued "+re.name);

               else

                   System.out.println("could not rescue "+re.name);

             }

          }

RoleControl(REVOKE)

The REVOKE action event is constructed through the revoke posting method. This is handled by the infrastructure, resulting in the team interaction to revoke the given actor as role filler.

RoleEvent [posted event]

The infrastructure posts RoleEvent events to connect with the application level for notifications and application level reasoning. The event is a polymorphic event that is posted in different modes for different purposes.

      event RoleEvent extends BDIGoalEvent {

          #set behavior Recover never;

          public String team;

          public String container;

          public String role;

          public int mode;

          public final static int QUERY = -1;

          public final static int REJECT = 0;

          public final static int ASSIGN = 1;

          public final static int REJECTED = 2;

          public final static int ASSIGNED = 3;

          public final static int REMOVE = 5;

          public final static int REMOVED = 7;

      }

RoleEvent(QUERY)

The QUERY mode is sub-tasked by the infrastructure while handling a role performer ASSIGN action, and the purpose is for the application level to decide whether or not the proposed addition should be accepted. If the event handling succeeds, the addition is accepted, and if it fails, the addition is rejected.

RoleEvent(REJECT)

The REJECT mode is posted by the infrastructure for the role performer as a notification that the addition has been rejected.

RoleEvent(ASSIGN)

The ASSIGN mode is posted by the infrastructure for the role performer as a notification that the addition has been accepted.

RoleEvent(ASSIGNED)

The ASSIGNED mode is posted by the infrastructure for the role tenderer as a notification that the addition has been accepted.

RoleEvent(REJECTED)

The REJECTED mode is posted by the infrastructure for the role tenderer as a notification that the addition has been rejected.

RoleEvent(REMOVE)

The REMOVE mode is posted by the infrastructure for the role performer as a notification that the team has been removed as performer of a role.

RoleEvent(REMOVED)

The REMOVED mode is posted by the infrastructure for the role tenderer as a notification that a team has been removed as performer of a role.

转载于:https://www.cnblogs.com/6DAN_HUST/archive/2012/04/06/2434887.html