As mentioned above, we provide a Java implementation of the EmbASP framework.

The following figure provides some details about classes and interfaces of the implementation.

Core module implementation

Each component in the Core module has been implemented by means of an homonymous class or interface.

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.

As for the Android platform, we developed an AndroidHandler that handles the execution of an AndroidService, which provides facilities to manage the execution of an ASP reasoner on the Android platform.

Similarly, for the desktop platform we developed a DesktopHandler and a DesktopService, which generalizes the usage of an ASP reasoner 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 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 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.

Systems Module Implementation

The classes DLVAnswerSets, ClingoAnswerSets, DLV2AnswerSets 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.

The Javadoc documentation is available here.

For an offline usage, you can download it here.

How to import the framework on Android Studio

In order to use the framework in your applications you have to import it as module on Android Studio.

1. Import the framework module:
   1. Download the framework last released module.
   2. In the project view, right-click on your project New > Module.
   3. Select Import .JAR/.AAR Package.
   4. Select the directory in which the module has been downloaded.
2. Set the dependency:
   1. In the Android Studio menu: File > Project Structure.
   2. Select your project module (by default called app).
   3. In the Dependencies Tab add as Module Dependency the previously imported framework.

In the following, we describe an the actual usage of the framework by means of a running example; as a use case, we will develop a simple Android application for solving Sudoku puzzles.

The complete code of this example is freely available here. Please note that the zip file contains an Android Studio (version 2.3) project and uses the version 3.1.0 of EmbASP.

The framework features a annotation-guided mapping, offered by the ASPMapper component, for two-way translations between strings recognizable by ASP solvers and objects in the programming language at hand, directly employable within applications. By means of this feature, the ASP-based aspects can be separated from the Java coding: the programmer doesn't even necessarily need to be aware of ASP.

Let us think of a user that designed (or has been given) a proper logic program P to solve a sudoku puzzle and has also an initial schema. We assume that the initial schema is well-formed i.e. the complete schema solution exists and is unique. A possible program P is embedded in the complete example, that, coupled with a set of facts F representing the given initial schema, allows to obtain the only admissible solution.

By means of the annotation-guided mapping, the initial schema can be expressed in forms of Java objects. To this extent, we define the class Cell, aimed at representing the single cell of the sudoku schema, as follows:

    @Id("cell")
    public class Cell {
    
        @Param(0)
        private int row;
        
        @Param(1)
        private int column;
        
        @Param(2)
        private int value;
        
        [...]
        
    }           
                

It is worth noticing how the class has been annotated by two custom annotations, defined according to the following syntax:

• @Id(string_name): the target must be a class, and defines the predicate name 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 ASP atom the field is mapped to.

Thanks to these annotations the ASPMapper class will be able to map Cell objects into strings properly recognizable from the ASP solver as logic facts of the form cell(Row,Column,Value). At this point, we can create an Android Activity Component, and start deploying our sudoku application:

    public class MainActivity extends AppCompatActivity {
	
        [...]
        private Handler handler;
    
        @Override
        protected void onCreate(Bundle bundle) {
            handler = new AndroidHandler(getApplicationContext(), DLVAndroidService.class);
            [...]
        }
        
        public void onClick(final View view){
            startReasoning();
            [...]
        }
    
        public void startReasoning() {
            InputProgram inputProgram = new InputProgram();
            for (int i = 0; i < 9; i++){
                for (int j = 0; j < 9; j++)
                    try {
                        if(sudokuMatrix[i][j]!=0) {
                            inputProgram.addObjectInput(new Cell(i, j, sudokuMatrix[i][j]));
                        }
                    } catch (Exception e) {	
                    	// Handle Exception 
                    }
            }
            handler.addProgram(inputProgram);
    
            String sudokuEncoding = getEncodingFromResources();			
            handler.addProgram(new InputProgram(sudokuEncoding));
    
            Callback callback = new MyCallback();
            handler.startAsync(callback);
        }
    }
            

The class contains an Handler instance as field, that is initialized when the Activity is created as an AndroidHandler. Required parameters include the Android Context (an Android utility, needed to start an Android Service Component) and the type of AndroidService to use, in our case a DLVAndroidService.

In addiction, in order to represent an initial sudoku schema, the class features a matrix of integers as another field where position (i,j) contains the value of cell (i,j) in the initial schema; cells initially empty are represented by positions containing zero.

