Automatic Timetable Generator

School of Science and Engineering
AUTOMATIC TIMETABLE GENERATOR
Capstone Design
SPRING, 2022
Younes Messari
Supervised by Dr. Iraqi Houssaini Omar

AUTOMATIC TIMETABLE GENERATOR
Capstone Report
Student Statement:
I have applied ethics to the design process and in the selection of the final proposed design, and I
have held the safety of the public to be paramount and have addressed this in the presented
design wherever may be applicable.
II
Acknowledgments:
First and foremost, I would like to express my deep and sincere gratitude to my capstone
supervisor, Dr. Iraqi Houssaini Omar, professor at Al Akhawayn University in Ifrane, for giving
me the opportunity to work on such a project for my capstone. I would also like to thank him for
helping all the way through my capstone project, and motivating me to work smarter, while
providing me with all the necessary support and inspiration to keep perfecting the project.
I would also like to express my regards to Dr. Salih Alj Yassine, professor at Al
Akhawayn University in Ifrane, for supervising my fellow classmates and I throughout the
semester, providing all the technical assistance we needed at any time.
Last but not least, I would like to thank my wife, Zineb Bourchouk, master’s student at
Al Akhawayn University in Ifrane, for being the greatest moral support and advisor I could have
asked for.
III
Table of contents:
Acknowledgements……………………………………………………………………….. III
Table of Contents…………………………………………………………………………. IV
List of Figures ……………………………………………………………………………. VII
Abstract…………………………………………………………………………………… VIII
1- Introduction……………………………………………………………………………. 1
2- STEEPLE Analysis……………………………………………………………………. 2
2.1- Social………………………………………………………………………… 2
2.2- Technological………………………………………………………………… 2
2.3- Economic …………………………………………………………………….. 2
2.4- Environmental………………………………………………………………... 2
2.5- Political………………………………………………………………………. 3
2.6- Legal………………………………………………………………………….. 3
2.7- Ethical………………………………………………………………………… 3
3- Feasibility Study………………………………………………………………………… 4
3.1- Technical……………………………………………………………………… 4
3.2- Operational…………………………………………………………………… 4
3.3- Economic……………………………………………………………………... 5
3.4- Legal………………………………………………………………………….. 5
3.5- Schedule………………………………………………………………………. 6
4- Requirements' Specifications…………………………………………………………… 6
4.1- Functional Requirements……………………………………………………... 6
4.2- Non-Functional Requirements……………………………………………….. 9
IV
5- Technology Enablers…………………………………………………………………… 9
5.1- Odoo Framework …………………………………………………………….. 9
5.2- Python………………………………………………………………………… 10
5.3- PostgreSQL…………………………………………………………………… 10
5.4- XML………………………………………………………………………….. 11
6- Design…………………………………………………………………………………... 11
6.1- Software Architecture………………………………………………………… 11
6.1.1- Odoo Front-End…………………………………………………….. 12
6.1.2- Database……………………………………………………………. 12
6.1.3- Odoo Logic………………………………………………………… 13
6.1.4- Automatic Generation Algorithm…………………………………... 13
6.2- ER Diagram………………………………………………………………….. 14
7- Implementation………………………………………………………………………… 15
7.1- Odoo Modules……………………………………………………………….. 16
7.1.1- Models……………………………………………………………… 17
7.1.2- Views……………………………………………………………….. 19
7.1.3- Security……………………………………………………………... 21
7.2- Automatic Timetable Generation…………………………………………….. 21
7.2.1- SQL to Text Conversion…………………………………………… 21
7.2.2- Automatic Generation Algorithm…………………………………... 22
7.2.3- Text to SQL Conversion……………………………………………. 23
8- Deployment…………………………………………………………………………….. 24
9- Testing………………………………………………………………………………….. 24
V
9.1- Data Creation…………………………………………………………………. 24
9.2- Using the Solution……………………………………………………………. 25
10- Conclusion and Future Work…………………………………………………………. 25
10.1- Conclusion…………………………………………………………………... 25
10.2- Future Work………………………………………………………………… 26
References…………………………………………………………………………………. 27
VI
List of Figures:
Figure 1: Software architecture of the solution
Figure 2: Generation algorithm cycle
Figure 3: Entity relationship diagram for the project
Figure 4: XML Definition of the tree view for the batch_instructor_subject model
Figure 5: Form view for the batch_instructor_subject model
Figure 6: List view for the batch_instructor_subject model
Figure 7: Search view for the batch_instructor_subject model
Figure 8: Visualization of the (1+1) ES and simulated hardening
Figure 9: Odoo data creation interface
VII
Abstract:
In this final report, I will be going over the steps and the development process of my
capstone project. After a quick introduction of what my project is, this report contains the
necessary elements needed for the software engineering lifecycle. Firstly, I will go over a
STEEPLE analysis to determine the relevance and rationale of my project. Next, I conducted a
feasibility study to showcase how this project is achievable in terms of technicalities, schedule,
legality… After that, I will cover the functional and non-functional requirements of this project in
order for me to reach its full utility. Moreover, this report will also cover the details of the project
from the software architecture, design, implementation details, to the technology enablers. Last
but not least, I will discuss and explain my future plans with regards to this project.
As you will see in this report, the workflow throughout the development process of this
solution went smoothly. Indeed, making use of the available technologies provided by Odoo, such
as models and views, makes it very easy for developers to produce a fast and reliable solution.
Also important to mention are the two paradigms that Odoo makes a great use of are ORM and
MVC. Lastly, the genetic algorithms used, which are the (1+1) Evolutionary Strategy combined
with simulated hardening, ensure a fast, effective and optimized generation of timetables
VIII
Automatic Timetable Generator
1 - Introduction:
The purpose of this capstone is the automatic timetable generation in a college/school
context through an Odoo module/service. Odoo is an enterprise resource planning software that
uses Python as its main language, as well as PostgreSQL as an RDBMS. One of the main
challenges faced by many institutions at the beginning of each term is finding an appropriate
schedule that optimizes classroom usage, faculty schedules and classes’ distribution throughout
the week. The main purpose of this Odoo module is to generate the most optimized weekly
timetable for the term in a few clicks, instead of having to do it manually. The resulting timetable
will allow students, faculty and administration to consult all aspects of the schedule they are
interested in. This includes but is not limited to the availability of a certain classroom throughout
the week and the weekly schedule of a student or faculty. This timetable generator is exclusive for
the use of educational institutions (colleges, high schools…). The aim behind it is not only to allow
the administration to find the most optimized schedule for the classes they offer, but also to allow
both students and faculty to use this service to consult their schedules.
Therefore, the first requirement of this project is to automatically generate an optimal
weekly schedule/timetable for the institution using it. Additionally, it has to be an Odoo
module/service. I will be using the Odoo interface, environment and features to develop this
solution. As I will be basing my design on some open-source algorithms and code, the constraints
on my solution can be split into hard and soft constraints. Hard constraints are essentially the ones
that cannot be omitted such as not having overlapping resources (faculty or classrooms for
instance). Soft constraints are mostly related to optimization, for example, minimizing idle time
slots for faculty and groups. One assumption I will make for this project is that students are split
into “groups”, and no student will pertain to two different groups. I will mostly use Python
1
combined with SQL and XML, in order to generate the timetable automatically based on the
constraints imposed by the user/institution, as well as the type of user, i.e: student, faculty,
administration…
2
2 - STEEPLE Analysis:
2.1 - Social:
As this module will essentially be made for educational institutions, it is important for me
to understand what different constraints might be imposed on me in different contexts. In fact, a
school/college can pertain to a certain educational system. Be it American, French or any other
system, it is important to identify the differences and similarities between those in order for me to
make the solution as adaptable and flexible as possible.
2.2 - Technological:
I chose to develop this product in the context of the Odoo environment as this will pose
new opportunities. Odoo, as a software, has been gaining a lot in popularity, and that, in different
fields. One of the fields that has not been reached yet (or at least not prominently) is the educational
field. That is why using Odoo as a production/development technology goes in parallel with the
growth of the demand for the software.
2.3 - Economic:
As this project does not involve any initial investments, performing an economic analysis
only involves the revenue that might be generated. Odoo allows developers to publish their
services and modules and make Odoo users pay in order to use them. As far as I am concerned, I
am indeed planning on making this service paid, as it is for an exclusive use and not open for the
public.
2.4 - Environmental:
3
In terms of environmental impact, this project can help manage waste. As of today, many
universities use papers and ink in order to print students’ schedules, faculty’s schedules, classroom
schedules… Moreover, printing also involves a lot of power. Thanks to this solution, not only is
one computer enough to generate the timetable automatically, but it is also unnecessary to print all
the schedules as they can be checked online at any given time.
2.5 - Political:
For the political impact, it is hard to pan it out on international politics. However, if we talk
about university politics, it would be very beneficial for the university to have a more centralized
decision making unit. Generating the university timetable using one same software allows for
traceability and reduces communication issues between departments.
2.6 - Legal:
This software will not only allow the university to enforce their policies when it comes to
scheduling their classes, but also keep track of which class was conducted in which classroom with
which professor and which group attended the class. All of this data can turn out to be very useful
for the university using the solution.
2.7 - Ethical:
The possibility of fostering clientelism and favoritism while generating the timetables can
be high when employees are in charge. Having this task performed by a software can remove those
risks and make sure that the generated timetable is completely unbiased.
4
3 - Feasibility Study
3.1 - Technical feasibility:
As mentioned in my initial specifications’ document, I will be using Odoo, an enterprise
resource planning software. Odoo’s core language is Python, which I happen to be familiar with
as I have used it in many other projects. As for the specificities of Python in the context of Odoo,
the online documentation provided in the Odoo official website gives plenty of information and a
full guide on how to develop new modules for Odoo. As for the database, Odoo relies on
PostgreSQL as an RDBMS. Having taken many classes where we used SQL as a language, and
given that I used SQL during my internship, I can safely say that I am very familiar with the
technology. Moreover, debugging and testing are phases of software engineering I am comfortable
performing. When it comes to hardware, I will be using my personal laptop as it is more than
enough to develop an Odoo module from scratch.
3.2 - Operational feasibility:
Odoo provides a great user interface. It is clear, straight-forward and easy to understand.
When developing a new module, the Odoo UI is the base for this latter. In addition to that, Odoo
modules are easy to maintain as the maintenance is actually performed and provided by Odoo
directly. The only time where I will be the one maintaining my module is when I will update it
with new features or removing bugs and mis happenings.
3.3 - Economic feasibility:
Developing an Odoo module is completely free. Creating an Odoo account is also free of
charges. Therefore, in terms of costs, there will be no fees to commit in the development process
5
of this module. As for the revenue, I am not planning on making my module a paid module,
therefore not generating any income either.
3.4 - Legal feasibility:
When it comes to the legal side, as I mentioned in the initial specifications’ document, I
will use some open-source algorithms and code. Them being open-source means my module’s
code will also have to be open source according to the GNU AGPL regulations (GNU, 2007).
When it comes to data protection, Odoo promises full privacy and protection of Odoo users’ data.
Therefore, I do dont have to worry, as a developer, about that aspect either.
3.5 - Schedule feasibility:
In terms of schedule, I had a little more than two months to work on this project. As I was
able to split the project into many micro-tasks, the different milestones I had to achiever were
already distinct. First one was setting the Odoo environment on my machine. In parallel, I started
working on my ER diagram for the database. Next, I had to integrate the open-source algorithm to
make it work as an Odoo module. After some testing and debugging, the module was ready for
operation.
6
4 - Requirement Specifications
4.1 - Functional Requirements
• Managing entities:
o Classrooms:
▪ Entity definition: classroom entity represents the physical locations where
classes can be offered. The manager should be able to:
▪ Add classrooms
▪ Edit / Update classrooms
▪ Remove classrooms
▪ View for classrooms in tree view
o Instructors:
▪ Entity definition: instructor entity represents the instructors who will teach
the classes. The manager should be able to:
▪ Add instructors
▪ Edit / Update instructors
▪ Remove instructors
▪ View instructors in tree view
o Subjects:
▪ Entity definition: subject entity represents the courses available at the
institution. The manager should be able to:
▪ Add subjects
▪ Edit / Update subjects
▪ Remove subjects
7
▪ View subjects in tree view
o Terms:
▪ Entity definition: term entity represents the term when classes are offered.
It could be a semester, a trimester or an academic year. The manager should
be able to:
▪ Add terms
▪ Edit / Update terms
▪ Remove terms
▪ View terms in tree view
o Batches:
▪ Entity definition: batch entity represents a group of students who will take
a set of classes. The manager should be able to:
▪ Add batches
▪ Edit / Update batches
▪ Remove batches
▪ View batches in tree view
• Managing constraints and bridge tables:
o Subject - Instructor:
▪ Entity definition: determines which instructor teaches which subject. The
manager should be able to add / update / delete instances of this entity,
which will then cascade to the timetable.
8
o Subject - Classroom:
▪ Entity definition: determines where a specific subject should be taught.
Sometimes, there is no specific classroom for a subject. The manager should
be able to add / update / delete instances of this entity, which will then
cascade to the timetable.
o Batch - Subject - Instructor:
▪ Entity definition: basically the equivalent of a class. We can have multiple
sections of a class where in each of them, the batches will be different. The
instructor and classroom can be the same but not necessarily. The manager
should be able to add / update / delete instances of this entity, which will
then cascade to the timetable.
• Additional constraints:
o Classes between 9am and 9pm
o No resource overlapping (teacher, group, classroom)
o Class should take place in allowed classroom
o Minimize idle time for teachers and groups
o One hour on a teaching week where no one has classes
4.2 - Non-Functional Requirements:
According to Altexsoft’s blog (2020), the non-functional requirements applied to my project
are as follows:
• Performance and scalability: As the algorithm is based on a (1+1) evolutionary strategy
and simulated hardening, the performance is optimized for this specific solution.
9
• Portability and compatibility: Given that this is an Odoo module, it makes it very
portable and compatible with all machines, since it is a SaaS.
• Reliability, availability, maintainability: Failure of the software automatically means
failure of the machine or of Odoo, since it fully depends on these two. As for
maintainability, it is easy for me, as a developer, to update and fix bugs using my
knowledge in Odoo development.
• Security: The data is mostly stored locally, therefore, the security of the data is based on
how secure the machine is.
• Usability: Odoo provides a clear and easy to use user interface, which makes using the
software very easy.
10
5 – Technology Enablers:
5.1 – Odoo Framework
As mentioned in the introduction of the report, Odoo is an enterprise resource planning
software that uses Python as its main language, as well as PostgreSQL as an RDBMS (Odoo,
2020). Odoo is mainly used by companies and institutions as it offers many services called
“modules”. These modules vary from appointment scheduling to regular calendars. Odoo also
offers a feature for fellow developers, where they are able to create a new module from scratch or
based on an existing one, and add their own customized features. This latter use is the one I am
taking benefit from as I am developing this module from scratch.
5.2 – Python
As mentioned above, Odoo uses python as its main language. Everything related to
business logic is coded in Python. Not only is this good because we, developers, can benefit from
the flexibility and efficiency of native Python, but Odoo also provides a custom API that contains
methods and attributes specific to the creation of modules. Let’s have a look at how tables/entities
can be defined for the sake of the example. Let us assume we want to create an entity for
instructors. The first step is creating a new python file called “instructor.py”. Inside this file, we
need to import the necessary libraries provided by Odoo, which are fields, api and models. Then,
we create a class Instructor. Inside, we can now start defining the specifics for the table such as
the names, attributes, constraints… After that, there are two important files that are the global
_init_.py file, and the models’ _init_.py file. In the first one, we simply import all the models, so
we would have a line that looks like “from . import models”. In the second one, we import the
models themselves, so we would have the line “from . import instructor”. The last important file
11
is the _manifest_.py file. It contains all the information about the application such as the name,
version, description…
5.3 – PostgreSQL:
In Odoo, PostgreSQL is mainly used “under the table”. As developers, we can access the
SQL tables, but we generally wouldn’t need to as all the information we might need is available
directly in the Odoo interface. By going to Settings → Technical, we can basically access all the
components of our Odoo module from models to views. However, in my case, as the business
logic is performed outside of the Odoo context, I need to perform some SQL queries in order to
retrieve the data directly from the database and parse it to make it work in the automation algorithm
mentioned in the software architecture part.
5.4 – XML:
For the user interface, Odoo provides XML support. The structure of the XML file is
specific to Odoo as the opening tag is <odoo>. XML is mostly used for what we call “views”.
Views are the components that determine how the data is to be displayed. We have four main
views in Odoo. Tree view is the equivalent of a list. It displays the data in the form of a table, like
we see in SQL. Kanban view is a way of displaying each instance in a rectangle. The closest way
to describe it is how we see items in an online shop. The form view is used for data input. The
form view is how the user will be prompted to fill in some information about the instance he/she
is creating. Lastly, the graph view is mostly used for analytical data rather than display. For any
of these views, in the XML file, we only determine which attributes are to be displayed.
12
6 - Design:
6.1 – Software Architecture:
Odoo is an enterprise resource planning software that uses Python as its main language, as
well as PostgreSQL as an RDBMS. As shown in the figure below, my software can be decomposed
into four essential parts:
Figure 1: Software architecture of the solution
6.1.1 - The Odoo Front-end:
Odoo provides a friendly UI that is convenient and comfortable to use. Be it for the end
user, or for the developer, it is very easy to navigate the different features provided by Odoo itself,
as well as the features provided by the different modules and extensions that can be installed on
Odoo.
13
6.1.2 - The Odoo Back-End:
For developers, Odoo provides detailed documentation, accessible through the link
https://www.odoo.com/documentation/14.0/eng/. The documentation gives detailed instructions
and information on every aspect of developing an Odoo module, from the installation of the Odoo
environment on your machine, to the publication of the module, going through models (database
tables), security (access and visibility), views (UI-related) and business logic. The Odoo logic is
linked to the Odoo interface as it allows to determine the UI elements the developer wants, such
as the forms (to create, edit and delete new data), the trees, kanbans and graphs (to view the data).
The Odoo logic unit is also linked to the RDBMS as it stores and retrieves the data directly from
this latter. The main element that links Odoo to the RDBMS is called a “model”. A model is the
way Odoo represents a table in the RDBMS.
6.1.3 – The Database:
Odoo uses PostgreSQL as the default RDBMS. During the installation of Odoo, the installation
of PostgreSQL is done automatically. The RDBMS is mainly used to store and retrieve the data in
the context of the Odoo module. Also installed automatically is pgAdmin. This latter is rarely used
as Odoo already provides a built-in database manager that handles the database in Odoo
terminology (using models instead of tables, for instance) which makes it easier for developers to
keep track of the updates and modifications they bring to the module.
6.1.4 – The Automatic Timetable Generation Algorithm:
The automatic generation algorithm is the core of the business logic. Initially, as I used an
open-source algorithm available on GitHub, the business logic is already implemented. However,
14
to make it work with Odoo, it is necessary to link it directly to the database, rather than linking it
to Odoo. The way the generation algorithm works is shown in the second figure attached below.
As shown in the latter, the generation algorithm cycle works in five main steps:
1. Retrieve the data from the database
2. Parse the data into the appropriate format that is supported by the algorithm
3. Run the algorithm on the retrieved data
4. Get the output file
5. Convert the output file into SQL queries to store the result in the database.
Figure 2: Generation algorithm cycle
6.2 – ER Diagram:
The entity relationship diagram shown in the figure below shows all the entities I worked
with throughout this project, as well as the relationships between them. We can identify two
different types of tables in the diagram. The first ones are the actual entities of the database such
15
as “Classroom”, “Instructor”, “Subject” and “Batch”. The second ones are bridge tables whose
only purpose is to link two entities or more with one another, like “Subject_Instructor” and
“Subject_Classroom”. These tables will be used to enforce constraints. For instance, before adding
a class (which is the “Batch_Instructor_Subject” table), the database will check whether or not this
specific instructor teaches this subject, as well as whether this subject can be taught in that specific
classroom. The last table, “Timetable”, is the one filled automatically. The user has no control over
it as it is handled solely by the automatic timetable generation algorithm.
Figure 3: Entity relationship diagram for the project
16
7- Implementation:
Odoo is a very complete framework. It contains many elements that allow for an easy and
smooth development. One of the main features brought by Odoo is “Object Relational Mapping”
(ORM) (Odoo, 2021). Object relational mapping can be seen as a layer of abstraction between the
code and the RDBMS (Technopedia, 2011). It allows the developer to implement a solution using
a database without necessarily writing any SQL query (Altexsoft, 2021). As mentioned many time
throughout this report, the basic building block of Odoo is called “a module”.
7.1 – Odoo Modules
Modules can be compared to applications. Saying “Odoo application” is the same as saying
“Odoo module”. As companies, these modules can be viewed as services that can be downloaded
and installed. Each module can serve a specific purpose. However, as developers, these modules
can be viewed as an opportunity to add a new service or complete an already existing service
(which is what most Odoo developers do). Upon creating a new module, the structure of this latter
is always predefined. Withing this structure, there are four essential folders: views, controllers,
models and security. An Odoo module’s essential information can be found in a file called the
manifest. The manifest file is a python file (named “__mainfest__.py”). It contains all the
important information related to the module being developed. For instance, the manifest file is
where we can find the information related to the module name, version, category… We can also
find in this file all the dependencies since, as mentioned above, a module can be developed to add
new features to an already existing module. Lastly, we can also find the data that is used in that
17
very module. This data is related to security, views … (these concepts will be explained later on
in this report).
Odoo is also known for their take on the MVC architecture. MVC stands for “Model-View-
Controller”. It is a paradigm that allows the developer to “separate between data (models), user
interface (views)” by adding an intermediate layer called “the controller” (Odoo, 2021). In the case
of my project, the models are the different tables created in the database. These tables are shown
in section 6.2. As for the views, they are essentially how the user interface looks, through the
different types of views mentioned and shown below. From the MVC architecture of an Odoo
module, below is a detailed explanation on how each was user in this customized module:
7.1.1 – Models
A model can be assimilated to a SQL table. A model is a python file. The information it
contains is as follows:
- Model name: which is the name of the table once created in the SQL
database. The name attribute is determined through the _name
attribute as follows:
_name = “ttgen.classrooms”
which will result in the creation of a table called “ttgen_classroom”
in the database (dots are replaced by underscores).
- Fields: the fields are the equivalent of attributes in SQL. Just like in
SQL, Odoo allows the developer to determine the the name of the
attribute, the data type, as well as how the attribute will be shown in
the Odoo view.
building = fields.Integer(string='Building', required=True)
18
In the example above, the attribute in SQL will be called “building”
and be of type “Integer”. In an Odoo view, the name will be shown
as “Building”. This field is necessary and no instance of the
classroom model can be created without a “building” attribute,
which is why the “required” attribute is set to “true”. Also, we can
add fields that are from other tables (foreign keys), the same way it
is done in SQL:
In the example above, we have a field called “classroom_id”.
Conventionally, when we have a foreign key in a table, the name of
the attribute is the name of the module the foreign key is from with
“_id” in the end. “Many2one” is how Odoo will understand that this
field comes from another model, and this model is the first attribute,
which is “ttgen.classroom” in this case. Laslty, Odoo allows to add
computed fields. These fields’ values are then related to another
fields (or other fields) and the computation(s) to be performed are
simple python functions.
In the code snippet above, the “name” attribute is computed through
the “_get_classroom_name” function.
19
- Constraints: Odoo also allows the developer to define the constraints
on a certain table. The constraints can be listed in a python list called
“_constraints” like follows:
The constraint above is called “check_existence” and it ensures that
the combination of the two attributes ‘building’ and ‘roomNumber’
is unique. In case there is an error, the message displayed will be
“This classroom already exists”.
7.1.2 – Views
Also, part of the Odoo environment are what we call “views”. A view is what determines
how the data is to be displayed to the end user. Views are defined in an XML file, like shown in
the figure below. This latter shows the definition of a tree view for one of my models - the
instructor_subject model.
Figure 4: XML Definition of the tree view for the batch_instructor_subject model
20
There are three view types I used in this project which are:
- Form view: which is the view that will be displayed to the user
when they want to create a new instance of a model (inserting)
Figure 5: Form view for the batch_instructor_subject model
- List view: which is how the view that will be displayed to the user
while viewing the existing data (viewing).
Figure 6: List view for the batch_instructor_subject model
21
- Search view: which is how the user can filter the data from the list
view based on a certain attribute or field.
Figure 7: Search view for the batch_instructor_subject model
7.1.3 – Security
The security folder is what I used in order to give access to the models. The main security
file is called “ir.model.access” and it is a “.csv” file. This file is what will determine whether an
instance of a model can be created, written into the database or read from it.
7.2 – Automatic Timetable Generation:
7.2.1 – SQL to Text Conversion:
For the parser that lies between the PostgreSQL database and the automatic generation
algorithm, I used a library called psycopg2, which allows to query an SQL database using python.
The first step is setting the SQL parameters. That is, it is necessary to determine the database name,
password, as well as host username. These parameters are then used to initialize a cursor, which is
what will allow us to write pure SQL queries in the middle of our python code. A query is executed
through the command “cursor.execute()” as shown in the code snippet below.
22
The result of the execution of this line is a python list. From there, I simply parsed the data
retrieved from the database into the appropriate format that is handled by the automatic generation
algorithm.
7.2.2 – Automatic Generation Algorithm:
The parsing algorithm from the above paragraph outputs the parsed data in a “.txt”
file. This text file is then used as an input for the automatic timetable generation algorithm. This
latter “implements one of possible solutions for generating university schedules. The proposed
solution is based on methods of evolutionary computing, uses (1+1) evolutionary strategy and
simulated hardening” (N. Dresevic, 2018). Already, we can see two methods mentioned in the
quote above. These are (1+1) evolutionary strategy and simulated hardening. (1+1) evolutionary
strategy belongs to the computing category of artificial evolution, “which use mutation,
recombination, and selection applied to a population of individuals containing candidate solutions
in order to evolve iteratively better and better solutions.” (Beyer, 2007). In evolutionary
algorithms, each iteration is called a generation. From each generation, we evaluate the elements
that are the furthest from the goal, and rerun the algorithm on them, until all the elements are close
enough (depending on the constraints) to the goal (Auger, 2009). In the case of my solution, the
(1+1) evolutionary strategy is used to ensure the hard constraints. As for simulated hardening, it is
mainly used to ensure the soft constraints to some extent. The reason behind that is that simulated
hardening can only “harden” the solution to some extent. For visualization purposes, the goal can
23
be represented as a wide circle, where the (1+1) ES will get all the elements within that circle, and
simulated hardening will only “try” to get those elements closer to the center (Weng, 2019).
Figure 8: Visualization of the (1+1) ES and simulated hardening
The resulting timetable information are then written into a text file in a specific format.
7.2.3 – Text to SQL Conversion:
Just like for the first parser, I used the psycopg2 library. The only difference is that, instead
of sending “SELECT” queries to the database and parsing them into a text file, I am extracting the
necessary information from the output text file of the generation algorithm and converting this
information into “INSERT” SQL queries. The whole parser does the “actual” work in the lines
shown in the code snippet below:
24
As we can see, the “INSERT” query is executed, the changes are committed, and the parser’s
work is done. It then moves on to the next set of lines in the text file.
25
8- Deployment:
Using this solution could not be any easier thanks to Odoo. The process can be summarized
to three steps. The first one is downloading and installing Odoo on the machine. Since Odoo is the
service provider, the two remaining steps will only require the first one. The second step is
installing the module. That can be done by simply dragging the folder called “TTGenerator” into
the “Modules” folder in the installation path of Odoo, then searching for the module’s name on
Odoo. The last step is using the module. Now that it is installed on the machine, it is ready to be
used and tested.
26
9- Testing:
9.1- Data Creation
Creating data in Odoo is simple. The Odoo interface allows an ease of access to all the
features and functionalities available. In order to do so, we need to navigate to the entity we want
to create an instance of in the menu bar, circled in red in the figure below, and then simply clicking
the “Create” button, circled in blue. We will then be prompted with the form view, as described
and shown in section 7.1.2. We then need to fill in the necessary information, and click on the
“Save” button. The data is thereafter created into the database.
Figure 9: Odoo data creation interface
9.2- Using the Solution:
As mentioned throughout the report, the purpose of the module is to make it easy for the
user to get the most optimal timetable for the term without many efforts. That is why this solution
is designed in such way that the timetable is automatically updated as data is added. Therefore,
using the solution requires nothing more than adding the data into the database.
27
10- Conclusion and Future Work:
10.1 – Conclusion:
To sum up this report, I can confidently say that the progress I made so far is very
satisfying. I learned the major Odoo development basics as well as understood how genetic
algorithms and evolutionary strategies can work together to optimize goal-finding in terms of time
and space complexity. As for my understanding of Odoo, I would like to thank Dr. Iraqi once again
for giving me such an amazing opportunity to learn the framework and discover the features it
provides. It is a great discovery on my side.
Lastly, I would also like to mention that all the links I used, be it on my project or in this
report are cited in the references section.
10.2 – Future Work:
Since this module is now fully functional and ready to be deployed, it is my task as a
developer to make sure it remains bug-free and does not contain any logical errors. That is why
the module, in my opinion, still requires lots of testing to ensure a reliable solution that will always
suggest the most optimized timetable without inconveniencing the user. As it is now, the solution
still needs some perfecting in terms of constraints and triggers in the SQL part. Even though most
of the constraints are already implemented, some still need to be tailored for the module to be
adaptable in different contexts. As for triggers, even though Odoo provides cascading on updates
and deletes, there are some special cases that require some custom triggers. One example I can
give is if an instructor stops teaching a class (meaning deleting an instance from the
subject_instructor table), then it should cascade into the classes table and delete all the lines where
that instructor is teaching that subject.
28
Lastly, data creation can sometimes be tedious. Although it is only done once at the
installation of the module, it can be exhausting for a department / person to manually input each
classroom, instructor, subject… especially when dealing with a large-scale institution. Therefore,
my goal is to find a way to make this process less tiring and repetitive.
29
References:
Weng, L. (2019, September 5). Evolution strategies. Lil'Log (Alt + H). Retrieved April 9, 2022,
from https://lilianweng.github.io/posts/2019-09-05-evolution-strategies/
NDresevic. (n.d.). NDresevic/timetable-generator: Timetable generator for university schedule

