University Timetabling through Conceptual Modeling

University Timetabling through Conceptual Modeling

Jonathan Lee,^1,* Shang-Pin Ma,^1,†Lien Fu Lai,^2,‡Nien Lin Hsueh,^3,§

Yong-Yi Fanjiang^4,¶

1Department of Computer Science and Information Engineering, National Central University, Chungli 320, Taiwan

2Department of Computer Science and Information Engineering, National Changhua University of Education, Changhua 500, Taiwan

3Department of Information Engineering and Computer Science, Feng Chia University, Taichung 400, Taiwan

4Department of Computer and Information Science, National Taichung University, Taichung 403, Taiwan

A number of approaches have been proposed in tackling the timetabling problem, such as oper- ational research, human-machine interaction, constraint programming, expert systems, and neu- ral networks. However, there are still several key challenges to be addressed: easily reformulated to support changes, a generalized framework to handle various timetabling problems, and abil- ity to incorporate knowledge in the timetabling system. In this article, we propose an automatic software engineering approach, called task-based conceptual graphs, to addressing the chal- lenges in the timetabling problem. Task-based conceptual graphs provide the automation of soft- ware development processes including specification, verification, and automatic programming.

Maintenance can be directly performed on the specifications rather than on the source code;

moreover, hard and soft constraints can be easily inserted or removed. A university timetabling system in the Department of Computer Science and Information Engineering at National Cen- tral University is used as an illustrative example for the proposed approach. © 2005 Wiley Periodicals, Inc.

1. INTRODUCTION

Timetabling is a major administrative activity for a wide variety of institu- tions. Timetabling can be defined as a process of assigning events or activities to resources such as time ~timeslots!, space ~rooms!, and personnel ~teachers or crews!,

*Author to whom all correspondence should be addressed: e-mail: yjlee@selab.csie.

ncu.edu.tw.

†e-mail: albert@selab.csie.nce.edu.tw.

‡e-mail: lflai@cc.ncue.edu.tw.

§e-mail: nlhsueh@fcu.edu.tw.

¶e-mail: yyfanj@selab.csie.ncu.edu.tw.

INTERNATIONAL JOURNAL OF INTELLIGENT SYSTEMS, VOL. 20, 1137–1160 ~2005!

© 2005 Wiley Periodicals, Inc. Published online in Wiley InterScience

~www.interscience.wiley.com!.

•

which satisfy all constraints. Over the last 30 years, many approaches and models have been proposed for dealing with a variety of timetabling programs. Most of these works employed operational research,^1–7human-machine interaction,^8,9con- straint programming,^{10 –14} expert systems,^15–19 or neural networks^{20 –22} to solve the timetabling problem. However, there are still several key challenges to be addressed:

•

•

•

•

In this article, we propose an automatic software engineering approach, called task-based conceptual graphs ~TBCG!, to addressing these challenges. TBCGs pro- vide the automation of software development processes including specification, verification, and automatic programming. First, we use TBCGs to capture and rep- resent a conceptual model for the problem domain. Second, contextual retrieval mechanism²³proposes a multiple-viewed approach for helping acquire specifica- tions and elicit information in contexts. Third, the verification of TBCGs²⁴is per- formed on model specifications and process specifications of each task. Finally, we operationalize TBCGs for the execution of task-based specifications. Once TBCGs have been constructed and verified, a blackboard system will automati- cally transform TBCG specifications into an executable university timetabling pro- gram. Major constituents of a software system such as database schemas, the knowledge base, and user interfaces can also be generated by transforming TBCGs into their corresponding counterparts.

We have applied the TBCG approach in timetable planning for the Depart- ment of Computer Science and Information Engineering at National Central Uni- versity ~NCU! in Taiwan. We have also adopted some observations made in Ref. 16 about the timetabling problem to further confine our scope on the problem: First, it assumes that students are already assigned or will select classes for themselves.

Second, constraints can be further classified as hard or soft. Finally, the aim of timetabling algorithms is to find a feasible solution that satisfies all hard con- straints, and as many soft constraints as possible, rather than to optimize on some chosen objective functions.

The expressive power of TBCGs makes it easier to model the timetabling problem. As a first-order logic vehicle, TBCG is powerful in describing domain knowledge, static facts, constraints, and relationships in the real world. Moreover, TBCG proposes a constraint satisfaction and relaxation mechanism to spot a fea- sible solution that satisfies all hard constraints and as many soft constraints as possible. With its graphic and formal representation, TBCGs can serve as a readable

and executable specification language. Small logical changes may have large and complex effects while performing maintenance at the implementation level;

whereas maintenance at the specification level is fairly simple and explainable. As TBCG specifications can be transformed into executable programs automatically, maintenance can then be directly performed on the specifications rather than on the source code. TBCG hence offers a certain degree of flexibility to support changes.

In the Section 2, we discuss related work. Section 3 gives a problem state- ment for the timetabling problem we are dealing with. In Section 4, we give an overview on how to express task-based specifications in conceptual graphs, and how to model the university timetabling by using TBCG. We also discuss issues identified and the proposed approach to operationalize TBCGs and the transfor- mation between TBCG and CLIPS. Section 5 outlines how the system is built.

Finally, we summarize the proposed approach in Section 6.

2. RELATED WORK

A wide variety of approaches to the timetabling problem have been proposed.

These works can be classified into three categories based on the underlying tech- nologies adopted: operational research ~OR!, human-machine interaction, and arti- ficial intelligence ~AI!.

2.1. Operations Research

Over the last 30 years, many OR techniques ranging from the use of math- ematical programming to heuristics are adopted to solve the timetabling problem.

These studies can be roughly divided into three types: sequential methods, cluster methods, and meta-heuristic methods.

