The following figure provides some details about classes and interfaces of the implementation.
* {box-sizing: border-box;} .img-magnifier-container { position:relative; } .img-magnifier-glass { position: absolute; border: 3px solid #000; border-radius: 50%; cursor: none; /*Set the size of the magnifier glass:*/ width: 220px; height: 220px; }
Each component in the Base module has been implemented by means of an abstract class, generic class or interface that will specialize in the following packages.
In particular, the Handler_ class collects InputProgram_ and OptionDescriptor_ objects communicated by the user.
For what the asynchronous mode is concerned, the interface Service_ depends from the interface CallBack_, since once the reasoning service has terminated, the result of the computation is returned back via a class CallBack_.
In order to support a new platform, the Handler_ and Service_ components must be adapted.
As for the Android platform, we developed an AndroidHandler_ that handles the execution of an AndroidService_, which provides facilities to manage the execution of a solver on the Android platform.
Similarly, for the desktop platform we developed a DesktopHandler_ and a DesktopService_, which generalizes the usage of a solver on the desktop platform, allowing both synchronous and asynchronous execution modes.
This module includes specific classes for the management of input and output to ASP and PDDL solvers.
The Mapper_ component of the Languages module is implemented via a Mapper_ class, that allows to translate input and output into Java objects. Such translations are guided by ANTLR4 library and Java Annotations , a form of metadata that mark Java code and provide information that is not part of the program itself: they have no direct effect on the operation of the code they annotate.
In our setting, we make use of such feature so that it is possible to translate facts into strings and vice-versa via two custom annotations, defined according to the following syntax:
- @Id (string_name) : the target must be a class, and defines the predicate name (in the ASP case) and the action name (in the PDDL case) the class is mapped to;
- @Param (integer_position) : the target must be a field of a class annotated via @Id, and defines the term (and its position) in the atom (in the ASP case) and in the action (in the PDDL case) the field is mapped to.
By means of the Java Reflection mechanisms, annotations are examined at runtime, and taken into account to properly define the translation.
If the classes intended for the translation are not annotated or not correctly annotated, an exception is raised.
In addition to the Mapper_, this module features two sub-modules which are more strictly related to ASP and PDDL.
The classes DLVAnswerSets_, DLV2AnswerSets_, ClingoAnswerSets_, DLVHEXAnswerSets_ and SPDPlan_ implement specific extensions of the AnswerSets_ or Plan_ classes, in charge of manipulating the output of the respective solvers.
Moreover, this module can contain classes extending OptionDescriptor_ to implement specific options of the solver at hand.
A complete UML Class Diagram is available here.
For further information, contact embasp@mat.unical.it or visit our website.