implemented in python using genetic algorithms. GitHub. Retrieved April 9, 2022, from
https://github.com/NDresevic/timetable-generator
Developer. Odoo. (n.d.). Retrieved April 9, 2022, from

https://www.odoo.com/documentation/15.0/developer.html
Techopedia. (2011, September 26). What is object-relational mapping (ORM)? - definition from
Techopedia. Techopedia.com. Retrieved April 9, 2022, from
https://www.techopedia.com/definition/24200/object-relational-mapping--orm
Auger, A. (2009, July). Benchmarking the (1+1) evolution strategy with one-fifth success rule.
ACM-GECCO Genetic and Evolutionary Computation Conference. FFInsria. Retrieved
April 9, 2022 from https://hal.inria.fr/inria-00430515/document
Beyer, H.-G. (n.d.). Evolution strategies. Scholarpedia. Retrieved April 9, 2022, from
http://www.scholarpedia.org/article/Evolution_strategies
MVC - model, view, controller. MVC - Model, View, Controller. (n.d.). Retrieved April 10,
2022, from https://doc.odoo.com/5.0/vi/developer/1_3_oo_architecture/mvc/
Editor. (2020, February 12). Non-functional requirements: Examples, types, how to approach.
AltexSoft. Retrieved April 9, 2022, from https://www.altexsoft.com/blog/non-functional-
requirements/
Editor. (2021, March 11). Understanding object-relational mapping: Pros, cons, and types.
AltexSoft. Retrieved April 9, 2022, from https://www.altexsoft.com/blog/object-relational-
mapping/
Orm API. Odoo. (n.d.). Retrieved April 9, 2022, from