Sequential methods order activities based on how difficult it is to schedule them and then assign the activities into valid resources in sequence. Graph coloring^{1,4, 25–28}is the most common sequential methods to solve the timetabling problem. de Werra^{1, 25, 26}shows how to reduce a course timetabling problem into the graph coloring problem. By applying graph coloring technology, the problem can be formulated as a network of arcs and nodes, and the solution can be obtained by finding a set of colors in which no two adjacent nodes or edges have the same color. While these techniques adapt well to small-scale problems, they fail to scale up for large ones and cannot be easily reformulated or customized to support change.¹⁶

Cluster methods split activities into groups based on whether it satisfies hard constraints and then assign the groups into resources to fulfill the soft constraints.

Tripathy^{7, 29}employs a Lagrangian Relaxation technique to solve the timetabling problem. In his approach, the number of variables is reduced by grouping, the number of constraints is reduced by replacing some of relaxed constraints, and feasible solutions are obtained by heuristics. Ferland and Roy²formulates the time- tabling problem as an assignment problem and solves it through a reduction to a quadratic assignment problem. The main drawback of these approaches is that the

clusters of events are formed and fixed at the beginning of the algorithm and that may result in a poor quality timetable.³⁰

Meta-heuristic methods begin with some initial solutions and use search strat- egies that try to avoid local optima. The memetic algorithm⁵improves the perfor- mance of a genetic algorithm by incorporating a local neighborhood search, which explores the neighborhood of the solutions obtained by a genetic algorithm and navigates the search toward the local optima for each solution. Hertz^3,31uses the tabu search technique to solve the university course timetabling problems. Refer- ence 31 considers the optimization problem with the grouping option, whereas Ref. 3 extends the approach to a more complex case that takes into account lec- tures of different length. Schaerf⁶proposed an algorithm based on a local search, which is constituted by tabu search and randomized hill-climbing. These methods can produce high-quality solutions but often have a considerable computational cost.³⁰

2.2. Human-Machine Interaction

The human-machine interaction approach is an iterative process. The machine first proposes an initial solution. Subsequently, the user either accepts it, improves upon it manually, or instructs the machine to provide another solution. The pro- cess iterates until the user is satisfied, or no further process is possible.

Mulvey⁹proposes a model of approximation, evaluation, and modification to deal with the timetabling problem. First, the user requires an approximate model of the ill-defined problem. Second, this model has to be evaluated by an estimator as to whether it provides a good starting solution, and how flexible it is in aiding the user to improve upon the solution. Finally, the user or machine goes through the modification process.

Johnson⁸uses a database management system for the bookkeeping aspects of timetable development. The system alleviates clerical burden associated with the production of timetables. In addition, the provision of accurate information aids the decision making to management on teaching commitments for resource allo- cation purposes. The major drawback of such systems is that for large problems, the process can be laborious, and obtaining a good initial solution may be compu- tationally expensive.¹⁶

2.3. Artificial Intelligence

In recent years, a number of AI technologies, including constraint program- ming, expert systems, and neural networks, are used for solving the timetabling problems.

Constraint programming approaches formulate the timetabling problem as a constraint satisfaction model and then propagate constraints to obtain a feasible solution. Monfroglio¹³ proposes a Prolog-based system that employs back- tracking for finding feasible timetables. The system decomposes and classifies constraints with respect to message passing and the constraint ordering to mini- mize the backtracking and maximize the parallelism. Deris et al.¹¹ propose a

constraint-based reasoning algorithm to model and solve the timetabling problem.

The proposed system is implemented in an object-oriented approach and can thus be easily adapted to support changes. In Ref. 14, OR models and local search techniques are also used to assist the constraint programming search process by effectively reducing the solution search space. They propose a minimum cost matching algorithm to relax the constraint satisfaction model. Constraint logic pro- gramming^10,12integrates logic programming and constraint solving to tackle com- binatorial problems such as planning, scheduling, and resource allocation. This combination helps make constraint logic programs expressive and flexible.

Expert systems capture human expertise and use it in the solution process.

Since the model employed more closely resembles the real world situation, its solutions could also better fit the context. Gunadhi and his colleague¹⁶ introduce an automated timetabler that combines data model and knowledge base, devel- oped using object-oriented methodology. The separation of data, knowledge, and algorithms provide flexibility to deal with changes, and the incorporation of human expertise helps in reducing the search space for a feasible solution. Solotorevsky et al.¹⁹develop a rule-based language, called RAPS, for specifying resource allo- cation problems and timetabling problem. The language enables the specification of a problem in terms of resources, activities, allocation rules, and constraints, and thus provides a convenient knowledge acquisition tool. Dhar and Ranganathan¹⁵ propose the use of an expert system, called PROTEUS, for the allocation of teach- ers to courses, and compare it to integer programming techniques. For predictive scheduling of passenger trains, Isaai and Cassaigne¹⁷and Isaai and Singh¹⁸intro- duce a lookahead, constraint-based algorithm that is designed using an object- oriented approach. In their approach, expert knowledge is used as heuristics for finding practical solutions and combined with the constraint-propagation technique.

Hopfield and Tank²⁰ first applied the parallel characteristics of neural net- works to solve the optimization problems. The initial results of the Hopfield neu- ral networks are infeasible. Several researchers have modified the approach in an attempt to overcome the limitations of Hopfield neural networks, but the field has never truly recovered from its controversial beginnings. Pellerin and Herault²¹use neural networks to prevent conflicting assignments as part of a manual scheduling procedure. Smith et al.²² propose a discrete Hopfield neural networks that maps the timetabling problem onto a neural network and obtains better and faster results.

The extensive computational effort required, however, makes neural networks less impressive.³²

3. PROBLEM STATEMENTS OF THE UNIVERSITY TIMETABLING The timetabling problem is to fix a sequence of meetings between teachers and students in a prefixed periods of time ~typically a week!, satisfying a set of constraints of various types. Schaerf³³classifies the timetabling problems into three main classes: school timetabling, course timetabling, and examination time- tabling. The focus of this article is on solving the course timetabling. In general, the university course timetabling problem is to schedule a set of sessions for each

