This is the implementation of GoOrg (PAAMS'19 and EMAS'19 papers available) project. GoOrg is a method for automatic creation of organisations. This demand comes from complex projects of multiple systems working in a coordinated way in order to achieve mutual goals which are situations where Multi-Agent Systems are often applied. To design such systems it is necessary to define how they will work together, i.e., how they will be organised which can be a tough task for humans encharged for the design of the whole system. To track this problem and help humans to easier develop Multi-Agent Systems we propose GoOrg for generating the organisational structure of the system.
To run it use ./gradlew run. It should grab all dependencies of the project and run a very simple example which is a small goals tree asking for the most specialist roles, which is generating an organisational chart similar to the given goals tree, i.e., one role to perform each goal.
A graphviz representation (.gv file) of the input and of the output should be created in the folder output/diagrams. For search for one solution only, it is generated by default the PNG of the gdt and the solution in the folder output/graphs. For generating PDF of all .gv files, in *nux systems, assuming it has dot installed, just run the script ./createPDF.sh. The pdf files also go to output/graphs. The results are also stored in two statistic files in output/statistics, one file for the generation process and another for the binding process. The files are similar, each row representing a solution found, the most important difference is the column feasible filled by the binding process. The id corresponds to the id of created graphviz representation. Each time it runs the algorithm clean the output folders, so to keep the results it is necessary to make a copy before a running again.
In the class SimpleLogger there is a setting for printing output to standard console or to a file called log.log that is stored in the project root folder.
To run the simple embedded example with other cost functions and search approaches leave the first argument as "0" and use the second argument to select a cost function (see cost enumeration in javadocs for details). Currently the search approach used is BFS (Breadth First Search). Examples:
$ ./gradlew run --args="0 GENERALIST"
$ ./gradlew run --args="0 SPECIALIST"
To run other examples just refer to the corresponding moise organisational description file, choosing the cost function. It also supports multiple cost functions. In this case, the latter have higher priority. Examples:
$ ./gradlew run --args="examples/Paint_House.xml FLATTER GENERALIST"
$ ./gradlew run --args="examples/Full_Link.xml TALLER SPECIALIST EFFICIENT"
It is available an integrated test of all cost functions among other unit tests. For running these tests getting text output, execute:
$ ./gradlew test -i
Currently, the project is using as input a goal decomposition tree with skills annotated on it. There are four possible transformations which is (i) for creating the root role, (ii) for creating subordinates, (iii) for joining a subordinate into an existing role, and (iv) for joining a pair into an existing role. Next version will add more annotation in order to improve the roles creation process which will allow the creation of coordinatiors, departments and so on.
To add this project to eclipse use Import > Gradle > Existing Gradle Project.
Other approaches that under study are DFS (Depth First Search) and A*.
The javadoc documentation is available!