https://www.odoo.com/documentation/15.0/fr/developer/reference/backend/orm.html
Licence Publique Générale GNU affero, v3.0 - projet GNU - free software foundation. [une tête
de GNU] . (n.d.). Retrieved April 9, 2022, from https://www.gnu.org/licenses/agpl-
3.0.fr.html
30

Automatic Timetable Generator

Uploaded by

Copyright:

Available Formats

Automatic Timetable Generator

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Automatic Timetable Generator

Uploaded by

Copyright:

Available Formats

School of Science and Engineering

AUTOMATIC TIMETABLE GENERATOR

Supervised by Dr. Iraqi Houssaini Omar

design wherever may be applicable.

semester, providing all the technical assistance we needed at any time.

List of Figures ……………………………………………………………………………. VII

2.3- Economic …………………………………………………………………….. 2

4.1- Functional Requirements……………………………………………………... 6

4.2- Non-Functional Requirements……………………………………………….. 9

5.1- Odoo Framework …………………………………………………………….. 9

6.1- Software Architecture………………………………………………………… 11

6.1.1- Odoo Front-End…………………………………………………….. 12

6.1.3- Odoo Logic………………………………………………………… 13

6.1.4- Automatic Generation Algorithm…………………………………... 13

7.1- Odoo Modules……………………………………………………………….. 16

