Organisation Oriented Programming
Practical work using MOISE within JaCaMo
Table of Contents
Introduction
In the following, you will use a MAS with an organization deployed on a MAS running on multiple machines. You will use and then develop a normative organization coordinating and regulating the cooperation among autonomous agents interacting on a shared environment. As in the previous set of practical works done in the EOP approach of JaCaMo, the code is organized into two JaCaMo configuration files (.jcm): one for the MAS "kind-of" server, one for the MAS "kind-of" client.
- The MAS server part ("step_main.jcm") provides you with the configuration file where (i) some artifacts are deployed in the "server" workspace, (ii) the organization is deployed
- The MAS client part ("step.jcm") is refering to the agents that you will have to customize or develop. These agents will connect on the remote workspace to use artifacts that are deployed on this remote workspace.
They will also enter the organization by adopting roles and committing to missions.
Configuration
- The standalone MOISE distribution can be downloaded from http://moise.sourceforge.net/.
- However, being already part of the JaCaMo Platform that you installed in the previous step (cf. Introduction), you don't have anything more to do to configure your working environment.
- In this part of the practical work, we will use the Eclipse IDE with the JaCaMo plugin.
Preamble
- Being part of an organization means for an agent to be able to get the current state of the organization entity and to execute organizational actions on the organization entity. Actions and current state are brought to the agents by organisational artifacts: GroupBoard and SchemeBoard
GroupBoard (see the GroupBoard API)
Organizational actions (i.e. organizational artifact operations):
- adoptRole(String role): the agent tries to adopt role in the group
- leaveRole(String role): the agent tries to give up role/in the group + *addScheme(String schId)*: the group starts being responsible for the scheme /schId
- removeScheme(String schId): the group finishes being responsible for the scheme schId
- setParentGroup(String parentGroupId) : the group becomes a subgroup of parentGroupId
Organization observable properties
They are Java objects that are mapped into an agent's beliefs - annotated with artifact(artifact id) -. They are:
- specification(….): the specification of the group in the OS (a prolog like representation) as follows: group_specification(group type id, list of role, list of sub-groups, properties).
- Each role in the list is: role(id,min cardinality, max cardinality, list of compatible roles, list of links), each link is: link(type, target, scopo) (see explanations)
- play(agent, role, group): agent agent is playing the role in the group.
- schemes: a list of schemes ids the group is responsible for.
- subgroups: a list of subgroups ids
- parentGroup: the id of the parent group (used in subgroups)
- formationStatus: whether the group is well-formed (values are ok and nok)
Organizational signals
They are mapped into agent's organizational events. They are:
- oblCreated(o): the obligation o is created
- oblFulfilled(o): the obligation o is fulfilled
- oblUnfulfilled(o): the obligation o is unfulfilled (e.g. by timeout)
- oblInactive(o): the obligation o is inactive (e.g. its condition does not hold anymore)
- normFailure(f): the failure f has happened (e.g. due to some regimentation violation)
- destroyed(artifact id): artifact has been destroyed.
- obligation(agt, norm, what, deadline)
SchemeBoard (see the SchemeBoard API)
Organizational actions (i.e. organizational artifact operations):
- commitMission(String mission): the agent tries to commit to a mission in the scheme (verifications of the mission max cardinality and mission permissions, throwing normFailure in the case of breaking some regimentation)
- leaveMission(String mission): the agent tries to leave/remove its mission in the scheme (verifications that the agent is committed to the mission and that the mission's goals have been satisfied throwing a normFailure in the case of breaking some regimentation)
- goalAchieved(String goal): the agent sets the goal as achieved (verifications that the agent is committed to the goal and that the goal has been enabled throwing a normFailure in the case of breaking some regimentation)
- setArgumentValue(String goal, String var, Object value): the agent sets a value for the goal argument var
Organization observable properties
They are Java objects that are mapped into an agent's beliefs - annotated with artifact(artifact id) - (see SchemeBoard API). They are:
- specification(….) for schemes are (see explanations): scheme_specification(id,goals tree starting by root goal,missions).
- commitment(agent, mission, scheme) agent ag is committed to the mission in the scheme (we have as many obs prop as commitments)
- groups: a list of groups responsible for the scheme.
- goalState(schId, goalId, list of committed agents, list of agents that achieved the goal, state); where state refers to the goal status: waiting, enabled, satisfied).
- obligation(agent,norm,goal,deadline): the current active obligations.
Organizational signals
They are mapped into agent's organizational events. They are:
- oblCreated(o): the obligation o is created
- oblFulfilled(o): the obligation o is fulfilled
- oblUnfulfilled(o): the obligation o is unfulfilled (e.g. by timeout)
- oblInactive(o): the obligation o is inactive (e.g. its condition does not hold anymore)
- normFailure(f): the failure f has happened (e.g. due to some regimentation violation)
- destroyed(artifact id): artifact has been destroyed.
- obligation(agt, norm, what, deadline)
Step 12: Using an Organization Specification
- Let's go back to the refactoring issued from the last practical work on EOP (step 6)
a. Use a world of artifacts
- Download the code for this step and install it in your maop eclipse workspace as a jacamo project.
- Look at the code of the "user_agent" that uses these artifacts and run the example launching the MAS server and the client one.
Coordinate !! Coordinate !!
- In order to install some coordination, let's use an organization which defines an explicit and changeable coordination pattern among the agents: roles, missions/goals and norms for having a set of agents in charge of observing, another set of agents in charge of computing, another set of agents in charge of putting messages.
- This specification is a follows:
- Structural specification: the possible roles are: greeter, observer, computer
- Functional specification: possible goals are compute, greeting, observe, the missions are mCompute, mGreeting, mObserve
- Normative specification is straightforward: permissions for each role, each mission
b. Coordinate the use of a world of artifacts by organizing agents
- Download the code for this step and install it in your maop eclipse workspace as a jacamo project.
- The org-spec.xml file in src/org contains the definition of the organization specification described above. It is defined using the MOISE organization language.
- To use this code, you will be an agent of the MAS by using a GUI artifact in the MAS client (Scheme Console and Group Console). Thaks to them you will be able to interact with the MAS system as if you were an agent of the organization.
- To ease the test, you can define a group of three to four students. One student of the group executes the main configuration file (i.e. execution of the MAS server part) – one server per group only. All the members of the group executes the other configuration file after having updated the join remote workspace action with the IP of the machine on which the server is running – one client per member of the group.
- Take care to follow the life cycle of the organization as explained in the course. Thanks to the GUI artifact, you can decide to adopt a role, to commit to a mission, to declare the achievement of some goal
- Look at the execution using either the agent inspector to watch the evolution of the mental state of the agent, or the organization inspector to watch the evolution of the organization state in the groupboards and schemeboards, to detect the violations
c. Change the organization specification
- Change the specification of the organisation (e.g. cardinality of roles, order of the goals, …) and see how it changes the functionning of the agents
- Modify the organisation specification in order to force to have at least two agents playing the role gretter in the group.
- Modify the organisation specification so that the role greeter is obliged to commit to mission mCompute (after testing, undo your change)
Learned features
In this step, you have learned:
- How to use the organization specification
- What is the life cycle of an organization in the MOISE framework
- How to change and define organization specification
Step 13: Reasoning on the Organization
- We will reuse the previous example and will automate some of the actions for creating/instantiating the organisation.
- You can have a look at the way the deployement of the organisation management infrastructure is done in the MAS server (org_majordomo)
- You can also have a look at the code of org_agent that is realising some very simple automated reasoning on the organization
d. Make your agent adopt a role
- Choose a role to be adopted by your agent
- Add in your code the plan so that your agent adopts the chosen role as soon as the group has been created (i.e. the corresponding groupBoard artifact has been deployed)
- Add in your code the plan so that your agent leaves its current role as soon as another agent adopts the same role in his/her group and the group is not yet well formed. After leaving the agent adopts another role.
e. Make the group responsible of a social scheme
- make your group responsible of the social scheme deployed in the schemeBoard artifact, as soon as the group is well formed.
- From that moment, agents that are playing roles in the group, have the possibility to execute the missions of the scheme under the responsibility of the group.
How to test the status of a group
- As soon as the group is well formed, a new belief formationStatus is generated into the agent's belief base
f. Make an obedient agent
- Add a plan in the agent's code so that this agent is an obedient one: as soon as one obligation, that concerns it, is created, it fullfills the obligation
What does it mean to fulfill an obligation
- fulfilling an obligation for a mission means committing to that mission
- fulfilling an obligation for a goal means achieving that goal
g. Manage the reputation of an agent
- Add a plan in the agent's code so that each time an agent of its group fulfills an obligation, it broadcasts a message in order to increase the reputation of that agent
How to know that an obligation has been fulfilled
- as soon as an obligation is fulfilled, the signal oblFulfilled is generated by the artifacts
Learned features
In this step, you have learned:
- How to do some basic reasoning on the organization
Step 14: Coming back to the Gold Miners Tutorial
Coming soon …
Step 15: Coordinated Builing of Giacomo's House
- In this exercise, you will develop the second part of the building house multi-agent system aiming at managing the execution of the general workflow describing the tasks to build an house (see eop practical lesson.
- A possible partial implementation of this application is available as a tutorial of the jacamo platform available at http://jacamo.sourceforge.net. You can use it as starting point (you already have started to develop this application while building the auction house).
- The description of the steps and design choices are available here.
Exercise:
- Develop an agent that tries to adopt roles related to tasks he/she is not supposed to (malevolent agent)
- Develop an agent that does not fulfill the tasks
- Change the Giacomo agent so that it is able to monitor the building of the house and check whether the tasks are being done appropriately: reacting to the norm violation, to the norm fulfillement.
- Add any improvement you wish.