Execution

After pushing the model to the Kevoree runtime, a console appears allowing us to interact with the SMS module. We initiate a query about (sms : dispatchSMS) on the console by typing dispatchSMS on the console of the SMSModule.ii

The SMS module starts a new query servant which initiates in its turn a new query about (hcs : emergency). This query is captured by the interceptor and it is displayed on the graph GUI; in fact two nodes representing the SMSModule and HCS are added to the graph. If the demo mode of the interceptor is selected, the user has to click on Next button each time to forward a query from one component to another. This step-by-step mode is very useful to understand the actual interactions and to slow down the exchanges.

The knowledge base of hcs contains one rule supporting (hcs : emergency), M2, and another one supporting its negation, M1. hcs evaluates both rules and resolves the conflict using its preference order. Finally, it sends back the result of the query to the first query servant, which in turn computes and returns a positive truth value for (sms : dispatchSMS). Each time a query or a query response is generated from any component and dispatched to any other, the interceptor captures it, adds it to the graph, and waits for the user to click Next before forwarding the query or the response to the appropriate component.

Figure 7.6: Different steps of execution of the running example.

ii_{You can run the demo and access its source code and all other necessary files at:}

https://github.com/

securityandtrust/ruleml13.

Screen-shots from the demo during different steps of execution are displayed in figure7.6. Following this, the SMS module will display, on the console connected to smsModule, the answer for dispatchSMS, which in this case is true.

Before pushing the model from the Kevoree editor to the Kevoree runtime (i.e.: the node that will host the instances), we setup the properties of the components to initialize their knowledge bases and preference orders as described in table 7.1, and according to the CDL representation model that we present in Section 2.5. For instance, the sms component is initiated with a knowledge base containing one mapping rule (M1) that states that if (hcs : emergency) of hcs is true, then (sms : dispatchSMS) of the sms module will also be true. HCSPref.txt contains the preference order of hcs, according to which the information imported by the medical profile is preferred to that coming from the ARM, which is in turn preferred to that coming from the bracelet.

After pushing the model to the Kevoree runtime, a console appears allowing us to interact with the sms module. We initiate a query about (sms : dispatchSMS), and we get true as a response. In fact, what happens in the back-end is that a query servant starts on the sms module to solve the query. The query servant initiates, then, a new query for (hcs : emergency). In the knowledge base of hcs, there is one rule supporting this literal, and another one supporting its negation. hcs evaluates both rules and resolves the conflict using its preference order. Finally, it sends back the result of the query to the first query servant, which in turn computes and returns a positive truth value for (sms : dispatchSMS). The full interaction is displayed in figure7.7.

Figure 7.7: Execution of the running example.

7.5

Conclusion

We presented R-CoRe: a rule-based contextual reasoning framework for ambient intelligence and demonstrated its use ambient assisted living. Being based on contextual defeasible

7.5. Conclusion

logic, R-CoRe enables reasoning with imperfect context data in a distributed fashion. The capabilities of the underlying software platform, Kevoree, and its component-based models, enable R-CoRe to overcome several technical issues related to communication, information exchange and detection. R-CoRe, as currently presented in this chapter, has some technical limitations. As it deals with real components, we must assume limited memory, battery, computation and power resources. These limitations vary widely from a component to another depending on the nature of the components, and their technical complexity. For the current implementation, we have limited the knowledge base size to a maximum of 500 literals and rules. We have also limited the time-out for 10 seconds, so that if a component does not receive an answer to its query within 10 seconds, the corresponding thread server will send a time-out response, and the query will automatically expire. These limits define the maximum number of hops that a query can make before it expires, which in turn limits the communication resources, as some communication channels might not be free (over sms for example). With the current settings, we can easily implement small to medium scale AAL scenarios. However, dealing with more complex scenarios require including an optimization engine. To address such needs, the next chapters will discuss on solutions that offer trade-offs between computation time, memory and communication between devices. These optimizations techniques, when combined with [email protected], will allow the AmI platform to adapt itself depending on the available resources, especially for large scale applications.

