Arab Open University- Lebanon Faculty of Computer Studies Information Technology and Computing Department University Courses Scheduling Automation: An Aspect Oriented Approach Omar M. Al Kaissy 080015 T471: Final Year Project, May 2010 Supervisor: Dr. Nouhad Amaneddine
44
Embed
Faculty of Computer Studies Information Technology and ...aou.edu.lb/OnlineServices/Preface/1143.pdf · TMA03 March 2010 6 Revision and improvements Project Report TMA04 April 2010
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Arab Open University- Lebanon
Faculty of Computer Studies
Information Technology and Computing
Department
University Courses Scheduling Automation:
An Aspect Oriented Approach
Omar M. Al Kaissy 080015
T471: Final Year Project, May 2010
Supervisor: Dr. Nouhad Amaneddine
2
DEDICATION
This work is dedicated to my mother, brother, aunt and my father (RIP), and to all my tutors and friends.
3
ACKNOWLEDGMENT
All of the below mentioned tutors have contributed to my academic success at the Arab Open University and I would like to thank each and every one of them.
Dr. Nouhad Amaneddine
Dr. Ahmad Fadlallah
Dr. Ali Atieh
Dr. Charbel Fares
Mr. Ali Harb
Mr. Marwan Al Khatib
Mr. Hadi Barada
Ms. Anne-Marie Boustany
Mr. Tarek Mahmoud
Mr. Chadi Ghaith
Ms. Diana Nasereddine
Ms. Rayhana Itani
Ms. Mona Rizkallah
Mr. Dani Zgheib
Mr. Vahajkn Kabakian
Mr. Mohamad Kuleilat
Ms Sanaa Itani
4
ABSTRACT University sections scheduling deals with organising encounters (sections)
between teachers and students. This scheduling must satisfy organizational and
personal costs; this problem is considered to be a very difficult combinatorial
optimization problem.
Educational administrators attest to the difficulty of solving the problem of
sections scheduling: How to ensure adequate teaching resources and teachers
are available in the appropriate classrooms with the appropriate students at the
appropriate times. Mathematicians have proved that this kind of problems to be
NP-hard (Non-deterministic Polynomial) meaning it ranks alongside the classic
logistics problem such as the travelling salesman problem and the crystal
packing problems.
This work presents a new customized approach to scheduling based on the
requirements of the Arab Open University.
5
TABLE OF CONTENTS Dedication.............................................................................................................2
1.1 Iterate over the group of tutors and get course tutors;
1.2 Create day objects;
2.1 Find tutors who teach at the given days and during morning (8 -> 12),
afternoon (12 -> 18) and evening (18 -> 21) periods and hold them to
day objects;
2.2 Divide the number of required morning sections for the course by 6
(week days including Saturday) the quotient will be amIter and the
remainder is amRemainder;
2.3 Iterate amIter times over day objects and find an available tutor to
teach a section in the morning, if found, create a section object, if not,
increment the number of suggested sections for that day in the
morning period;
2.4 Find amRemainder different days where we can find available tutors to
teach a section;
2.5 What is left should be incremented to suggested sections number of
least sections days;
3.1 Divide the number of required evening sections for the course by 5
(week days excluding Saturday) the quotient will be pmIter and the
remainder is pmRemainder;
3.2 Iterate pmIter times over day objects and find an available tutor to
teach a section in the evening, if found, create a section object, if not,
increment the number of suggested sections for that day in the
evening period;
3.3 Distribute pmRemainder sections evenly over least sections days
where there is available tutors to teach;
29
3.4 What is left should be incremented to suggested sections number of
least sections days;
4.1 Divide the number of required afternoon sections for the course by 5
(week days excluding Saturday) the quotient will be anIter and the
remainder is anRemainder;
4.2 Iterate anIter times over day objects and find an available tutor to
teach a section in the afternoon, if found, create a section object, if
not, increment the number of suggested sections for that day in the
afternoon period;
4.3 Distribute anRemainder sections evenly over least sections days
where there is available tutors to teach;
4.4 What is left should be incremented to suggested sections number of
least sections days;
4.5 Find available rooms for the scheduled sections to be taught at.
30
2.4. IMPLEMENTATION
2.4.1. IMPLEMENTATION TOOLS:
• Netbeans IDE:
Used to write java code of the classes that does the actual functionalities
of the proposed software;
Version used: 6.8.
• Microsoft Access DBMS:
Used to design and implement tables, views and queries that hold the
data used and produced in the main software system;
Version used: Microsoft Office Access 2003.
• Eclipse Galileo IDE with AspectJ extension:
Used to write the aspects code.
Version used: 3.5
2.4.2. IMPLEMENTATION LIBRARIES
• Java Excel API - A Java API to read, write and modify Excel
spreadsheets:
This API allows non Windows operating systems to run pure Java
applications which can both process and deliver Excel spreadsheets.
Because it is Java, this API may be invoked from within a servlet, thus
31
giving access to Excel functionality over internet and intranet web
applications.
This library was used to import tutors, rooms and courses data from excel
sheets provided by the user.
2.4.3. FUNDAMENTAL METHODS AND FUNCTIONS Most of the program functionalities were implemented using methods of an implementation class named “Orchestration” the most significant of those are:
distributeCourseSections
This method takes the course code and applies the scheduling algorithm described in section 2.3.6.
This method returns nothing.
getAvailableRoomsAt
This method takes two numbers (integers); the first indicates the start time and the second for the duration of availability.
The method returns a group (vector) of room objects that are available at the start time and for the full duration.
distibuteCourseSectionsOverRooms
This method takes the course object and finds the available rooms for its sections.
This method returns nothing.
saveSemesterToDB
This method takes no parameters; it looks for the current semester that the program is set to work on and save its data (tutors, rooms, courses and sections) to the database.
UploadSemesterFromDB
This method takes the semester and looks the database to find all the data related to that semester (tutors, rooms, courses and sections) and loads it (create objects and set their attributes) to the program.
32
CHAPTER THREE: RESEARCH
3.1. SCHEDULING AUTOMATION: RECENT RESEARCH Although the courses scheduling automation is a classical combinatorial
optimization problem, no widely accepted model is used in the literature. The
reason behind this is that the characteristics of the problem are dependent on the
educational system and the type of institution involved. As such, although the
basic problem is the same, variations are introduced in different works.
In January 2010, a group of researchers in Brazil developed a new approach to
solving the problem of school timetabling. They report details in an issue of the
International Journal of Operational Research.
The group has developed a GRASP (i.e., Greedy Randomized Adaptive Search
Procedure) heuristic for the school timetabling problem. The approach itself, as
with any other heuristic method, is not guaranteed to find the best solution for
each case, but it does help solve the problem for Brazilian high school timetables
efficiently and quickly, given their specific requirements.
GRASP repeats a basic three-step cycle. First, it selects a random lecture and
assigns it resources, then adds the next lecture and ranks the options and so on.
The growing list of assigned lectures is sorted with those that score the highest in
terms of the different criteria moving up the priority list, this is the "greedy" part.
The addition of each subsequent lecture must then adapt to fit unless it scores
more highly than the others in which case it moves up the list. The second phase
improves the list using a "local search procedure" that compares neighboring
lectures and re-ranks them in pairs. This phase continues until no further
improvements are possible. Finally, a so-called "path-re-linking strategy" is used
to spot the almost optimum solutions, which are then used to guide the final
solution. "The basic cycle is repeated a number of times and the overall
33
champion solution are returned as the final answer of the algorithm," explain the
group of researchers.
Educational timetabling problems involve scheduling a number of "meetings" (i.e.
classes, sections, etc.) among different resources without overlapping, finding a
suitable teacher who is available to teach a certain course at a given time. Until
now, solving the school timetabling problem was done manually, or at best with
the help of a spreadsheet program. Typically, a manual solution requires expert
attention and can take many weeks for large educational establishments like
universities. Moreover, because of the problem complexity, administrators are
not always able to take the best decisions, building schedules that are
inconsistent with teaching requirements and do not satisfy all teachers' needs.
"An optimization tool could assist these planners in order to reduce the time they
need to build the timetables and to improve the quality of the solutions," the
researchers explain. The timetabling problem is defined in terms of a set of "m"
disjoint classes of students, "n" teachers, "s" subjects and "p" weekly time
periods. The latter are prefixed for each class. The tool must then find a slot for
each teacher and ensure that all students receive the requisite lectures each
week while simultaneously satisfying a complex set of constraints, like with
teachers' preferences and availability, adequate daily balancing of class subjects
and collective sport classes. Besides, time grids for different grades might also
conflict.
Problems arise since tutors usually teach more than one course; many criteria
are assigned a degree of importance. Any software should be able to pick a
given lecture and see how well it fits with the "hard" criteria and endeavors to fit it
to the "soft" criteria.
34
3.2. ASPECT ORIENTED PROGRAMMING: BACKGROUND
We know that a program must be correct and we can study it from that viewpoint
only; we also know that it should be efficient and we can study its efficiency on
another day. . . But nothing is gained on the contrary by tackling these various
aspects simultaneously. It is what I sometimes have called "the separation of
concerns." EDSGER DIJKSTRA
Aspect-oriented programming had been introduced to provide a solution to the
scattering and tangling described of code. It is a promising technique to liberate
developers from the hegemony of the dominant decomposition. Simply put, this
means that whichever modularity we choose (objects, functions, etc.) will at
some point impose some kinds of constraints on the design. In the object-
oriented methodology, the dominant decomposition is the modularity of classes,
and methods. The hegemony refers to the fact that when sticking to object-
orientation, developers are obliged to make design decisions that lead to
scattering and tangling of their code. In some cases, developers must be able to
break out of that modularity and design code that crosscuts an object model.
AOP comes along… it allows a developer to program those crosscutting portions
of the software separately from any of the structural entities. Even though in its
infancy, AOP has proven to be useful in modularizing source code and has
provided a wide range of benefits, from performance enhancement to more
evolvable code. Aspect-oriented languages provide support for programming
such crosscutting concerns, or aspects, in one place and then automatically
propagate the behavior to the many appropriate points of execution in the code.
In this sense, aspects allow a developer to specify behavior that overlays an
existing class model.
However, it is important to consider when an aspect is appropriate to be used for
some functionality. Nonetheless, aspect-orientation has been shown, when used
35
properly and appropriately, to transform necessarily cumbersome code into
something more manageable.
Simply, an aspect is a particular kind of concern. A concern is any code related
to a goal, feature, concept, or some kind of functionality. An aspect is a concern
whose functionality is triggered by other concerns, and in multiple situations. If
the concern was not separated into an aspect, its functionality would have to be
triggered explicitly within the code related to the other concern and so would
tangle the two concerns together. Moreover, because the triggering is in multiple
places, the triggers would be scattered throughout the system.
There are many examples of behavior like this indeed, any functionality that has
policies that need to be carried out in different modules of an object-oriented
code base are those likely candidates to apply the aspects to.
A typical example of using aspects is logging or tracing code, since to add tracing
code to a system, many locations must be modified, and every time the tracing
scheme is changed, all those locations have to be altered. Another example is
synchronization code, which is difficult to implement, since it requires a developer
to go back to each method to be synchronized and add the necessary locking
and unlocking code. Any code that may be needed in multiple places has the
potential to be problematic. Having a programming model that means such code
only needs to be written once and is in only one place when it requires change or
deletion provides an obvious gain for the developer.
Aspects are not just a neat way for adding logging or synchronization or other
simple functionality. Aspects are a programmatic construct; they provide active
support, not just textual code manipulation, for separating concerns in source
code. Aspects have been applied to far more complex crosscutting concerns
than synchronization, logging, and tracing. For example, they have been applied
in operating systems as a way to encapsulate and improve their performance.
36
3.3. EMPLOYING ASPECT ORIENTED PROGRAMMING As with systems in any programming paradigm, aspect-oriented systems need to
be designed with good software engineering practice. The analysis and design of
a system are as important as the implementation itself, many professionals
consider these phases to be even more important in their contribution to the
success of a project as a whole.
In any development effort, it is helpful for a developer to be able to monitor the
structure of the final implementation at all stages of the software lifecycle.
Otherwise, the developer would have to think in a different way to get from a
particular way of encoding design to another way of coding the software;
developers must be able to easily map their designs to the code in order for the
design to continue to make sense during the development lifecycle.
In addition to seamless traceability between the design and code, we also
consider the benefits of separating aspects in the. The same benefits derived at
the code level through applying aspect orientation can be derived at the design
level. In the infancy of aspect orientation, developers simply used object-oriented
methods and languages (such as standard UML) for designing their aspects.
This proved difficult because standard UML was not designed to provide
constructs to describe aspects: Trying to design aspects using object-oriented
modeling techniques proved as problematic as trying to implement aspects using
objects. Without the design constructs to separate crosscutting functionality,
similar difficulties in modularizing the designs occur, with similar maintenance
and evolution problems. We need special support for designing aspects, as we
can then improve the design process and provide better traceability to aspect-
oriented code.
A similar set of problems arises when analysing requirements documentation to
determine how to design a system. Approaches for extracting requirements from
an object-oriented perspective simply don't go far enough when trying to plan for
37
aspect orientation. Heuristics and tools to support such an examination are
helpful to the developer.
There are two ways in which a system can be designed using the aspects
orientated approach. For developers, they may choose to carry through to
implementation the separation of the design-level themes. They also need to use
a programming model that supports theme-based modularization and
composition as designed using Theme/UML. Aspect-oriented languages provide
such a model. Taking this approach yields the traceability benefits that were
previously discussed as an advantage to using the aspect orientation approach.
Alternatively, developers may implement the composed design using an object-
oriented language. It is likely that this approach would only be taken where there
is a difficulty to use an aspect-oriented programming language. The resulting
code will display the modularization characteristics, in which the themes are
integrated into the straight object model, that aspect-oriented programming has
been designed to avoid. In either case, there is language support as well as
development environments that would be helpful in implementation.
3.4. NOTES ON ASPECT ORIENTED PROGRAMMING Aspect-Oriented Software Development (AOSD) is an effective technique for
modularizing crosscutting concerns, but effective design principles are needed to
create aspect systems that support long-term maintenance and evolution.
To date, aspects have mostly been used to modularize “nonfunctional” concerns
like persistence, security, logging, caching, etc., in contrast to the domain logic,
specified by the functional requirements. Aspects for a nonfunctional concern
usually require no modifications of the target modules, because the concern’s
38
problem domain is usually orthogonal to the modules’ domains. Hence, the
advised modules are oblivious.
However, partitioning the domain logic itself into aspects is more likely to
introduce logic conflicts, since they are no longer orthogonal. Obliviousness by
itself does not address this design issue. Some aspect systems handle this
problem by composing applications from aspects, using merging heuristics to
resolve potential conflicts. However, general design principles are needed to
address this problem for all aspect systems. Also, for reasons of program
correctness, security, performance, etc., a module may need to control access to
its join points and prohibit some types of advice and introductions. Real,
successful systems evolve over time. Aspects written with early AOSD
approaches tended to be tightly coupled to the rest of the application logic,
leading to an AOSD-Evolution Paradox. While the initial version of an aspect-
based application has better modularity than a comparable object-based
implementation, tight coupling of the aspects to the rest of the application makes
evolution harder. This coupling occurs when pointcuts refer to concrete program
structure, like class and package names, that tend to be volatile. While the
advised modules are oblivious to the aspects, the aspects are not at all oblivious
to the modules they advise. This paradox has been a practical barrier to AOSD
adoption, but it can be resolved by adherence to several of the dependency
principles.
The term noninvasiveness is now used to retain the notion of advice insertion
without direct module modification, but with the recognition that techniques of
control are sometimes required and naïve obliviousness is not adequate for all
design problems. Reasoning about a module requires understanding the system
context. However, AOP makes this explicit and provides tools for modular
reasoning.
39
CHAPTER FOUR: CONCLUSIONS
4.1. PROBLEMS FACED AND LESSONS LEARNED
4.1.1. MAINTAINING MOMENTUM
Although the requirements were specified clearly in the analysis phase of the
software development cycle, some flexibility were found and led to some minor
changes in the way those requirements were to be met. On the other hand, some
new requirements were added later after the evaluation of the design phase,
there were moderate difficulties in meeting them, the key to success were to
making the software more malleable but less prone to errors.
Many difficulties were found during the development process especially
regarding timing, delays came mainly from the allocation of less time to tasks
which need plenty of time, and allocation of extra time to tasks that could be
finished in less time. This has led to iterating over each development step more
than once thus leading the developer to adopt the iterative approach to software
life cycle. This will be discussed in the introduction of the “Development” part of
this report.
4.1.2. CHANGES MADE TO THE PLAN
Changes based on the tutor’s comments:
• Comment: A complete automatic scheduling might require more then the
time given for the project. Pay attention to this issue.
Change: Defining clearly the requirements specifications and the scope
of the project so that they can be met within the project
deadlines.
40
• Comment: You need to elaborate on the problems you intend to solve in
your system.
Change: Interviews has been held with university tutors to collect more
information about the problems to be solved, these information
are then organised properly into the requirements
specifications and scope definition.
• Comment: References are not written in the standard way.
Change: Asked the supervisor about the correct way of citing references
and saw an example.
• Comment: Elaborating more on your choices of the required
software/hardware needed for the project, with justifications.
Change: investigation the available options to choose the appropriate
software/hardware requirements.
• Comment: You need to set the tasks' list with their priorities.
Change: A general list of tasks with their priorities is set; however,
prioritising tasks in detail is not possible now, since priorities emerge
through the development process.
Changes Done Based on Observation:
• Changing some of the references that were supposed to be used in the
system.
Setting up the project plan according to the software development methodology
described in the course M301 “Software Systems And Their Development”.
41
4.1.3. SKILLS NEEDED:
Skill: Problem Solving Skills
Reason: Define clearly the problem domain to invent the appropriate
to tackle it.
Skill: Logical – Analytical Skills
Reason: Analysing and developing the ideas in a logical order.
Skill: Critical thinking.
Reason: Evaluation of the available resources and facilities.
Skill: Programming skills – technical skills.
Reason: implementation of the final design of the software.
4.1.4. DEVELOPED SKILLS:
Skill: Programming skills – technical skills
Justification: these skills are essential in developing the software
especially at the implementation phase of the project
How-To: reading books on the programming language used (Java)
and looking at practical examples on how to best use this
language.
Skill: Design skills
Justification: the design stage is very important in software development,
it has influence on the whole process and determines the
success of the software.
42
How-To: getting a good understanding of the design stage in different
software development processes.
Skill: Reading skills
Justification: the time constraints to finish the project are tight, so good
reading skills is required to invest the time wisely.
How-To: reading about reading! I’ll revise the reading skills course
again and apply the right reading techniques.
4.1.5. CONDUCTING LITERATURE SEARCH
I’ve been searching through Google Scholar as well as Google, for papers books,
and other publications related to the topic of my project, I’ve found plenty of work
as well as websites of special interest groups. The choice was difficult because I
either didn’t get the full idea of the paper/book because of its complexity, or it is
very simple and intended for less professional audience which in turn proved to
be useless for my project aims. After some skimming through the books and
papers, I’ve came up with a list of useful resources for my project.
Below are the main ways that the developer used to conduct literature search
showing the advantages and disadvantages of using each:
Internet Search:
Strengths:
- Diversity of resources on available for everyone, any time and covering
many topics.
- Ease of search material needed for the project.
Weaknesses:
- Existence of many non-trustworthy contents distributed over the net.
43
Library Search:
Strengths:
- Trust-worthy contents which are intended for audience of specialised
people.
- Books are organised according to their fields.
Weaknesses:
- It is time consuming to go through an enormous number of books to
extract the necessary information
Personal Preference:
Both ways are useful under certain circumstances, the Internet provides a quick
source of information although it needs evaluation and validation, while the
library contains books on specialised topics that has a broad view on the problem
domain tackled by the project.
4.2. FUTURE WORK This project presented a certain algorithm for solving the university courses
scheduling automation problem. Experiments in real world instances showed that
the proposed method is of great use to concerned people, and it has the
advantage of a simpler design.
Contributions of this project include the customized solution to a specific real life
problem; i.e. courses scheduling automation in the Arab Open University..
Although the proposed method offers quite an improvement, future researches
may improve the algorithm itself and/or the incorporation of more requirements
and constraints can significantly improve the method usefulness.
44
REFERENCES - Santos, H. An Efficient Tabu Search Heuristic for the School Timetabling
Problem, the International Journal of Operational Research, USA, InderScience
Publishers (2010)
- Miles, R. AspectJ Cookbook, USA, O'Reilly Media (2004).
- Clarke, S. and Baniassad, E. Aspect-Oriented Analysis and Design: The Theme
Approach, USA, Addison Wesley Professional (2005).
- Wampler, D. Aspect-Oriented Design Principles: Lessons from Object-Oriented
Design, Canada, AOSD International Conference (2007).
- Kiryakov, Y. and Galletly, J. Aspect Oriented Programming – Case Study
Experiences, Bulgaria, International Conference on Computer Systems and