course within a given number of rooms and time periods. More specifically, each instructor offers several courses in each semester and each course has one to five lectures per week depending on the credit hours of the course. Instructors can choose one set of time periods on which they prefer the lecturing to take place. Besides, they can also exclude another set of time periods.

The process of course scheduling begins by proposing courses and time periods. Each instructor fills in a course form that includes the course title, prefer- ence time slots, and exclusive time slots. After collecting all the course informa- tion offered by instructors, scheduling can then begin. After each course has been scheduled, the department will send the draft timetable to all instructors for the purpose of validation. If there is no problem, the timetable will be sent to the Dean of Academic Affairs. Otherwise, the department will adjust the timetable to satisfy the instructors’ new requirements.

From the problem description above, we can identify three actors including the instructor, the administrator, and the student. Every actor has its own objective:

•

•

•

Based on the requirements, several constraints can be identified that the courses scheduling system must satisfy:

1. Instructors usually offer more than one course, and these courses should not be sched- uled at the same time.

2. The courses cannot be scheduled at the same time as other required courses in the same class.

3. Only one course can be assigned to a classroom at any point of time.

4. Only available time slots of a classroom can be scheduled.

5. The registered students of a course should not exceed the capability of the classroom.

6. The scheduled times of courses should fall within the preference sets and none of the exclusion sets as much as possible.

7. The lectures of a course should not be scheduled in the continual time slots in a week period. The best scheduling policy for a three-credit-hour course is to schedule two lectures in continual time slots and the other one in another isolated time slot on another day.

Constraints can be further classified as hard or soft: the former have to be satisfied, while the latter are desirable but can be relaxed to attain a feasible solu- tion. In our example, constraints one to five are hard constraints, and the con- straints six and seven are soft.

A university timetabling problem in the Department of Computer Science and Information Engineering at NCU is used as an illustrate example to demon- strate our approach. The department has 19 faculty members and more than 550 students. The model was tested with real data containing 42 subjects to be sched- uled into 40 time slots and 6 rooms.

4. CONCEPTUAL MODELING THROUGH TASK-BASED CONCEPTUAL GRAPHS

In order to automate the software development process, we propose the use of TBCGs³⁴for conceptual modeling and to serve as a basis for transforming spec- ifications into executable codes ~see Figure 1!. First, we use TBCGs to capture and represent a conceptual model for the problem domain. To construct a con- ceptual model, task-based specification methodology ~TBSM!³⁴ is used to serve as the mechanism to structure the knowledge captured in conceptual models;

whereas conceptual graphs ~CGs! are adopted as the formalism to express task- based specifications and to provide a reasoning capability for the purpose of auto- mation. Second, the contextual retrieval mechanism²³proposes a multiple-viewed approach to help to acquire specifications and elicit information in contexts. To automate the reuse of existing TBCGs, the contextual retrieval mechanism uses fuzzy similarity to automatically match two surrounding contexts of specifica- tions and utilizes purpose-directed analogy for retrieving reusable specifications.

Third, the verification of TBCGs²⁴is performed on: ~1! model specifications of a task by checking the consistency of constraints networks through the constraint satisfaction algorithm and by repairing constraint violation using the constraint relaxation method; and ~2! process specifications of a task by checking the inter- level and intralevel consistency based on operators and rules of inference inher- ited in conceptual graphs. Finally, we operationalize TBCGs for the execution of task-based specifications. Once TBCGs have been constructed and verified, a black- board system will automatically transform TBCG specifications into an execut- able program. Major constituents of a software system such as database schemas, the knowledge base, and an initial user interface can also be generated by trans- forming TBCGs into their corresponding counterparts.

4.1. Task-Based Specifications in Conceptual Graphs

Task-based specification methodology acquires and organizes domain knowl- edge, functional requirements, and high-level problem-solving methods around the

Figure 1. Automated software development processes by TBCG.

general notion of tasks. A specification can be described at various abstraction levels and thus pieces of abstract specification can be refined into a more detailed one in a lower abstraction level. The specification has two components: a model specification that describes static properties of the system and a process specifi- cation that characterizes dynamic properties of the system. The static properties of the system are described by two models: a model about domain objects and a model about the problem solving states that we refer to as a state model. The dynamic properties of the system are characterized by ~1! using the notion of state transitions to explicitly describe what the functionality of a task is, and

~2! specifying the sequence of subtasks and interactions between subtasks ~i.e., behavior of a system! using task state expressions ~TSE!. A TSE uses the fol- lowing operators that can be divided into three groups: ~1! sequencing: follow operator, and immediately follow operator, ~2! branching: selection, optional oper- ator, and conditional operator, and ~3! iteration: iteration operator. Both the model and the process specifications can be first described in their high-level abstract forms, which can be further refined into more detailed specifications in the next level. The notion of task structure ~i.e., task /method/subtask!^35,36is adopted for the process refinement.

The conceptual graph^37,38is a directed, finite, connected graph and consists of concepts, concept instances ~referents!, and conceptual relations. Concepts and relations represent declarative knowledge. Procedural knowledge can be attached through actors. Actors represent processes that can change the referents of their output concepts, based on their input concepts. Concepts are represented in square brackets, relations in parentheses, and actors in angle brackets. Delugach has extended conceptual graphs to include a new type of node, demons ~in double angle brackets!, to cause creation and retraction of input and output concepts.³⁹A demon’s algorithm causes each of its actual output concepts with referents to be asserted ~i.e., marked!, while each of its actual input concepts is to be retracted. If there is more than one input concept, no demon action occurs until all of its input concepts have been asserted. The notion of constraint overlays has also been incor- porated into the conceptual graphs, which provides a method to attach constraints to objects and collections of objects that make up world states.^40,41Constraint over- lays, represented in angle brackets and linked to concepts with dash lines, can overlay actors ~procedures or constraints! on a conceptual graph to describe the changes to a model state.

