===================== Theoretic implementation ===================== The following figure provides some details about classes and interfaces of the implementation. .. raw:: html
Base module implementation ========================== Each component in the :guilabel:`Base` module has been implemented by means of 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 class |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|_. Platforms module implementation =============================== In order to support a new platform, the |Handler|_ and |Service|_ components must be adapted. 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. Languages module implementation =============================== This module includes specific classes for the management of input and output to ASP, Datalog and PDDL solvers. The |Mapper|_ component of the :guilabel:`Languages` module is implemented via a |Mapper|_ class, that allows to translate input and output into Theoretic objects. Such translations are guided by `ANTLR4 `_ library and |Predicate|_ abstract class, also present in the module. To make possible translate facts into strings and vice versa, the classes that want to represent a predicate, must extend the abstract class |Predicate|_, and must be implemented by including the following code: * *predicateName="string_name"* : must be entered as a class field and must contain the predicate name (in the ASP/Datalog case) or the action name (in the PDDL case) to map; * *[("class_field_name_1", int), ("class_field_name_2"), ...]* : Is a list that must be passed to super in the constructor, and must contain so many tuples how many are the class field, containing the field name, sorted by the position of the terms they represent, and optionally the keyword int if the field represents an integer. Thanks to the structure of the |Predicate|_ class, this information is passed to the |Mapper|_ class, to correctly perform the translation mechanism. If the classes intended for the translation are not constructed correctly in this way, an exception is raised. In addition to the |Mapper|_, this module features three sub-modules which are more strictly related to ASP, Datalog and PDDL. Specialization module implementation ==================================== The classes |DLVAnswerSets|_, |DLV2AnswerSets|_, |ClingoAnswerSets|_, |DLVHEXAnswerSets|_ implement specific extensions of the |AnswerSets|_ class, the |SPDPlan|_ class extends |Plan|_, while |IDLVMinimalModels|_ extends |MinimalModels|_ . These classes are in charge of manipulating the output of the respective solvers (e.g. IDLV). Moreover, this module can contain classes extending |OptionDescriptor|_ to implement specific options of the solver at hand. Class Diagram ============= A complete UML Class Diagram is available `here <../_static/complete_diagram_theoretic.svg>`_. | For further information, contact `embasp@mat.unical.it `_ or visit our `website `_. .. |Handler| replace:: ``Handler`` .. |InputProgram| replace:: ``InputProgram`` .. |OptionDescriptor| replace:: ``OptionDescriptor`` .. |Service| replace:: ``Service`` .. |CallBack| replace:: ``CallBack`` .. |DesktopHandler| replace:: ``DesktopHandler`` .. |DesktopService| replace:: ``DesktopService`` .. |Mapper| replace:: ``Mapper`` .. |Predicate| replace:: ``Predicate`` .. |DLVAnswerSets| replace:: ``DLVAnswerSets`` .. |DLV2AnswerSets| replace:: ``DLV2AnswerSets`` .. |ClingoAnswerSets| replace:: ``ClingoAnswerSets`` .. |DLVHEXAnswerSets| replace:: ``DLVHEXAnswerSets`` .. |SPDPlan| replace:: ``SPDPlan`` .. |AnswerSets| replace:: ``AnswerSets`` .. |Plan| replace:: ``Plan`` .. |IDLVMinimalModels| replace:: ``IDLVMinimalModels`` .. |MinimalModels| replace:: ``MinimalModels`` .. _Handler: ../_static/doxygen/theoretic/classbase_1_1handler_1_1Handler.html .. _InputProgram: ../_static/doxygen/theoretic/classbase_1_1input__program_1_1InputProgram.html .. _OptionDescriptor: ../_static/doxygen/theoretic/classbase_1_1option__descriptor_1_1OptionDescriptor.html .. _Service: ../_static/doxygen/theoretic/classbase_1_1service_1_1Service.html .. _CallBack: ../_static/doxygen/theoretic/classbase_1_1callback_1_1Callback.html .. _DesktopHandler: ../_static/doxygen/theoretic/classplatforms_1_1desktop_1_1desktop__handler_1_1DesktopHandler.html .. _DesktopService: ../_static/doxygen/theoretic/classplatforms_1_1desktop_1_1desktop__service_1_1DesktopService.html .. _Mapper: ../_static/doxygen/theoretic/classlanguages_1_1mapper_1_1Mapper.html .. _Predicate: ../_static/doxygen/theoretic/classlanguages_1_1predicate_1_1Predicate.html .. _DLVAnswerSets: ../_static/doxygen/theoretic/classspecializations_1_1dlv_1_1dlv__answer__sets_1_1DLVAnswerSets.html .. _DLV2AnswerSets: ../_static/doxygen/theoretic/classspecializations_1_1dlv2_1_1dlv2__answer__sets_1_1DLV2AnswerSets.html .. _ClingoAnswerSets: ../_static/doxygen/theoretic/classspecializations_1_1clingo_1_1clingo__answer__sets_1_1ClingoAnswerSets.html .. _DLVHEXAnswerSets: ../_static/doxygen/theoretic/classspecializations_1_1dlvhex_1_1dlvhex__answer__sets_1_1DLVHEXAnswerSets.html .. _IDLVMinimalModels: ../_static/doxygen/theoretic/classspecializations_1_1idlv_1_1idlv__minimal__models_1_1IDLVMinimalModels.html .. _SPDPlan: ../_static/doxygen/theoretic/classspecializations_1_1solver__planning__domains_1_1spd__plan_1_1SPDPlan.html .. _AnswerSets: ../_static/doxygen/theoretic/classlanguages_1_1asp_1_1answer__sets_1_1AnswerSets.html .. _MinimalModels: ../_static/doxygen/theoretic/classlanguages_1_1asp_1_1minimal__models_1_1MinimalModels.html .. _Plan: ../_static/doxygen/theoretic/classlanguages_1_1pddl_1_1plan_1_1Plan.html