A Solver-Independent Platform for Modeling Constrained Objects Involving Discrete and Continuous Domains

Transcription

1 A Solver-Independent Platform for Modeling Constrained Objects Involving Discrete and Continuous Domains Ricardo Soto 1,2 and Laurent Granvilliers 1 1 LINA, CNRS, Université de Nantes, France 2 Escuela de Ingeniería Informática Pontificia Universidad Católica de Valparaíso, Chile {ricardo.soto,laurent.granvilliers}@univ-nantes.fr Abstract. The constrained object modeling paradigm allows to represent systems as hierarchies of objects under constraints. This paper focuses on the modeling of constrained objects involving discrete and continuous domains. To this end, a new solver-independent modeling language called COMMA will be introduced. The mapping process from this language into the RealPaver solver will be explained. 1 Introduction Complex structures as circuits, engines and molecules are in general entities composed by many pieces. These pieces have features and a number of rules or laws that define the structure assembly of the system. Modeling these structures is not quite natural using either a pure logic or a pure declarative constraint language. It seems more appropriate to adopt a compositional approach where the pieces of the system are represented by objects, the features of the pieces are represented by attributes and the rules are represented by constraints. This approach is the basis of the constrained object modeling paradigm. Although this approach seems to be a good candidate for modeling this class of problems, it has received little attention from the Constraint Programming (CP) community [6]. For instance, currently there is no modeling language available based on this paradigm. In this paper, we introduce the new modeling language COMMA [1], in order to extend previous work done under this paradigm [3, 10, 9, 7] by providing important features such as a richer constraint language (closer to OPL [13]), solver independence, extensibility, and the capability of modeling and solving constrained objects involving discrete and continuous domains. The first implementation of COMMA is written in Java (20000 lines) where models can be translated to three different solvers: ECLiPSe [14], Gecode/J [2], and RealPaver [8]. This paper is organized as follows: Section 2 gives a summary of the features of COMMA. Section 3 explains the mapping process from COMMA models to RealPaver models. Conclusions and future work are given in Section 4.

2 2 COMMA Features The main features of the language are described in this section, namely the core of the language, important characteristics from the user point of view, and the system architecture for parsing. Objects + Constraints COMMA is built from a combination of a constraint language with an object-oriented language. The object part is an abstraction of the Java programming style. Classes and objects can be defined using a simple notation. The constraint language provides classical constructs like basic data types, data structures, conditional statements, and iteration statements. Simplicity In COMMA we try to avoid the encoding concerns that make models complex and difficult to state and understand. For instance, there is no need for object constructors to state a class, direct variable assignment can be done into the class. Other details such as object visibility (protected, private, public) have been omitted. We believe that these details are suitable for programming (such as in Gecode [2] or ILOG SOLVER [11]), but not for modeling.. Hierarchy The hierarchical class diagram is a good basis for managing large scale constraint problems especially from applications fields such as operation research, engineering and design. Classes, data files, and extension files can be gathered to build components. Reuse Abstraction, constraint encapsulation, composition, and inheritance, are main features of the language supporting reuse of existing components. Extensibility The constraint language is extensible [12]. New functions and relations can be added to existent domains, extending the syntax of the constraint language. This capability makes the architecture adaptable to further upgrades of the solvers. Solver independent modeling Solver independence is considered as very important in modern modeling languages [5, 4]. This architecture gives the possibility to plug-in new solvers and to process the same model with different solvers, which is useful to learn which solver is the best for it. Compiler The compiling system is composed by three independent compilers. One for the COMMA language, one for the data and another for the extension files. The COMMA compiler is composed of one parser per constraint domain (Integer, Real, Boolean and Objects), one parser for constraints involving more than one domain (Mixed parser) and one base parser for the rest of the language (classes, import and control statements). This approach allows one to easy maintain the parsing engine, not to recompile the base language by hand. It requires specific rules to handle ambiguity and typing problems [12].