Conceptual graphs have several useful features that can facilitate the map- ping from task-based specifications to their counterpart graphs. For example, terms and relations in domain model of TBSM can be directly mapped to concepts and conceptual relations, and the notion of partial conceptual graphs corresponds to the notion of partial model in our methodology. Details of task-based specifica- tions in conceptual graphs can be found in Ref. 34.

Referring to our course scheduling example, various components modeled using TBCG are fully discussed below.

Figure 2 shows a task structure of the course scheduler system. We will focus here on the Schedule-An-Instructor task ~i.e., T₂!. The functionality of the task Schedule-An-Instructor is to schedule all the courses that the instructor teaches in

the available time slot and classroom while various requirements and constraints are satisfied. This is achieved by iterating between three subtasks:

~1! Select-A-Course ~T₂₁!, which chooses the course among nonscheduled courses that the instructor lectures

~2! Schedule-A-Course ~T₂₂!, which attempts to schedule the current course for the cur- rent instructor

~3! Conflict-Resolution ~T₂₃!, which resolves time conflicts

A correct specification would indicate that Conflict-Resolution should be skipped under the situation that the current course is successfully scheduled for the current instructor. It is also desirable to indicate that if some courses have not been sched- uled for the instructor yet, the system should repeat another round to select a course, schedule the course, and resolve conflicts. The specifications in conceptual graphs for the tasks and methods relevant to this example are shown in Figure 3 through 6.

Domain Model. Since domain models are similar to entity-relationship mod- els, the transformation of terms, attributes, and relations to conceptual graphs is straightforward. First, a term becomes a concept of type ENTITY. Second, an attribute associated with a term is represented by a relation ~attr!, and an attribute name is characterized by a concept type as a data type through a relation ~chrc!.

Finally, a relation becomes a conceptual relation. Consider the task specification Figure 2. A task structure of the timetabling at NCU.

Figure 3. The task Schedule-An-Instructor.

Figure 4. A method of the task Schedule-An-Instructor.

of Schedule-A-Course in Figure 5, the domain model expresses three terms and their attributes; for example, the first term ~i.e., Course! has seven attributes ~i.e., Name, Session, Class, Required, Credit-Hours, Meeting, and Location!. The ref- erent of each concept attaches an “@” to indicate the cardinality of the concept.

Figure 5. The task Schedule-A-Course.

Figure 6. A constraint T₂₂⫺ L1in the state model of Schedule-A-Course.

State Model. A conceptual graph representation for a state model should cap- ture two main semantics in the model: the stages of completion and constraints satisfaction. Our translation rules are summarized as follows: ~1! To overlay con- straint actors on the conceptual graph of state objects. The constraint overlays are used to show the relationships among state objects. All state objects associated with a constraint actor are required to satisfy the relationship expressed by the actor. ~2! To use demons for state transitions whose inputs and outputs are state objects as referents of the type STATE, and input tokens are of the type TASK. No demon action occurs until all input concepts are asserted and all input tokens are enabled. The performance of tasks ~in the form of input tokens! is thus essen- tial for state transitions. For example ~see Figure 5!, in the task specification of Schedule-A-Course, the state model expresses that the state @~current!r @Instruc- tor#r ~instruct! r @Course# R ~current!# will be changed into another state @~cur- rent!r @Instructor# r ~instruct! r @Course# R ~scheduled!# under the conditions that ~1! constraints T₂₂⫺ L1, . . . , T₂₂⫺ L5are satisfied, and ~2! the task Schedule- A-Course is performed.

Functional Specifications. Preconditions, protections, and rigid postcondi- tions are represented by propositions. A soft postcondition can be viewed as a fuzzy proposition with fuzzy concepts and fuzzy conceptual relations.^{42– 44}Consider the task Schedule-An-Instructor in Figure 3: The precondition of the task repre- sented by a proposition says that there exists a current instructor who lectures a set of courses. The postcondition of the task expresses that the certain courses lec- tured by the instructor is scheduled.

Behavioral Specifications. TSE is an extension of regular expressions and therefore can be represented using state transition diagrams. To transform TSEs into conceptual graphs, we have adopted the notion of demons to represent transi- tions, which possesses the semantics of an actor node with respect to output con- cepts’ referents, with the additional semantics that a demon actually asserts its output concepts and then retracted its input concepts.³⁹We also assume that there is a mapping w that maps an expression to its state where the postcondition after progressing through the expression is true. The distinction between follow and immediately follow operator is noted by using the demon for the immediately fol- low operator with the task before and after the operator being marked, whereas the follow operator is transformed into a demon whose inputs are not yet completely marked.

In the cases of selectional, iteration, conditional, and optional operators, two conventions are adopted. First, we follow the tradition of demons by using an initiator demon ~i.e., ^^T &&! and a START concept ~a subtype of STATE! for the beginning state. Second, the convention of viewing a conditional test as a task

~e.g., see Ref. 45! is also adopted, denoted as b?, where b is a condition. That is, b? is a special control flow task that is invoked only when b is tested to be true, whereas¬b? is another special control flow task that is invoked only when ¬b is tested to be true. A final state is denoted by attaching the monadic relation ~final!.

The difference between selectional and conditional operators is that the expres- sionE1will not be performed unless the conditional test for b₁? is tested to be true, both of which are not marked. The optional operator is treated as a special

case of selectional operator. The iteration operator is implemented using three demons. The first demon is invoked by performing an expression E, while the second demon will be invoked by two input tokens, b? and E, to represent the notion of iteration condition. The third demon is to indicate the exit condition.

The mapping of TSE operators to conceptual graphs is summarized in Table I.

Method Specifications. A method in TBSM is to accomplish its parent task.

Generally, a method consists of a collection of subtasks, a guard condition to invoke the method, and a TSE to specify the temporal relationship among those subtasks.