In this chapter, we enabled agents to intercommunicate and exchange information in order to derive the context in a distributed way. With this information in hand, the next step is to investigate how to adapt AmI platforms according to the contextual information.

8

Polymer - A model-driven

approach for MOEA

This chapter is based on the work that has been published in the following paper:

• Assaad Moawad, Thomas Hartmann, François Fouquet, Grégory Nain, Jacques Klein, and Johann Bourcier. Polymer: A model-driven approach for simpler, safer, and evolutive multi-objective optimization development. In MODELSWARD 2015-3rd

International Conference on Model-Driven Engineering and Software Development,

pages 286–293. SCITEPRESS, 2015

Contents

8.1 Introduction . . . . 92 8.2 Real-World Case Study . . . . 93 8.3 Model-based MOO . . . . 94 8.3.1 Approach . . . 94 8.3.2 Polymer Implementation. . . 97 8.3.3 Partial Model Cloning . . . 99 8.4 Evaluation. . . . 99 8.4.1 Complexity to Implement . . . 99 8.4.2 Evolutive Refactoring Robustness. . . 100 8.4.3 Performance and Effectiveness . . . 101 8.5 Conclusion . . . . 102

8.1

Introduction

In many domains, such as finance, science, engineering, and logistics several conflicting objectives need to be simultaneously optimized. In finance for example, the anticipated value of a portfolio should be maximized, whereas the expected risk should be minimized. Such problems, involving conflicting objectives, are called multi-objective optimization (MOO)

problems, characterized by solutions offering trade-offs between different objectives.

Different algorithms can cope with such problems, e.g. particular swarm optimiza- tion [KE+_{95], simulated annealing [VLA87], and population based algorithms [DPAM02].}

Multi-objective evolutionary algorithms (MOEAs) are another class of algorithms, which has proved to be particularly capable of finding solutions for complex domain-specific opti- mization problems with large solution spaces for which typically no efficient deterministic algorithms exist. However, MOEAs are difficult to use, require specific and detailed expert knowledge about fitness functions, mutation operators, and genetic problem encodings. Common encodings consist in mapping a domain-specific MOO problem into a binary, permutation-based matrix, or graph-based representation [CVVL02]. The solutions found by MOEAs must then be decoded, meaning to map them back to the domain-specific multi-objective optimization problem. This makes it very challenging to properly apply MOEAs and may require developers to focus more on the encoding of a problem than on the problem itself [KCS06]. The continuous design process of today’s software systems makes it even more difficult to implement and especially to maintain MOEAs. Each change in the domain and/or in the optimization goals requires to adapt the problem encoding and decoding. Since the encoding is usually not statically typed, type checkers cannot be used to indicate potential errors. As a consequence it is hardly possible to use standard refactoring techniques to apply domain and/or optimization goal changes. Instead, the problem encoding must be adapted manually and independently from the domain represen- tation. Moreover, optimization problems are inevitably linked to the growing complexity of software. Fitness functions and mutation operators can use these models and their API instead of relying on complex and error prone encoding steps. Similar to paradigms like domain-driven design, our model-driven approach allows developers to focus on the actual domain-specific optimization problems rather than on technical encoding details.

In this chapter, we present a new MDE approach to develop MOO layers directly on top of models. This approach is generic and can be applied to any domain-specific model. In the next chapter, we will apply it for the AmI domain and show

how it contributes to the big picture of the thesis. Our approach also reduces the

gap between MOEA representations and models, allowing to reuse standard modeling tools (e.g. model checkers) within fitness functions or mutation operators. Integrated into an open-source framework, our approach can significantly simplify domain-specific MOO development. We evaluate our approach on a cloud case study and show its suitability in terms of i) complexity to implement a MOO problem, ii) complexity to adapt (maintain) this implementation caused by changes in the domain model and/or optimization goals, and iii) efficiency and effectiveness remains comparable to traditional implementations.