Practical work on Organisation Oriented Programming: The Moise Framework

Introduction

The MOISE distribution is available from http://moise.sourceforge.net/ or here locally (current version is 0.9.beta).

Configuration

  • Download and install the MOISE distribution in the MAOP directory to have the complete distribution with examples, documentation and tutorial.

Preamble

  • Each agent has the possibility to participate to the management of the organization by the way of the organisational artifacts: GroupBoard and SchemeBoard

GroupBoard

Organizational operations

They are made available to agents through organizational actions. They are:

  • 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

Organizational operations

They are made available to agents through organizational actions. They are:

  • 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 11

  • Let's go back to the refactoring issued from the last practical work on EOP

Exercise: Using a world of artifacts

  • Download the code for this step and install it in your eclipse workspace as a jason 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.

Step 12

  • In order to install some coordination, let's use an organization which provides us with the right mean to install an explicit and changeable coordination pattern.
  • The org-spec.xml file contains the definition of an organization specification based on the MOISE organization language. This is a very first organisation structure and functional specifications assigning goals to agents (one role, mission/goal and norm 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

Exercise: Coordinated use of a world of artifacts

  • Download the code for this step and install it in your eclipse workspace as a jason project.
  • Define a group of three to four students. Each group launches only one MAS server. Each user launches a MAS client.
  • Use the GUI agent in your MAS client and try to enter the organization following the dynamic of the organization as explained in the course. Thanks to the GUI agent, 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 inspector, the organizational artifacts (groupboard and schemeboard), detect the violations

Exercise : Changing 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)

Step 13

  • We will reuse the previous example and will automate some of the actions for creating/instantiating the organisation.
  • You could have a look at the way the deployement of the organisation management infrastructure is done in the MAS server (org_majordomo)

Exercise: Adopting 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.

Exercise: Making a 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

Exercise: Making 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

Exercise: Managing 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

Practical work on Multi-Agent Oriented Programming: Builing 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.
Olivier Boissier, May 2013