Refer to TSE of the method in Figure 4, ^^T && and @START # indicate the initiator demon and the beginning state, respectively. The task T₂₁is performed first while condition b2 is tested to be true, and the state is then changed into @w~T₂₁!#. Next, the task T₂₂is performed and the state will be changed into @w~T₂₂!#. Subsequently, there exist two possible branches: ~1! when the condition @ b₃# is tested to be true, the task T₂₃will be invoked; and ~2! when the condition¬@ b3#is tested to be true, the state @w~T₂₂!#remains unchanged. In both cases, @ b₂#will be tested to

decide whether the iteration will be performed again or not. The states attached by

~ final !indicate the final states.

4.2. Operationalizing Task-Based Conceptual Graphs

Our approach operationalizes TBCGs by providing automatic translation into an expert system in CLIPS. To transform TBCGs into an executable system, it is needed to take multiple constituents of a software system such as database sche- mas and the knowledge base into consideration. In our approach, the goal of the problem-solving model is to transform a task into its corresponding software com- ponents. To achieve this purpose, we adopt the blackboard model ~see Figure 7!

that consists of a blackboard structure and five knowledge sources with their con- trol components. The problem-solving state data are kept in the blackboard struc- ture that is hierarchically organized into six levels of analysis. Knowledge sources produce changes to the blackboard that lead incrementally to a solution. Inter- actions among the knowledge sources take place solely through changes on the blackboard. Whenever a piece of knowledge is obtained, the blackboard system will automatically produce executable programs that will lead incrementally to a solution. Accordingly, our system exhibits both an opportunistic and incremental characteristics in dealing with a large amount of knowledge to generate software.

An element in the task level of the blackboard represents a task specification in TBCG. The task partition knowledge source breaks a task down into four mod- els: domain model, state model, functional model, and behavior model, to facili- tate the extraction of multiple views. Based on the domain model extracted from the task, the database construction knowledge source can automatically build up the database schemas. The rule extraction knowledge source generates rules from:

Figure 7. The blackboard model of our system.

~1! the state model, which contains knowledge about constraints, constraints sat- isfactions, states, and functions, ~2! the functional model, which describes pre- condition, protection, and postcondition, and ~3! the behavior model, which characterizes the dynamic behavior of a task. The UI information extraction knowl- edge source extracts information about formats and structures of knowledge from the domain model, information about human-computer interactions from the state model, and information about the system flow from the behavior model. Finally, in the knowledge base level, the knowledge base synthesis knowledge source inte- grates all rules from several tasks to form a knowledge base based on the notions of task structures.

4.2.1. Extracting into Database Schemas

Each fact in CLIPS is similar to a tuple in relational database schema and can be defined by the deftemplate construct. The domain model of a task is composed of a network of concepts and conceptual relations. As domain models are similar to entity-relationship ~ER! models, the transformation of concepts and conceptual relations to entities, attributes, and relations in ER models is straightforward. The database construction knowledge source first translates a domain model into deftemplate constructs for the purpose of reasoning in CLIPS and then maps these templates into relational database schemas for the purpose of storing facts. Table II indicates the mapping from domain models into deftemplate constructs with one- to-one correspondence. As a deftemplate construct is similar to a relational data- base schema, we can translate the construct into Oracle database formats directly.

Table II. Translating domain models into CLIPS.

Domain model The deftemplate construct

@C1:*#r~R!r@C2:*# ~deftemplate C1 ~slot C2!!

@C1:*#r~R!r@C2:$*%# ~deftemplate C1 ~multislot C2!!

@C1:$*%#r~R!r@C2:*# ~deftemplate C2 ~multislot C1!!

@C1:$*%#r~R!r@C2:$*%# ~deftemplate C1 ~multislot C2!!

~deftemplate C2 ~multislot C1!!

@C1:*#r~R1!r@@C2:*#r~R2!r@C3:*#@1# ~deftemplate C1 ~slot C2! ~slot C3!!

@C1:*#r~R1!r@@C2:*#r~R2!r@C3:$*%#@1# ~deftemplate C1 ~slot C2! ~multislot C3!!

@C1:*#r~R1!r@@C2:$*%#r~R2!r@C3:*#@1# ~deftemplate C1 ~multislot C2! ~slot C3!!

@C1:*#r~R1!r@@C2:*#r~R2!r@C3:*#@n# ~deftemplate C1 ~multislot C2! ~multislot C3!!

@C1:*#r~R1!r@@C2:*#r~R2!r@C3:$*%#@n# ~deftemplate C1 ~multislot C2!!

~deftemplate C2 ~multislot C3!!

@C1:*#r~R1!r@@C2:$*%#r~R2!r@C3:*#@n# ~deftemplate C1 ~multislot C3!!

~deftemplate C3 ~multislot C2!!

To ensure the key constraint and entity integrity constraint will never be vio- lated, we add an id slot to each deftemplate construct. The id slot must be unique and not null for every fact in CLIPS. To avoid the possible violation of referential integrity constraint, the deletion of a fact may cause the deletion of a field in other facts that refer to it.

4.2.2. Extracting into the Knowledge Base

Essentially, functions are computed by operationalizing a network of actors;

while state transitions are executed by operationalizing a sequence of demons. To perform functions, we define a set of actor primitives by which composite actors can be represented in terms of these primitive actors. The modularity of an actor is accomplished by translating each actor definition into an independent module in CLIPS. Facts and rules within an actor’s module will not affect those within other modules. To execute state transitions, we also define a set of TSE operators by which complex task sequence can be expressed in terms of these operators. The modularity of a method is accomplished by translating each task into an indepen- dent module in CLIPS. The execution of a TSE expression within a task’s module is irrelevant to other tasks.

Transforming Functions into CLIPS. TBCG’s functions are operational- ized by automatically translating actors into CLIPS. We have defined a set of actor primitives ~see Table III! that can be directly mapped to functions in CLIPS with one-to-one correspondence. These actor primitives provide four groups of pri- mary functions, including test functions, manipulation operators, I/O functions, and mathematical operators. Furthermore, these primitives comprise a substrate on which one can define composite actors.

