iOpt incorporates many libraries and frameworks such as a constraint library, a ..... visual components are directly connected to a schedule model using again ...
iOpt: A Software Toolkit for Heuristic Search Methods Christos Voudouris, Raphael Dorne, David Lesaint, Anne Liret BTexact Technologies, Intelligent Systems Lab, B62 Orion Building, pp MLB1/12, Martlesham Heath, Ipswich IP5 3RE, Suffolk, United Kingdom {chris.voudouris, raphael.dorne, david.lesaint, anne.liret}@bt.com
Abstract. Heuristic Search techniques are known for their efficiency and effectiveness in solving NP-Hard problems. However, there has been limited success so far in constructing a software toolkit which is dedicated to these methods and can fully support all the stages and aspects of researching and developing a system based on these techniques. Some of the reasons for that include the lack of problem modelling facilities and domain specific frameworks which specifically suit the operations of heuristic search, tedious code optimisations which are often required to achieve efficient implementations of these methods, and the large number of available algorithms - both local search and population-based - which make it difficult to implement and evaluate a range of techniques to find the most efficient one for the problem at hand. The iOpt Toolkit, presented in this article, attempts to address these issues by providing problem modelling facilities well-matched to heuristic search operations, a generic framework for developing scheduling applications, and a logically structured heuristic search framework allowing the synthesis and evaluation of a variety of algorithms. In addition to these, the toolkit incorporates interactive graphical components for the visualisation of problem and scheduling models, and also for monitoring the run-time behaviour and configuring the parameters of heuristic search algorithms.
1 Introduction The iOpt Toolkit research project at BTexact Technologies was motivated by the lack of appropriate tools to support the development of real-world applications, which are based on heuristic search methods. The goal, originally set, was to develop a set of software frameworks and libraries dedicated to heuristic search to address this problem. Following contemporary thinking in software engineering, iOpt allows code reuse and various extensions to reduce as much as possible the fresh source code required to be written for each new application. Furthermore, application development is additive in the sense that the toolkit is enhanced by each new application, reducing further the effort in developing similar applications to those already included. iOpt is fully written in the Java programming language with all the acknowledged benefits associated with that, including:
• • • •
easier deployment in different operating systems and environments, stricter object oriented programming, compatibility with 3-tier application servers based on J2EE, and also better integration with visualisation code in Web browsers and stand alone applications.
Up to recently, Java was considered too inefficient (e.g. compared to C++) for developing optimisation applications. This situation has significantly improved with the introduction of new compilation technologies such as Sun’s HotSpot and the ever improving performance of PCs. iOpt has taken advantage of these two developments using Java as a promising alternative to C++; at least from the software engineer’s point of view who is sometimes willing to sacrifice ultimate performance for ease of use and better integration. iOpt incorporates many libraries and frameworks such as a constraint library, a problem modelling framework, a generic framework for modelling scheduling applications, a heuristic search framework, as well as interactive visualisation facilities for constraint networks, scheduling applications, algorithm configuration and monitoring. In this paper, due to space limitations, we only provide a general description of the different parts of the toolkit while focusing on the software engineering aspects and design choices. For a more detailed technical description and computational results on the problem solving modules (i.e. constraint library and heuristic search framework) the reader may refer to [18] and also [3].
2 One-Way Constraints The iOpt Toolkit, to facilitate problem modelling, provides declarative programming capabilities within the Java programming language. The paradigm followed is similar to C++ libraries for constraint programming such as ILOG Solver [15], consisting of a number of built-in relations which are available to the user to state its problem. A constraint satisfaction algorithm is used to transparently maintain these relations. In contrast to constraint programming tools, relations available in iOpt are based exclusively on one-way dataflow constraints [19, 20]. A one-way dataflow constraint is an equation (also called) formula, in which the value of the variable in the left-hand side is determined by the value of the expression in the right-hand side. For example, a programmer could use the equation y = x + 10 to constrain the value of y to be always equal to the value of x plus 10. More formally, a one-way constraint is an equation of the form [19]: u = C(p0, p1, p2, …, pn)
(1)
where each pi is a variable that serves as a parameter to the function C. Arbitrary code can be associated with C that uses the values of the parameters to compute a
value. This value is assigned to variable u. If the value of any pi is changed during the program’s execution, u’s value is automatically recomputed (or incrementally updated in constant time). Note that u has no influence on any pi as far as this constraint is concerned; hence, it is called one-way. 2.1 Constraint Satisfaction Algorithms for One-Way Constraints The two most common constraint satisfaction schemes for one-way constraints are the mark/sweep strategy [7, 20] and the topological ordering strategy [6, 20]. A mark/sweep algorithm has two phases. In the mark phase, constraints that depend on changed variables are marked out-of-date. In the sweep phase, constraints whose values are requested are evaluated and the constraints are marked as up-to-date. If constraints are only evaluated when their values are requested, then the sweep phase is called a lazy evaluator. If all the out-of-date constraints are evaluated as soon as the mark phase is complete, then the sweep phase is called an eager evaluator. A topological ordering algorithm is one, which assigns numbers to constraints that indicate their position in topological order. Like the mark/sweep strategy, the topological ordering strategy has two phases. A numbering phase that brings the topological numbers up-to-date and a sweep phase that evaluates the constraints. The numbering phase is invoked whenever an edge in the constraint dataflow graph changes. The sweep phase can either be invoked as soon as a variable changes value or it can be delayed to allow several variables to be changed. The sweep phase uses a priority queue to keep track of the next constraint to evaluate. Initially all constraints that depend on a changed variable are added to the priority queue. The constraint solver removes the lowest numbered constraint from the queue and evaluates it. If the constraint’s value changes, all constraints that depend on the variable determined by this constraint are added to the priority queue. This process continues until the priority queue is exhausted. For the purposes of this project, we evaluated both topological ordering and mark/sweep algorithms. Although, theory suggests that topological algorithms should be faster at least for basic constraint types [19], our experience (with both approaches implemented in the Java language) showed that topological algorithms were slower something, which is in agreement with the findings in [19]. This is primarily because mark/sweep methods are simple and therefore subject to faster implementations compared to the queue-based topological ordering methods. When cycles and dynamic relations are added then mark/sweep algorithms also become theoretically faster [20]. One-way constraints have been used extensively by the GUI community in building interactive user interfaces [13, 14], and also in circuits [1] and spreadsheet programming [12]. Localizer, a scripting language for implementing local search algorithms also uses this approach for modelling combinatorial optimization problems [10, 11]. A specialized topological ordering algorithm is deployed there [10]. In Localizer, one-way functional constraints are called invariants. We will also use the same term to refer to one-way constraints when used in the context of Heuristic Search. This would help distinguish them from multi-way relational constraints as
they are traditionally defined and used in Constraint Programming and also from the problem’s constraints as they are given in its mathematical formulation. 2.2 Invariant Library The Invariant Library (IL) of iOpt, as the name suggests, is solely based on invariants (i.e. one-way constraints). IL provides a number of built-in data types such as Integer, Real, Boolean, String and Object and also set versions of these types (except for Boolean). Arithmetic, logical, string, object, set and other operators are available to the user to state its problem (i.e. decision variables, parameters, constraints and objective function). Being a library of Java, IL brings a number of advantages such as integration with visualisation components, ability for the user to extend the operators available by defining its own, facilities to work on language data structures such as Java Object and String (useful for producing on-the-fly constraint explanations) and also easier embedding into other Java programs. IL incorporates many optimisations such as incremental updates for aggregate types (e.g. sum, prod, min, max), lazy and eager evaluation modes, constraint priorities, cycle detection facilities, propagation stopping and the ability to work with undefined parts of the dataflow graph (e.g. when some of the decision variables are yet unassigned). In addition to these, it is more geared towards computationally demanding applications compared to other Java libraries and applications. This is achieved by avoiding some of the built-in but inefficient Java data structures and also by trying to avoid the constant creation and garbage collection of objects, something very common in a strict object oriented environment such as Java’s. Arbitrary dataflow graphs can be configured to model optimisation problems by mapping the decision variables representing a solution to the objective and constraints as they are given by the problem’s mathematical formulation. The reason for selecting invariants for supporting Heuristic Search, over relational constraints (as used in CP), is that invariants are particularly suited for heuristic search. Heuristic search techniques require an efficient way to access the impact of incremental solution changes to the problem’s constraints (i.e. constraint checks) and also the value of the objective function. Invariants are particularly adept at this task since they can incorporate specialized incremental update mechanisms for the different operators implemented, in addition to the general algorithms available for restricting the parts of the constraint graph that need to be updated after a change in the input variables (decision variables in this case). Small solution changes (often called moves) are the foundation of Heuristic Search (Local Search to be more precise). They are iteratively used to improve a starting solution for the problem. Devising an efficient move evaluation mechanism normally requires a person with significant expertise in the area. This hinders the widespread use of Heuristic Search. The invariant library addresses this problem by utilising the generic mark/sweep algorithm mentioned above which can achieve relatively efficient move evaluations in an automated way and that without any particular expertise or special programming skills required by the user. The library also supports dynamic changes such as the addition and deletion of variables and constraints always bringing the network of invariants in a consistent state after each modification.
3 Problem Modelling Framework A Problem Modelling Framework (PMF) is part of the toolkit. The role of the framework is to provide an ontology for combinatorial optimisation problems something which is not explicit in the invariant library which is general in its nature. PMF includes foundation classes for Problem and Solution and also for the various types of decision variables. In addition, it incorporates solution management facilities by keeping the best solution, current solution or a population of solutions, which can be used by local search or population-based techniques. It can also be instructed to detect constraint violations and stop the evaluation algorithm at an early stage. As with the invariant library, arbitrary dynamic changes to the objectives/constraints or decision variables are allowed with the problem model always ending up in a consistent state. In Figure 1, we provide an annotated code sample demonstrating the use of invariants in conjunction with the problem modelling framework to model a simple optimisation problem. We also include operations, which change the problem model. /* Create a simple problem model using Problem p = new Problem(); p.beginModelChanges(); RealVar x = new RealVar(10.0); p.addDecisionVar(x); p.addObjective(Inv.plus(x, 5.0)); p.addConstraint(Inv.gt(x, 5.0)); p.endModelChanges();
invariants */ // start changes to the problem model // create a real variable x and set its initial value to 10.0 // set x to be a decision variable // add the term x + 5.0 to the objective initially undefined // set the constraint x > 5.0 // end changes to the problem model
/* Change to the value of the decision variable */ /* Similar operations are performed when local search is evaluating a move or the user modifies the solution through a GUI */ p.beginValueChanges(); // start changes to the values of the decision variables x.setValue(100.0); // set x to the new value of 100.00 p.endValueChanges(); // end changes to the values of the decision variables p.propagateValueChanges(); // the mark/sweep algorithm is updating the invariants p.saveValueChanges(); // we commit the changes, we may undo them instead // in case of constraint violations or inferior cost /* Dynamic addition of decision variable/objective to the problem model */ RealVar y = new RealVar(15.0); p.addDecisionVar(y); p.addObjective(Inv.plus(y, 10.0)); // the overall objective is now (x + 5.0) + (y + 10.0) p.endModelChanges();
Fig. 1. Sample source code demonstrating the use of invariants and PMF.
The above example is a very simple one and only for illustration purposes. In fact, the problem modelling framework usually serves as the basis for domain specific frameworks such as the Scheduling Framework explained next. It has also been extended to model specific problems such as the Graph Colouring, Car Sequencing, Set Partitioning, Frequency Assignment as well as a real-world BT application related to field resource planning.
4 Scheduling Framework Scheduling problems can be found in diverse sections of the economy (e.g. Manufacturing, Transportation/Logistics, Utilities). To assist non-expert users to develop applications in these areas, we developed a framework of Java classes for specifically modelling scheduling problems with unary resources. These classes hide the complexity of invariant-based decision models from the user, who instead focuses on describing his/her problem using domain-specific entities (e.g. Activity, Resource, Break, etc.). There is a class hierarchy included for activities to capture the different types found in applications. Depending on the type of the activity, the user can state resource and/or time constraints (e.g. task A before/after task B, multiple time windows, “same”/”different” resource constraints and others). For modelling the resources, the framework includes different types of timelines such as state, capacity and capability timelines. The interactions of activities with these timelines capture all the necessary constraints related to the execution of activities on resources. The scheduling framework also supports user-defined models for resource setup(travel)/service times. These are sub-models, which can be implemented by external systems such as GIS (in the case of travel times), to offer realistic duration estimates for activities and also for resource transitions between activities. One or more of several built-in objectives can be selected and used. These are listed below: • • • • • •
unallocated costs for activities, resource usage costs, time window/lateness penalties, overtime costs, setup and service duration costs and also resource-activity compatibility preferences.
The scheduling framework internally uses the problem modelling framework mentioned in section 3. This makes it possible to extend it to capture the different variations of scheduling problems in terms of additional decision variables, constraints or costs. In contrast to CP-based scheduling libraries, the framework solely uses invariants for both constraint checking and also for the computation of the objective function. The move operators relocate and swap are readily available so that heuristic search methods or interactive graphical components such as a Gantt Chart can operate on the schedule. Using the Scheduling Framework, we have experimented building models for wellknown problems such as the Vehicle Routing Problem, Job Shop Scheduling Problem and also a Workforce Scheduling Problem. As with PMF and the invariant library, dynamic changes are allowed such as adding/removing activities/resources, resource/temporal constraints and also time
windows. These operations internally use the facilities of PMF and of the invariant library to implement changes in a consistent and transparent manner.
5 Heuristic Search Framework The Heuristic Search Framework (HSF) was created to be a generic framework for the family of optimisation techniques known as Heuristic Search. It covers single solution methods such as Local Search, population-based methods such as Genetic Algorithms as well as hybrids combining one or more different algorithms. Heuristic Search methods are known to be efficient on a large range of optimisation problems but they remain difficult to design, tune, and compare. Furthermore, they tend to be problem specific often-requiring re-implementation to address a new problem. HSF proposes a new way to design a Heuristic Search method whereby the functionality of common HS algorithms is broken down into components (i.e. parts) for which component categories are defined. Component categories are represented by Java interfaces while specific components are defined as Java classes implementing these interfaces. The designer has the capability to build a complete and complex algorithm by assembling these components which are either build-in or user extensions to the framework. In particular, three main concepts are the basis of HSF: Search Component, Heuristic Solution and Heuristic Problem. • Search Component as explained above is the basic entity that is used to build an optimisation method. Most often a Search Component represents a basic concept that could be encountered in an HS method. For example, the concept of Neighbourhood in a Local Search. A complete algorithm is a valid tree of search components1. • Heuristic Solution is the solution representation of an optimisation problem manipulated inside HSF. At the present moment, a Vector of Variables and a Set of Sequences are readily available. These representations are commonly used in modelling combinatorial optimisation problems. For example a vector of variables can model CSPs while a set of sequences can model various scheduling applications with unary resources. • Heuristic Problem is only an interface between an optimisation problem model implemented by IL (or my other means2) and HSF. This interface allows using the same algorithm for a family of optimisation problems without re-implementing any separate functionality. The following theoretical problems and real applications are already implemented using the Invariant Library (and also higher-level frameworks such as the Problem Modelling Framework and the Scheduling Framework) and used by HSF using that concept: Graph Colouring, Set Partitioning, Frequency Assignment, Job Shop Scheduling, Workforce Scheduling, Vehicle Routing, Car Sequencing, and Field Resource Planning. 1 2
A valid tree is a tree of search components that can be executed. HSF is generic like the Invariant Library and it can be used independently from it. For example, it can be used in conjunction with a hard-coded procedural problem model.
In the current version of HSF, the Search Component categories group many basic concepts encountered in Single Solution Heuristic Search such as Initial Solution Generation, Local Search, Move, Neighbourhood, Neighbourhood Search, Aspiration Criterion, Taboo mechanism, Dynamic Objective Function and others, and in Population-based Heuristic Search such as Initial Population Generation, Crossover, Mutation, Selection, Mutation Population Method, Crossover Population Method, Selection Population Method, Restart Population Method, and others. Furthermore, many popular meta-heuristics such as Simulated Annealing (SA), Tabu Search (TS), and Guided Local Search (GLS) are implemented. Methods such as Tabu Search and Guided Local Search can become observers of other search components such as Neighbourhood Search and receive notifications for certain events, which require them to intervene (e.g. move performed, local minimum reached, population converged and others). Invariants are often used to model parts of these methods such as the acceptance criterion in SA, tabu restrictions in TS or features and their penalties in GLS. Using the available set of search components and the other facilities explained briefly above, even the most complex hybrid methods can be modelled as the next example shows where a population-based method for Graph Colouring is composed using a local search method as the mutation, IUS crossover specialised to the Graph Colouring, Selection, and various other search components (see Figure 2).
Fig. 2. Hybrid Algorithm for Graph Colouring using Local Search as a mutation.
As it becomes obvious, designing a heuristic search is simplified to a great extend through assembling a set of components even for a sophisticated method such as the hybrid algorithm in Figure 2. The framework further allows the possibility to specialise an algorithm to an optimisation problem as we did above by adding a Graph
Colouring specific crossover IUS. Thus for the development of a problem-specific algorithm, we have only to implement the specialised problem-specific components not included in HSF. These can be incorporated in the framework and possibly reused in similar applications. Another benefit is that we can conduct easily and fairly comparisons between different algorithms or between different components of the same category (e.g. various Neighbourhood Search methods, currently fifteen of them incorporated in HSF). Since any new component can be directly plugged into the algorithmic tree replacing an old one, we can quickly determine the real benefit of different components to the search process. This is particularly useful when we are trying to determine what is the best variant of a method based on a particular philosophy (e.g. Tabu Search, Genetic Algorithms). An additional functionality included in HSF is that any heuristic search algorithm composed by the user can be saved in XML (a commonly-used Internet format for exchanging information). An efficient algorithm is never lost, instead can be kept in a simple text file. A build-in software generator can recreate the method at a later time from its XML specification. Since problem models are declarative and implemented by the Invariant Library, performing moves (in Local Search) or evaluating new solutions (in Population Methods) is transparent to the user. The user can then focus on the more important task of choosing and tuning the right algorithm instead of getting involved in lowlevel tasks such as trying to devise hard-coded efficient move evaluation mechanisms or implementing problem-specific methods to compute a complex fitness function.
6 Interactive Visualisation For optimisation systems to unlock their potential, they require not only sound algorithmic frameworks but also intuitive visualisation facilities to enable the user to participate in the problem solving process. For addressing this issue, the toolkit incorporates visualisation components (and also add-ons to third-party visualisation components), which can be connected to the various algorithmic/modelling frameworks, included in the toolkit. This facilitates the development of interactive optimisation systems, which allow what-if scenario testing along with intelligent manual interventions. In particular, three areas of visualisation are addressed. 6.1 Invariant Visualisation Software components have been developed to visualise invariant networks. The Model-View-Controller (MVC) approach is followed and the visual components use the Observer-Observable pattern (supported by the Invariant Library) to connect to the constraint network. The user may modify the values of variables or read the value of invariants in a table format or use a graph view to visualise the structure of the invariant network. This is particularly useful in the early stages of development for debugging parts of the problem model and also understanding the mechanism of
invariant evaluation. Figure 3 provides an example of a simple invariant network as visualised by the system.
Fig. 3. Invariant visualisation example.
6.2 Schedule Visualisation Similarly to invariant visualisation, a number of interactive components have been developed to visualise the entities in a schedule model amongst them a schedule tree representation, a Gantt Chart, a Capacity Chart, and a Map Viewer, along with several table views for the schedule entities (e.g. Resources, Activities, Breaks, etc.). The visual components are directly connected to a schedule model using again the MVC architecture and the Observer/Observable pattern. The user may drag and drop activities or change parameters and immediately see the impact they have on the problem’s constraints and objectives as the underlying invariant network propagates changes and updates only the affected parts of the visual display. Essentially, this approach implements an interesting form of interactive constraint satisfaction/optimisation, engaging the user in the problem solving process. It has also been useful to demonstrate to non-optimisation people the complexity of scheduling problems so that they appreciate more the usefulness of Heuristic Search methods. The visual components because they are Java-based can be incorporated inside a Web browser interface significantly reducing lead times otherwise needed to connect
to the constraint engine on the server in order to assess the impact of changes to the solution. Figure 4 shows a screen shot from a fully assembled system utilising the different components.
Fig. 4. Schedule visualisation example.
6.3 Algorithm Visualisation To visualise heuristic search algorithms, a special Java software package has been implemented with the focus being on allowing the user to understand and control the structure and behaviour of the methods. The facilities provided in the library include the visualisation of the tree of search components comprising an algorithm alongside with information on the parameters used by these search components. The user can walk through the tree of search components for any heuristic search method built using the toolkit. As shown in Figure 5, the UI is divided into two panels. On the left, the tree of search components for the method selected is available and on the right appears a panel with all parameters of the currently selected component that can be adjusted by the user. Changes to these parameters can be done before commencing the search process or during the search process.
Fig. 5. Component visualisation and settings for a Simulated Annealing method.
This latter facility allows the user to have interactive control over the algorithm. For example, if a tabu search method is trapped in a local optimum then we may want to increase (even temporarily) the size of the tabu tenure to allow the search to escape from it. As it can be seen in Figure 5, on the right panel there is a “Watch” button. When pressed, this button activates a monitoring facility for the particular search component. Watching a search component means displaying its different major variables. For example, watching a Simulated Annealing search component will display the objective value of the current/best solution, its current temperature, acceptance probability etc. (see Figure 6). This last facility allows the possibility to visualise the workings of the whole algorithm as well as of separate search components during a search process and then exploit this information to make further changes to their parameters.
Fig. 6. Watching a Simulated Annealing search component.
This can be seen as a form of heuristic search behaviour “trouble-shooter”. After having designed a heuristic search method using the HSF framework, the user can get a better understanding of the method by watching, setting or dynamically modifying
critical parameters. This could be used to make a better design resulting into a bettertuned and more efficient system.
8 Related Work and Discussion In terms of the Invariant Library, the system uses algorithms initially explored in the areas of Computer Graphics [19, 20]. Related work on using one-way constraints for heuristic optimisation is the Localizer language described in [10, 11] also mentioned earlier in this paper. Differences between the IL and Localizer include the algorithms used for propagation (mark/sweep and topological-ordering respectively), the ability to model dynamic problems in IL, but most importantly the fact that Localizer is a language on its own, whereas IL uses the Java programming language by providing a declarative environment within it. In the area of Scheduling, different frameworks have been developed such as DITOPS/OZONE[17], ASPEN[5], ILOG Schedule[9], with varying degrees of modelling capabilities. iOpt’s scheduling framework is solely based on invariants, which is unique among the published work in the above mentioned systems since most of them use relational constraints or a combination of functional and relational constraints as in the case of ASPEN. Secondly, the model provided is suited for the variety of Heuristic Search methods included in HSF with the addition of dynamic problem modelling capabilities. Systems such as ILOG Schedule are primarily based on exact search methods while DITOPS/OZONE and ASPEN support only a limited set of customised heuristic methods that have been built specifically for these libraries. In the case of the HSF, most of the frameworks proposed in the literature are either Local Search based or Genetic Algorithm based. In the case of Local Search examples of frameworks include HotFrame [4], Templar [8], LOCAL++ [16], SCOOP (http://www.oslo.sintef.no/SCOOP/), and also the work of Andreatta et al. [2]. These tend to provide templates with the user having to define the problem model rather than use a constraint-based problem modelling paradigm. The same applies for move operators. CP toolkits such as Eclipse and ILOG Solver in their latest versions also have integrated certain basic Heuristic Search methods such as Tabu Search and Simulated Annealing. Finally, almost all of the related works mentioned in this section, are either C/C++-based or rely on specialized scripting languages.
9 Conclusions The iOpt toolkit presented in this article represents a research effort to integrate a number of technologies to offer a complete set of tools for developing optimisation applications based on Heuristic Search. At its present stage of development, it plays the role of a prototype platform for experimenting with the integration of a number of technologies such as constraint satisfaction, domain-specific frameworks, heuristic
search and interactive visualisation whilst utilising the capabilities of the much promising Java language in doing so. In this article, we examined parts comprising the toolkit and in particular: • a lightweight constraint library for modelling combinatorial optimisation problems, • a problem modelling framework providing an ontology for combinatorial optimisation problems, • a scheduling framework which can be customized to model applications in areas such as manufacturing, transportation, workforce management, • a heuristic search framework for synthesising local search and population based algorithms and • various visualisation components which integrate with the above algorithmic modules. We described how these can work in synergy allowing a developer to focus on the high level task of algorithm design, automating in an efficient way large parts of his/her work in developing a real-world optimisation system. Current research is focused on incorporating as part of iOpt a relational constraint library and an exact search framework developed in-house. Relational constraints and invariants and also exact and heuristic search methods can work collaboratively in many different ways and at present we are trying to identify the most promising ones. This is analogous to the link between MP and CP. Hopefully, a successful link of HS with CP in iOpt can lead to an environment which not only supports CP and HS but also guides the user how to exploit the best combinations of these techniques. On the industrialisation front, iOpt is presently being validated on internal BT applications and an enterprise system based on the toolkit will be deployed later in the year. First results are promising both in terms of reducing development times and also with regard to use of the system by non-expert software developers. Experience gained from in-house development is utilised to rationalise the system and also improve its robustness and performance.
References 1. Alpern, B., Hoover, R., Rosen, B.K., Sweeney, P. F., and Zadeck, F.K., Incremental evaluation of computational circuits. In ACM SIGACT-SIAM’89 Conference on Discrete Algorithms, pp. 32–42, 1990. 2. Andreatta, A., Carvalho, S., and Ribeiro, C., An Object-Oriented Framework for Local Search Heuristics, 26th Conference on Technology of Object-Oriented Languages and Systems (TOOLS USA'98), IEEE Press, 33-45, 1998. 3. Dorne, R, and Voudouris, C., HSF: A generic framework to easily design Meta-Heuristic methods, 4th Metaheuristics International Conference (MIC’ 2001), Porto, Portugal, 423428, 2001. 4. Fink, A., Voß, S., Woodruff, D., Building Reusable Software Components for Heuristic Search, In: P. Kall, H.-J. Lüthi (Eds.), Operations Research Proceedings 1998, Springer, Berlin, 210-219, 1999.
5. Fukunaga, A., Rabideau, G., Chien, S., and Yan, D., Toward an Application Framework for Automated Planning and Scheduling, Proceedings of the 1997 International Symposium on Artificial Intelligence, Robotics and Automation for Space, Tokyo, Japan, July 1997. 6. Hoover, R., Incremental Graph Evaluation. PhD thesis, Department of Computer Science, Cornell University, Ithaca, NY, 1987. 7. Hudson, S., Incremental Attribute Evaluation: A Flexible Algorithm for Lazy Update, ACM Transactions on Programming Languages and Systems, Vol.13, No. 3, pp. 315-341, July 1991. 8. Jones, M., McKeown, G, Raywar-Smith, V., Templar: An Object Oriented Framework for Distributed Combinatorial Optimization, UNICOM Seminar on Modern Heuristics for Decision Support, London, 7 December, 1998. 9. Le Pape, C., Implementation of Resource Constraints in ILOG SCHEDULE: A Library for the Development of Constraint-Based Scheduling Systems, Intelligent Systems Engineering, 3(2):55-66, 1994. 10. Michel, L. and Van Hentenryck, P., Localizer, Tech Report CS-98-02, Brown University, March 1998. 11. Michel, L. and Van Hentenryck, P., Localizer: A Modeling Language for Local Search, INFORMS Journal of Computing 11(1): 1-14, 1999. 12. Microsoft Corporation, Microsoft Excel. 13. Myers B.A., McDaniel, R.G., Miller, R.C., Ferrency, A., Faulring, A., Kyle, B.D., Mickish, A., Klimovitski, A., and Doane, P., The Amulet Environment: New Models for Effective User Interface Software Development, IEEE Transactions on Software Engineering, Vol. 23, No. 6, pp. 347-365, 1997. 14. Myers, B.A., Giuse D., Dannenberg, R.B., Zanden, B.V., Kosbie, D.S., Pervin E., Mickish, A., and Marchal, P., Garnet: Comprehensive Support for Graphical, Highly-Interactive User Interfaces, IEEE Computer, Vol. 23, No. 11., pp. 71-85, 1990. 15. Puget, J-F., Applications of constraint programming, in Montanari, U. & Rossi, F. (ed.), Proceedings, Principles and Practice of Constraint Programming (CP'95), Lecture Notes in Computer Science, Springer Verlag, Berlin, Heidelberg & New York, 647-650,1995. 16. Schaerf, A., Lenzerini, M., Cadoli, M, LOCAL++: a C++ framework for local search algorithms, Proc. of TOOLS Europe '99: Technology of Object Oriented Languages and Systems. 29th Int. Conf. 7-10 June, IEEE Comput. Soc, pp. 152-61, 1999. 17. Smith, S.F., and Becker, M., An Ontology for Constructing Scheduling Systems, Working Notes of 1997 AAAI Symposium on Ontological Engineering, Stanford, CA, March, 1997 (AAAI Press). 18. Voudouris, C., and Dorne, R., Heuristic search and one-way constraints for combinatorial optimisation, Proceedings of CP-AI-OR’01, Wye College (Imperial College), Asford, Kent UK, pp. 257 – 269, April 2001. 19. Zanden, B.V., Halterman, R., Myers, B.A., McDaniel, R., Miller, R., Szekely, P., Giuse, D., and Kosbie, D., Lessons Learned About One-Way, Dataflow Constraints in the Garnet and Amulet Graphical Toolkits, manuscript in preperation, 1999. 20. Zanden, B.V., Myers, B.A., Giuse, D. and Szekely, P., Integrating Pointer Variables into One-Way Constraint Models, ACM Transactions on Computer-Human Interaction. Vol. 1, No. 2, pp. 161-213, June, 1994.