The method startReasoning is in charge of actually managing the reasoning: in our case, it is invoked in response to a click event that is generated when the user asks for the solution. It is firstly created an InputProgram object that is filled with Cell objects representing the initial schema, which is then provided to the handler; then it is provided with the sudoku encoding. It could be loaded, for instance, by means of an utility function that retrieves it from the Android Resources folder, which, within Android applications, is typically meant for containing images, sounds, files and resources in general.

At this point, the reasoning process can start; since for Android we provide only the asynchronous execution mode, a callback object is in charge of fetching the output when the ASP system has done.

Finally, once the computation is over, from within the callback function the output can be retrieved directly in form of Java objects. For instance, in our case an inner class MyCallback implements the interface Callback:

    private class MyCallback implements Callback {

        @Override
        public void callback(Output o) {
            if(!(o instanceof AnswerSets))
                return;
            AnswerSets answerSets=(AnswerSets)o;
            if(answerSets.getAnswersets().isEmpty())
                return;
            AnswerSet as = answerSets.getAnswersets().get(0);
            try {
                for(Object obj:as.getAtoms()) {
                    Cell cell = (Cell) obj;
                    sudokuMatrix[cell.getRow()][cell.getColumn()] = cell.getValue();
                }
            } catch (Exception e) {
                // Handle Exception
            }
            displaySolution();
        }
    }
		

The framework is released as JAR file to be used on a Desktop platform, therefore it can be easily imported and used in any Java project.

The SPD solver is invoked via an HTTP connection using JSON files as data interchange format. In order to manage them, the framework needs the json-simple library (you can download the JAR and include directly in your project or you can use Gradle or Maven)

In the following, we describe an the actual usage of the framework by means of a running example; as a use case, we will develop a simple Desktop application to solve the blocks-world problem.

The complete code of this example is freely available here. Please note that the zip file contains an Eclipse (Neon) project and uses the version 3.1.0 of EmbASP.

We will make use of the annotation-guided mapping, in order to retrieve the actions constituting a PDDL plan via Java objects. To this purpose, the following classes are intended to represent possible actions that a blocks-world solution plan can feature:

    @Id("pick-up")
    public class PickUp {

        @Param(0)
        private String block;

        [...]
    }
                

    @Id("put-down")
    public class PutDown {

        @Param(0)
        private String block;

        [...]
    }
                

    @Id("stack")
    public class Stack {

        @Param(0)
        private String block1;

        @Param(1)
        private String block2;
        
        [...]
    }
                

    @Id("unstack")
    public class Unstack {

        @Param(0)
        private String block1;

        @Param(1)
        private String block2;
        
        [...]
    }         
                

At this point, supposing that we are given two files defining the blocks-world domain and a problem instance, we can start deploying our application:

    public class Blocksworld {
        
        private static String domainFileName = "domain.pddl";
        private static String problemFileName = "p01.pddl";;

        public static void main(String[] args) {
            Handler handler = new DesktopHandler(new SPDDesktopService());
            
            final InputProgram inputProgramDomain = new PDDLInputProgram(PDDLProgramType.DOMAIN);
            inputProgramDomain.addFilesPath(domainFileName);

            final InputProgram inputProgramProblem = new PDDLInputProgram(PDDLProgramType.PROBLEM);
            inputProgramProblem.addFilesPath(problemFileName);

            handler.addProgram(inputProgramDomain);
            handler.addProgram(inputProgramProblem);

            try {

                PDDLMapper.getInstance().registerClass(PickUp.class);
                PDDLMapper.getInstance().registerClass(PutDown.class);
                PDDLMapper.getInstance().registerClass(Stack.class);
                PDDLMapper.getInstance().registerClass(Unstack.class);

                Plan plan = (Plan)(handler.startSync());
                
                for (final Object obj : plan.getActionsObjects())
                        //Manage objects as needed
                        
            } catch (Exception e) {
                // Handle Exception
            }
        }
    }
            

The class contains an Handler instance as field, that is initialized with a DesktopHandler using the required parameter SPDDesktopService.

Then it's set-up the input to the solver; since PDDL requires separate definitions for domain and problem, two PDDLInputProgram are created and then given to the handler.

The next lines inform the PDDLMapper about what classes are intended to map the output actions.

Finally the solver is invoked, and the output is retrieved. The output actions can be managed accordingly to the user's desiderata.