Our approach allows the set of actor primitives to be extensible; that is, new primitives can be defined in terms of existing actor primitives. We use actor defi- nitions to serve as the mechanism by which one can define the semantics of com- posite actors. In Sowa’s conceptual graphs, an actor can be defined as combinations of other actors in a dataflow graph. Since actor primitives can be executed by translating them into corresponding codes in CLIPS, a composite actor that is com- posed of actor primitives can then be executable.

A composite actor is operationalized by means of executing its actor defini- tion. Since an actor definition is comprised of a set of primitives that are directly mapped to CLIPS, a composite actor can then be executed via translating its actor definition into executable codes. For the automatic transformation, we have devel- oped a TBCG CASE tool to create task-based specifications in conceptual graphs and to translate them into executable CLIPS codes.

Transforming State Transitions into CLIPS. TSE operators are used to spec- ify the sequence of subtasks to characterize the behavior of their parent task. Each task is viewed as an independent module in which the internal structure of any task is irrelevant to other tasks. In our approach, a task is translated into a defmod- ule construct. Since each task forms an individual module in CLIPS, the sequence of subtasks can be executed by using the focus command to choose which task’s module would be executed. As the current focus is the top value of the focus stack,

the focus command pushes a module onto the top of the focus stack and the previ- ous value of the current focus will be remained. When the agenda of the current focus becomes empty ~i.e., no rules are fired!, the current focus is popped up.

Rules outside the current module cannot be fired until the modules they belong to are focused upon.

An operator in the sequencing group, such as follow operator ~see Figure 8!, is composed of two continuous demons with associated concepts for their input states, input tasks, and output states. Each transition demon can be translated into a defrule construct within the module of its parent task, in which ~1! its input state is retracted, ~2! its output state is asserted, and ~3! its input task is focused upon.

The conditional operator ~see Figure 9! is composed of two branching demons with associated concepts including input states, input conditions, input tasks, and output states. Each demon can also be translated into a corresponding defrule construct in which ~1! its input condition is matched, ~2! its input state is retracted,

~3! its output state is asserted, and ~4! its input task is focused upon. For example, the first demon in Figure 9 will be translated into two rules as follows ~assuming

Table III. Actor primitives.

Mapping actor primitives to CLIPS functions and operators Test function

具Greater-Than典 ~⬎ 具numeric典 具numeric典!

具Greater-Than-Or-Equal-To典 ~⬎⫽ 具numeric典 具numeric典!

具Equal-To典 ~⫽ 具numeric典 具numeric典!

具Not-Equal-To典 ~⬍⬎ 具numeric典 具numeric典!

具Same-As典 ~eq具expression典 具expression典!

具Not-Same-As典 ~neq具expression典 具expression典!

具Less-Than典 ~⬍ 具numeric典 具numeric典!

具Less-Than-Or-Equal-To典 ~⬍⫽ 具numeric典 具numeric典!

具In典 ~member$具single-field典 具multifield典!

具Not-In典 ~not ~member$具single-field典 具multifield典!!

具Subset典 ~subsetp具multifield典 具multifield典!

具Not-Subset典 ~not ~subsetp具multifield典 具multifield典!!

Manipulation operators

具Insert典 ~insert$具multifield典 1 具single-field典!

具Delete典 ~delete$具m典 ~member$ 具s典 具m典! ~member$ 具s典 具m典!!

具Modify典 ~replace$具m典 ~member$ 具s1典 具m典! ~member$ 具s1典 具m典! 具s2典!

具Move典 ~delete$具m1典 ~member$ 具s典 具m1典! ~member$ 具s典 具m1典!!

~insert$具m2典 1 具s典!

I/O functions

具Read典 ~read!

具Printout典 ~printout具logical-name典 具expression典!

Mathematical operators

具Add典 ~⫹ 具numeric典 具numeric典!

具Subtract典 ~⫺ 具numeric典 具numeric典!

具Multiply典 ~*具numeric典 具numeric典!

具Divide典 ~/具numeric典 具numeric典!

that condition b₁is the conceptual graphs @Instructor#R ~scheduled ! and b2is

~NEG !r @@Instructor# R ~scheduled !# !.

~defrule Module-Name::S-T0-to-S-T1

?f1⬍- ~S-T0!

~exists ~Instructor ~id ?! ~state scheduled! ~status ?! ~exclusive-set $?!

~preference-set $?!

~course $?!!!

⫽⬎

~retract ?f1!

~assert ~S-T1!!

~focus T1!!

Figure 8. ~a! The follow operator; ~b! the rule for the demon on the left; ~c! the rule for the demon on the right.

Figure 9. The condition operator.

The iteration operator ~see Figure 10! is composed of a self-loop transition demon ~with its input state, input condition, input task, and output state! and an exit transition demon ~with its input state, input condition, and output state!. Both the self-loop demon and the exit demon will be translated into defrule constructs.

For example, the self-loop demon in Figure 10 will be translated into the follow- ing rule ~assuming that the iteration condition b₂is the conceptual graphs ~NEG !r

@@Instructor#R ~scheduled !# !.

~defrule Module-Name::S-T2-to-S-T2-iteration

?f1⬍- ~S-T2!

~not ~exists ~Instructor ~id ?! ~state scheduled! ~status ?!

~exclusive-set $?! ~preference-set $?!

~course $?!!!!

⫽⬎

~retract ?f1!

~assert ~S-T2!!

~focus T2!!

When the module of a task is focused upon, a fact ~START ! will be asserted if the task’s precondition is satisfied. Subsequently, ~START ! will cause a series of rules ~generated by TSE operators! to be fired. The dynamic behavior of TBCGs can then be executed by composing a set of TSE operators.

5. NCU TIMETABLING SYSTEM GENERATED THROUGH TBCG The university timetabling system at NCU can be divided into two parts. One is the user interface in Java as the front-end; another is the expert system in CLIPS through TBCG specifications as the kernel. We will focus our attention on the latter. The overall architecture of our system is illustrated in Figure 11.