7.2- Automatic Timetable Generation…………………………………………….. 21

7.2.1- SQL to Text Conversion…………………………………………… 21

7.2.2- Automatic Generation Algorithm…………………………………... 22

7.2.3- Text to SQL Conversion……………………………………………. 23

9.2- Using the Solution……………………………………………………………. 25

10- Conclusion and Future Work…………………………………………………………. 25

10.2- Future Work………………………………………………………………… 26

Figure 1: Software architecture of the solution

Figure 2: Generation algorithm cycle

Figure 3: Entity relationship diagram for the project

Figure 5: Form view for the batch_instructor_subject model

Figure 6: List view for the batch_instructor_subject model

Figure 7: Search view for the batch_instructor_subject model

Figure 8: Visualization of the (1+1) ES and simulated hardening

Figure 9: Odoo data creation interface

The purpose of this capstone is the automatic timetable generation in a college/school

Therefore, the first requirement of this project is to automatically generate an optimal

to understand what different constraints might be imposed on me in different contexts. In fact, a

make the solution as adaptable and flexible as possible.

growth of the demand for the software.

the schedules as they can be checked online at any given time.

traceability and reduces communication issues between departments.

for the university using the solution.

3.1 - Technical feasibility:

As mentioned in my initial specifications’ document, I will be using Odoo, an enterprise

enough to develop an Odoo module from scratch.

3.2 - Operational feasibility:

with new features or removing bugs and mis happenings.

3.3 - Economic feasibility:

therefore not generating any income either.

3.4 - Legal feasibility:

Therefore, I do dont have to worry, as a developer, about that aspect either.

3.5 - Schedule feasibility:

4.1 - Functional Requirements

▪ Entity definition: classroom entity represents the physical locations where

classes can be offered. The manager should be able to:

▪ Edit / Update classrooms

▪ View for classrooms in tree view

the classes. The manager should be able to:

▪ Edit / Update instructors

▪ View instructors in tree view

▪ Entity definition: subject entity represents the courses available at the

institution. The manager should be able to:

▪ Edit / Update subjects

▪ View subjects in tree view