3 3 COMMA Overview Let us now show some of the main features of COMMA using an example involving discrete and continuous domains. Consider the task of installing two antennas whose coverage ranges are represented by circles. The position of antennas is supposed to be discrete. The coverage range of antennas is a variable with a bounded continuous domain. An intersection is required between circles to assure a minimum coverage range. This problem can be represented as a geometrical constraint system where the center of each circle corresponds to the correct antenna location (see Figure 1). y c1 (x 0, y 0) r x c2 Fig.1. Diagram of the antennas problem Figure 2 shows the COMMA model for this problem. Two classes are defined. Class antennas has two constrained objects circle and five constraints 3 enforced over the circle objects. The constraints c1.x = c2.x and c1.y = c2.y allow one to control the intersection between circles. The constraint c1.y0 = c2.y0 places the center of the circles in the same value of the y axis. An equal radius value for each circle is forced by c1.r = c2.r. The last constraint sets a distance of 1.5*radius between the x 0 points of the circles. For the second class called circle, x and y represent the points of the circle with center (x0,y0). The radius is determined by the attribute r and the equation of the circle is represented by the given constraint. All the attributes have been restricted to specific domains to assure the coverage range given by the intersection of the antennas. Constrained objects are translated to the solver source file by eliminating the hierarchy of the COMMA file. This process is done by expanding each constrained object declared (c1 and c2 in the example) adding its attributes and constraints in the flat file. The name of each attribute has a prefix corresponding to the 3 Due to extensibility requirements of the compiler, constraints must be typed. A detailed presentation of the compiler can be found in [1].

4 class antennas { class circle { circle c1; real x in [-3,3]; circle c2; real y in [-3,3]; constraint intersection { real r in [1.5, 2.5]; real c1.x = c2.x; int x0 in [0,5]; real c1.y = c2.y; int y0 in [0,5]; int c1.y0 = c2.y0; constraint radius { real c1.r = c2.r; real r^2 = (x-x0)^2 + (y-y0)^2; real c1.x *c1.r = c2.x0; } } } } Fig.2. A COMMA model for the antennas problem concatenation of the names of objects of origin in order to avoid name redundancy. The process is done recursively. Constraints derived from the expansion of objects are added in the same way 4 (see Figure 3). Variables real c1_x in [-3,3], real c1_y in [-3,3], real c1_r in [1.5,2.5], real c2_x in [-3,3], real c2_y in [-3,3], real c2_r in [1.5,2.5], Constraints c1_r = c2_r, c1_r^2 = (c1_x-c1_x0)^2 + (c1_y-c1_y0)^2, c2_r^2 = (c2_x-c2_x0)^2 + (c2_y-c2_y0)^2; Fig.3. Flat RealPaver file 4 Conclusion and Future Work We have shown by means of a practical example how COMMA is able to model systems using a compositional approach. This platform could be improved extending the list of supported solvers. The definition of a UML profile will be useful for modeling from a graphical perspective. Finally, we plan to make the COMMA system open source for the research community. 4 The translation process to ECLiPSe and Gecode/J can be found in [1].

5 References 1. COMMA Modeling Language. rsoto/comma. 2. Gecode System A.H. Borning. The Programming Languages Aspects of ThingLab, a Constraint- Oriented Simulation Laboratory. ACM TOPLAS, 3(4): , Alan M. Frisch et al. The design of essence: A constraint language for specifying combinatorial problems. In IJCAI, pages 80 87, R. Rafeh et al. From zinc to design model. In PADL, pages , F. Benhamou et al. Trends in Constraint Programming. ISTE, P. Fritzson and V. Engelson. Modelica A Unified Object-Oriented Language for System Modeling and Simulation. In ECOOP98, Brussels, L. Granvilliers and F. Benhamou. Realpaver: an interval solver using constraint satisfaction techniques. ACM Trans. Math. Softw., 32(1): , B. Jayaraman and P.Y. Tambay. Constrained Objects for Modeling Complex Structures. In OOPSLA, Minneapolis, USA, M. Paltrinieri. On the Design of Constraint Satisfaction Problems. In PPCP, Orcas Island, USA, J.F. Puget. A C++ implementation of CLP. In SCIS, Singapore, R. Soto and L. Granvilliers. Dynamic parser cooperation for extending a constrained object-based modeling language. To appear in Proceedings of WLP 2007, Wuerzburg, Germany. 13. P. Van Hentenryck. The OPL Optimization Programming Language. The MIT Press, M. Wallace, S. Novello, and J. Schimpf. Eclipse: A platform for constraint logic programming, 1997.