Figure 10. The iteration operator.

5.1. Database Schemas

Each connected conceptual graph in the domain model will be mapped to a database schema. Consider the example of the task Schedule-A-Course ~see Fig- ure 5!. The database construction knowledge source will generate three templates in CLIPS, including Course, Instructor, and Available-Location. The deftemplate construct of Course is shown as follows:

~deftemplate Course ~slot id! ~slot state! ~slot name! ~slot session! ~slot class! ~slot required!

~slot credit-hours! ~multislot meeting! ~multislot location!!

As a deftemplate construct is similar to a relational database schema, we can translate the construct into Oracle database formats directly. First, the template name is mapped to a relation table name in relational database schema. Second, each slot is mapped to an attribute column whose type is a built-in data type. Third, a multislot is mapped to an attribute column whose type is a collection type. Finally, facts can then be mapped to tuples in the created object relational database schema directly. Consider the deftemplate construct generated from the Schedule-A-Course task, its corresponding database schema is shown below.

Course

id, state, name, session, class, required, credit-hours, $meeting%, $location%

Figure 11. Overview of the university timetabling system in NCU.

5.2. Knowledge Base

The rule extraction knowledge source extracts rules for constraints, con- straints satisfactions, states, and functions from the state model of each task:

•

Consider the constraint T22⫺ L¹in Figure 6, the rule part is translated into the rule:

~defrule Schedule-A-Course::T22-L1-rule

~and ~Course ~id ?id1! ~state current! ~name ?name1! ~session ?session1!

~class ?class1!

~required ?required1! ~credit-hours ?credit-hours1! ~meeting $?meeting1!

~location $?location1!!

~Instructor ~id ?id2! ~state current! ~status ?status! ~exclusive-set $?exclusive- set2!

~preference-set $?preference-set2! ~course $?course2!!!

~test ~member$ ?id1 $?course2!!

~forall ~Course ~id ?id1! ~state current! ~name ?name1! ~session ?session1!

~class ?class1! ~required ?required1! ~credit-hours $?credit-hours1!

~meeting $?pre1 ?one1 $?post1! ~location $?location1!!

~test ~not ~member ?one1 $?exclusive-set2!!!!

⫽⬎

~assert ~constraint-satisfaction ~constraint T22-L1!!!!

•

•

Hence, each state model will generate one rule for executing the state transition. Con- sider the state model in Figure 5, the input state will be retracted and the output state will be asserted when its associated constraint hierarchy is satisfied.

~defrule Schedule-A-Course::State-Transition

?f1⬍- ~task-is-satisfied!

?f2 ⬍- ~Instructor ~id ?id2! ~state current! ~status ?status2! ~exclusive-set

$?exclusive-set2!

~preference-set $?preference-set2! ~course $?course2!!

?f3⬍- ~Course ~id ?id3! ~state current! ~name ?name3! ~session ?session3!

~class ?class3! ~required ?required3! ~credit-hours ?credit-hours3!

~meeting $?meeting3! ~location $?location3!!

~test ~member$ ?id3 $?course2!!

⫽⬎

~retract ?f1 ?f2 ?f3!

~assert ~Instructor ~id ?id2! ~state current! ~status ?status2! ~exclusive-set

$?exclusive-set2!

~preference-set $?preference-set2! ~course $?course2!!!

~assert ~Course ~id ?id3! ~state scheduled! ~name ?name3! ~session ?session3!

~class ?class3! ~required ?required3! ~credit-hours ?credit-hours!

~meeting $?meeting3! ~location $?location3!!!!

To extract rules for the precondition and the protection from the function model of each task:

•

•

Finally, to extract rules about task sequences from the behavior model of each task, task state expressions will be translated into their corresponding rules through demons. Each demon can be transformed into a corresponding defrule construct in which its input condition ~if any! must be matched, its input state must be retracted, its output state must be asserted, and its input task ~if any! must be focused upon.

Once all rules in each task are extracted, the knowledge base synthesis knowl- edge source will integrate these rules using task structures. A task structure is an overall view of the system and can be used to lump all relevant rules together.

According to the task structure, the knowledge base synthesis knowledge source collects one task at a time from the highest level task. Therefore, we can ensure that rules for each task will not be omitted, and all rules in a system can be inte- grated under the notion of task structures.

6. CONCLUSION

In this article, we propose an automatic software engineering approach, called TBCGs, to addressing the university timetabling problem. TBCG provides the auto- mation of software development processes, including specification, verification, and automatic programming. A university timetabling system in the Department of Computer Science and Information Engineering at NCU is used as an illustra- tive example to demonstrate the proposed approach.

Our approach offers several benefits that are useful for addressing the chal- lenges in the timetabling problem:

•

•

•

Acknowledgments

This research is partially sponsored by the National Science Council ~Taiwan! under grant NSC92-2213-E-008-001.

References

1. de Werra D. Restricted coloring models for timetabling. Discrete Math 1997;165/166:161–

170.

2. Ferland JA, Roy S. Timetabling problem for university as assignment of activity to resources. Comput Op Res 1985;12~2!:207–218.

3. Hertz A. Finding a feasible course schedule using tabu search. Discrete Appl Math 1992;35~3!:255–270.

4. Knauer BA. Solutions of a timetabling problem. Comput Op Res 1974;1:363–375.

5. Moscato P, Norman MG. A memetic approach for the traveling salesman problem—

Implementation of a computational ecology for combinatorial optimization on message passing systems. In: Valero M, Onate E, Jane M, Larriba JL, Suarez B, editors. Proc Conf on Parallel Computing and Transputer Applications. Amsterdam: IOS Press; 1992.

pp 177–186.

6. Schaerf A. Local search techniques for large high school timetabling problems. IEEE Trans Syst Man Cybern A 1999;29~4!:368–377.

