The DITOPS approach to knowledge-based planner and scheduler design (and construction) relies heavily on object-oriented programming techniques and software reuse, allowing schedulers and other planning applications to be constructed as a ``differential'' process, focusing primarily on the differences between existing software and the system being constructed. Object-oriented programming techniques can provide high reusability of software, but only if system design places special emphasis on the design of reusable components [][for example]Wirfs-Brock. In DITOPS, the design of these components has been carried out with generality and extensibility in mind.
Any scheduler construction project (potentially as part of a larger system design) begins with:
In an object-oriented approach to software construction, these steps constitute an object-oriented analysis of the scheduling system (they also constitute part of the design). The approach taken in the DITOPS reconfigurable framework is the introduction of a common scheduling and planning ontology which serves as the starting point for a more detailed analysis of the target system. By ontology we mean more than just a dictionary of terms: the system offers the scheduling system designer a class library of common and general scheduling concepts, such as activities, resources and demands. The ontology/library encodes a broad range of constraints which are applicable in different domains. Constructing a scheduler (or some other planning application) using the DITOPS approach thus consists of the following:
The basic class library provides a general scheduling ontology. This ontology can be specialized for specific domains (for example, we have built a transportation-domain ontology for rapid configuration of various planning systems for transportation-related problems). The general and domain-specific ontologies can then be used to build organization-specific ontologies and actual planning applications. It should be noted that in addition to providing a collection of domain modeling concepts, the class library has a set of classes for building problem solvers and scheduling algorithms. This allows scheduling procedures and associated heuristics to be constructed the same way domain models are constructed.
DITOPS uses a constraint-based model of scheduling, well-suited to the reactive decision-making requirements of practical scheduling domains. In broadest generality, this model defines a problem solving organization that distinguishes two components: a decision-making component, responsible for making choices among alternative scheduling decisions and retracting those that have since proved undesirable, and a constraint management component, whose role is to propagate the consequences of decisions and incrementally maintain a representation of the current set of feasible solutions (detecting inconsistent solution states when they arise). Schedule construction, revision, and improvement proceed iteratively within a basic decide and commit cycle.
The general philosophy of application construction is to use the library components to build increasingly complex (and specialized) services, ultimately resulting in an application. The configurable framework establishes a full hierarchy of protocols implementing the aforementioned model of constraint-based scheduling; it also provides a starting point for a scheduling application builder, who will replace abstract classes of the framework with more specialized classes that suit the problem at hand. This approach is analogous to modern application development frameworks which provide the basic functionality of a complex user-interface in the form of an application ``skeleton'' (e.g., [2]). In the case of DITOPS, the ``skeleton'' is an empty, generic constraint-based scheduling system. Solutions and classes defined in the framework will probably suit the majority of application needs. However, there is always the possibility to replace any component of the system with a different or more specialized component. This flexibility is directly attributable to the abstract layering of object interaction protocols provided by the framework.