7. Tripathy A. Computerised decision aid for timetabling—A case analysis. Discrete Appl Math 1992;35~3!:313–323.

8. Johnson D. A database approach to course timetabling. J Op Res Soc 1993;44~5!:425– 433.

9. Mulvey JM. A classroom/time assignment model. Eur J Op Res 1982;9:64–70.

10. Boizumault P, Delon Y, Peridy L. Constraint logic programming for examination time- tabling. J Logic Programming 1996;26:217–233.

11. Deris S, Omatu S, Ohta H. Timetable planning using the constraint-based reasoning.

Comput Op Res 2000;27:819–840.

12. Jaffar J, Maher MJ. Constraint logic programming: A survey. J Logic Program 1994;

19~20!:503–581.

13. Monfroglio A. Time-tabling through a deductive database: A case study. Data Knowl Eng 1988;3:1–27.

14. Valouxis C, Housos E. Constraint programming approach for school timetabling. Comput Op Res 2003;30:1555–1572.

15. Dhar V, Ranganathan N. Integer programming vs. expert systems: An experimental com- parison. Commun ACM 1990;33~3!:323–336.

16. Gunsdhi H, Anand VJ, Yong YW. Automated timetabling using an object-oriented sched- uler. Expert Syst Appl 1996;10~2!:243–256.

17. Isaai MT, Cassaigne NP. Predictive and reactive approaches to the train-scheduling prob- lem: A knowledge management perspective. IEEE Trans Syst, Man Cybern C 2001;31~4!:

476– 484.

18. Isaai MT, Singh G. An object-oriented, constraint-based heuristic for a class of passenger- train scheduling problems. IEEE Trans Syst Man Cybern C 2000;30~1!:12–21.

19. Solotorevsky G, Gudes E, Meisels A. Raps: A rule-based language specifying resource allocation and time-tabling problems. IEEE Trans Knowl Data Eng 1994;6~5!:681– 697.

20. Hopfield JJ, Tank DW. Neural computation of decisions in optimization problems. Biol Cybern 1985;52:141–152.

21. Pellerin D, Herault J. Scheduling with neural networks: Applications to timetable construc- tion. Neurocomputing 1994;6:419– 442.

22. Smith KA, Abramson D, Duke D. Hopfield neural networks for timetabling: Formula- tions, methods, and comparative results. Comput Ind Eng 1995;44:283–305.

23. Lai LF, Lee J, Yang SJ. Fuzzy logic as a basis for reusing task-based specifications. Int J Intell Syst 1999;14:331–357.

24. Lee J, Lai LF. Verifying task-based specifications in conceptual graphs. Inform Software Technol 1998;39:913–923.

25. de Werra D. An introduction to timetabling. Eur J Op Res 1985;19:151–162.

26. de Werra D. Extensions of coloring models for scheduling purposes. Eur J Op Res 1996;92:474– 492.

27. Kiaser L, Yellen J. Weighted graphs and university course timetable. Comput Op Res 1992;19:59– 67.

28. Selim SM. Split vertices in vertex coloring and their application in developing a solution to the faculty timetable problem. Comput J 1988;31~1!:76–82.

29. Tripathy A. School timetabling—A case in large binary integer linear programming. Manag Sci 1984;30~12!:1473–1489.

30. Burke EK, Petrovic S. Recent research directions in automated timetabling. Eur J Op Res 2002;140:266–280.

31. Hertz A. Tabu search for large scale timetabling problems. Eur J Op Res 1991;54:39– 47.

32. Mausser HE, Magazine MJ. Comparison of neural and heuristic methods for a timetabling problem. Eur J Op Res 1996;93:271–287.

33. Schaerf A. A survey of automated timetabling. Artif Intell Rev 1999;13~2!:87–127.

34. Lee J, Lai LF, Huang WT. Task-based specifications through conceptual graphs. IEEE Exp 1996;11~4!:60–70.

35. Chandrasekaran B. Design problem solving: A task analysis. AI Mag 1990;11~4!:59–71.

36. Lee J, Lai LF. A high-level petri nets based approach to verifying task structures. IEEE Trans Knowl Data Eng 2002;14~2!:316–335.

37. Sowa JF. Conceptual structures: Information processing in mind and machine. Reading, MA: Addison-Wesley; 1984.

38. Sowa JF. Towards the expressive power of natural language. In: Sowa JF, editor. Princi- ples of semantic networks: Explorations in the representation of knowledge. San Mateo, CA: Morgan Kaufmann Publishers; 1991. pp 157–189.

39. Delugach HS. Dynamic assertion and retraction of conceptual graphs. In: Way EC, editor.

Proc Sixth Annual Workshop on Conceptual Graphs. Binghamton, NY: SUNY Bingham- ton; 1991. pp 15–26.

40. Eshner D, Hendler J, Nau D. Incremental planning using conceptual graphs. J Exp Theor Artif Intell 1992;4~2!:85–94.

41. Pfeiffer HD, Hartley RT. The conceptual programming environment, cp. In: Nagle TE, Nagle JA, Gerholz LL, Eklund PW, editors. Conceptual structures: Current research and practice. UK: Ellis Horwood; 1992. pp 87–107.

42. Lee J, Kuo JY. New approach to requirements trade-off analysis for complex systems.

IEEE Trans Knowl Data Eng 1998;10~4!:551–562.

43. Lee J, Liu KFR, Chiang WL. A fuzzy petri net based expert system for damage assessment of bridges. IEEE Trans Syst Man Cybern B 1999;29~3!:350–370.

44. Lee J, Liu KFR, Chiang WL. Modeling uncertainty reasoning with possibilistic petri nets.

IEEE Trans Syst Man Cybern 2003;33~2!:214–224.

45. Warren DHD. Generating conditional plans and programs. In: Proc Summer Conf on Arti- ficial Intelligence and Simulation of Behavior, Edinburgh, UK, July 12–14, 1976. pp 344–

354.