Faculty of Computer Studies Information Technology and...

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

Acknowledgment...................................................................................................3

Abstract.................................................................................................................4

List of Figures .......................................................................................................7

Chapter One: The Project .....................................................................................8

1.1. Introduction.................................................................................................8

1.1.2. Project Proposal ...................................................................................8

1.1.1. Project Aims .........................................................................................9

1.1.2. Project Deliverables .............................................................................9

1.1.3. Development Tools ............................................................................10

1.2. Planning....................................................................................................10

1.2.1. Approach Taken .................................................................................10

1.2.2. General Project Schedule...................................................................11

Chapter Two: Development Cycle ......................................................................12

2.1. Approach Taken .......................................................................................12

2.2. Analysis ....................................................................................................14

2.2.1. Statement of Requirements................................................................14

2.2.2. Eliciting Information ............................................................................14

2.2.3. Functional Requirements....................................................................15

2.2.4. Data Requirements ............................................................................16

2.2.5. Software/Hardware Requirements .....................................................16

2.3. Design ......................................................................................................17

2.3.1. use cases ...........................................................................................17

6

2.3.2. Classes...............................................................................................23

2.3.3. Initial Data Flow Diagram ...................................................................25

2.3.4. Object Diagram ..................................................................................26

2.3.5. Entity Relationships Diagram .............................................................27

2.3.6. the Scheduling Algorithm....................................................................28

2.4. Implementation .........................................................................................30

2.4.1. Implementation Tools: ........................................................................30

2.4.2. Implementation Libraries ....................................................................30

2.4.3. Fundamental Methods and Functions ................................................31

Chapter Three: Research ...................................................................................32

3.1. Scheduling Automation: Recent Research ...............................................32

3.2. Aspect Oriented Programming: Background ............................................34

3.3. Employing Aspect Oriented Programming................................................36

3.4. Notes on Aspect Oriented Programming ..................................................37

Chapter Four: Conclusions .................................................................................39

4.1. Problems Faced and Lessons Learned ....................................................39

4.1.1. Maintaining Momentum ......................................................................39

4.1.2. Changes Made to The Plan................................................................39

4.1.3. Skills needed: .....................................................................................41

4.1.4. Developed Skills: ................................................................................41

4.1.5. Conducting Literature Search.............................................................42

4.2. Future Work..............................................................................................43

References .........................................................................................................44

7

LIST OF FIGURES Figure 1: Use Case Diagram……………………………………………20

Figure 2: Class Diagram………………………………….……………..22

Figure 3: Initial Dataflow Diagram……………………………..……….23

Figure 4: Object Diagram………………………………………….…….24

Figure 5: Entity Relationship Diagram………………………..………..25

8

CHAPTER ONE: THE PROJECT

1.1. INTRODUCTION

1.1.2. PROJECT PROPOSAL

PROBLEM DEFINITION

The problem that the software will tackle; is how to develop a database that

contains the courses, sections, tutors, tutorial timing, class rooms, and room’s

capacity, and distribute the sections on the existing class.

On the other hand, conventional software development techniques scatter the

implementation of concerns (i.e. persistence, security, debugging, logging,

distribution, performance monitoring and exception handling).

The main problems arise when using the Object Oriented Software Development

(OOSD) are:

1- In the design stage, OOSD takes the class as the unit to model; it may not

comprehensively meet the demand of software system.

2- In the implementation stage, the encapsulation of data fields and

behaviour increases the security and modularity of the software, but

dramatically reduces the reuse of components.

The resulted system will be used in schools, universities and any other institution

that offer the class – student – tutor – room way of organisation.

SUGGESTED SOLUTION

AOSD was established to overcome the limitations of OOSD (Object Oriented

Software Development); it enhances the modularity of the software, which in turn

9

improves the expandability, reuse of code and maintenance of the software. The

suggested solution will:

1- Developed the system using the conventional OOSD approach.

2- Analyse the OO system (No. 1) and introduce aspects to improve it.

3- Implement the final design using AspectJ (an extension to Java to support

Aspects Programming).

4- Prepare a study which compares the advantages gained by using the

above approach.

5- The system itself will be used to schedule courses’ sections over existing

rooms and according to tutors’ available times

1.1.1. PROJECT AIMS

1- Develop automatic scheduling system software using the aspect oriented

approach.

2- Identify the advantages and disadvantages of using the aspect oriented

software development AOSD.

1.1.2. PROJECT DELIVERABLES

1- A complete course scheduling automation software system.

2- A comparative study on the advantages of using AOSD over the traditional

object oriented paradigm alone.

10

1.1.3. DEVELOPMENT TOOLS

• ArgoUML

The developer found this tool very useful in modelling during the software

system life cycle; use cases diagram and class diagrams were drawn using it

smoothly and in a clear coherent manner.

• Java Netbeans IDE;

Netbeans proved to be a good tool to build the software especially its GUI

builder, the tool has been developed by SUN, who also develops Java

programming language.

• Java Eclipse IDE;

Eclipse was used to add aspects using AspectJ plug-in that were developed

for it.

• AspectJ extension for Eclipse to program aspects.

AspectJ is the plug-in that is used inside Eclipse to let the developer program

aspects.

1.2. PLANNING

1.2.1. APPROACH TAKEN

The project should take no more than 6 months to be developed (including the

time spent to choose the topic), the strategy that I will follow is to divide the

project into tasks and the tasks into subtasks if applicable, the time schedule will

be divided into months and assuming that each month consists of only 3 weeks

to allocate the tasks and subtasks, this way I’ll have 7 – 10 days every month to

ensure that the tasks are met perfectly. Using the same approach, I’ll divide my

work into 5 months and leave the last month for revision and improvement.

11

1.2.2. GENERAL PROJECT SCHEDULE

Month Task Actual Date

1

Define the project in technical terms and look for the references needed to achieve the aims completely and perfectly.

Looking through the latest work done in the field of AOSD.

Arranging the reference materials and choosing the best to accompany the project stages.

October 2009

2 Analysis of the project

TMA01

November 2009

3

Design the solution

Class and interaction diagrams (UML)

TMA02

December 2009

4 Implementation

AspectJv

January - February

2010

5

Testing

Preparing the comparative study depending on the findings and observations from the

development process

TMA03

March 2010

6

Revision and improvements

Project Report

TMA04

April 2010

7 Defence May 2010

12

CHAPTER TWO: DEVELOPMENT CYCLE

2.1. APPROACH TAKEN

A life cycle describes the events and activities in the life of a software system and

the sequence in which they happen. Thus, it is possible choose how to connect

the development activities together to form a life cycle, which can then be used to

elaborate a process for developing software. The arrangement of the

development activities into a single sequence is called the classic waterfall model

for the development of software.

Even if a developer can complete each activity completely (and correctly) the

waterfall model has not proven satisfactory in practice.

If projects use a strictly sequential life cycle, a working version of the software

system will not be available until late in the testing activity, this could be

significant especially for larger projects, since it assumes that the customer is

patient and the users are not concerned about the delay required to produce a

prototype to their requirements. Moreover, any errors detected in the working

version of the software can be disastrous. Hence real projects rarely follow a

purely sequential life cycle.

An alternative is to iterate around one or more of the activities in a life cycle.

Iteration allows the developers to improve the outputs from a given set of

activities before moving on to the next activity. In particular, iteration allows a

group of people, usually developers, to perform a review of an activity or the

outputs from that activity.

In general, reviewing a proposed solution provides the feedback necessary to

modify it and improve the solution. Think what happens when you need to tune a

guitar or violin. You pluck a string, a note sounds and you adjust the tension on

that string. You repeat the process until you get the desired pitch.

13

Incremental development is another form of life cycle. Here the idea is to divide

the system into a number of independent or reasonably independent ‘chunks’.

The process begins by developing one chunk – the core – and adding

successive increments to it over time. A significant point about this method is that

the core is a functioning item of software that meets some of the requirements.

As each increment is added, the resulting software is still functional. In this way,

the users obtain useful and usable software quickly. This method also enables

the developers to take on board feedback from users as the software develops;

an increment may simply be an enhancement of the previous version.

Increments can be developed sequentially or in parallel, depending on

circumstances. For example, a small team might choose to develop increments

sequentially, according to a priority agreed with the users.

Object-oriented design is very much an iterative process, alternating between

improving the structural model and deciding on the dynamic behaviour. Thus, the

developer chose the iterative life cycle model to develop the software system.

This chapter will discuss the software development steps that lead to the

production of the final software system; first, the analysis phase is discussed in

section two, the design will be the subject of section three, the implementation

will be illustrated in section four, evidence for testing will be shown in section five.

14

2.2. ANALYSIS

2.2.1. STATEMENT OF REQUIREMENTS

“In this project you are asked to develop a complete GUI application that

automatically distributes the sections on the available class rooms. For this

project, you need first to develop a database that contains the courses, sections,

tutors, tutorial timing, class rooms, and room’s capacity. It is expected that the

application should be able to take as input an excel file that contains the section’s

name, timing and tutor name on one hand and the database about the existing

class rooms on the other hand. Based on all this information, this application

should distribute the sections on the existing class rooms by applying different

approaches (iterative, random, priorities, etc)”.

2.2.2. ELICITING INFORMATION

Many meetings were held with course coordinators to get an idea of how the

proposed system should function, the main way of eliciting information is to ask

questions, the central question was: why do you want this software system?

The questioning process took place in stages; from broad questions and going to

more specific questions through study and analysis of previous questions’

answers.

Questions were of different categories; Scoping questions were used to delineate

what facilities should be in the system and what facilities should not be included.

Questions about input data were asked to know what kind of information and

data that is to be processed by the system. Questions about output data were

asked to know what kind of data or information the system should produce.

15

Behavioural questions were asked to know what the system should do; they

ranged from broad questions to specific ones.

2.2.3. FUNCTIONAL REQUIREMENTS

The system will divide the work into two phases:

Phase One: Sections Distribution.

The average number of students in a section is 30, however, one section will be

offered if the number is up to 35 students, if the number is 36, 2 sections will be

offered, thus; the minimum number of students in a section will be 18, while the

maximum number will be 35.

After calculating the number of sections offered for the semester, half of the

sections should be offered in the morning (from 8:00 to 12:00), and the other half

in the evening (from 12:00 to 21:00), the distribution will always start from the

morning, i.e. if only one section is offered, it should be offered in the morning.

After deciding the number of morning and evening sections, they should be

distributed evenly on tutors’ available times; the user will be notified if some

sections are left without a tutor to be taught.

The result of this phase is a set of sections for each course that shows the name

of tutor, room number, number of students, and the time for each section.

Phase Two: Rooms’ Distribution

The set of sections resulted from phase one above is needed to proceed to this

phase.

The distribution will be based on the time availability of rooms

16

The end result of this phase will be a list of sections and the rooms they are

taught in, and a report that shows the sections that couldn’t be fit into one of the

rooms.

2.2.4. DATA REQUIREMENTS

• A list of tutors (excel sheet).

• A list of courses, their code and name (excel sheet).

• A list of rooms showing their codes (excel sheet).

2.2.5. SOFTWARE/HARDWARE REQUIREMENTS

Java will be used to implement the software system, after some search and

evaluation; I’ve found that the best Java IDE for me is Eclipse that can be

extended to write the code of aspects using AspectJ.

A recent PC will be enough to implement and run the software system, it should

has Windows installed with Java run time environment, although the software

itself is written in Java – which is portable – but the above requirement will be

required to implement the software.

17

2.3. DESIGN

2.3.1. USE CASES

Identifier and Name: UC_1 Add Course

Initiator: Coordinator

Goal: add a course to courses repository

Pre-condition: -

Post-condition: register the added course to courses repository

Assumptions: all the data required to add a course is met.

Main success scenario:

1 The Coordinator adds a new course

2 The system records the added course.

Identifier and Name: UC_2 Upload List of Courses


Goal: Upload List of Courses

Pre-condition: the list should be in a predefined format.

Post-condition: register the uploaded courses to courses repository

Assumptions: all the data required to add the courses is met.


1 The Coordinator uploads an excel sheet that contains data about courses.

18

2 The system records the uploaded courses.

Identifier and Name: UC_3 Add Tutor


Goal: add a tutor to the list of tutors

Pre-condition: -

Post-condition: register the added Tutor to Tutors repository

Assumptions: all the data required to add a tutor is met.


1 The Coordinator adds a new tutor

2 The system records the added tutor.

Identifier and Name: UC_4 Upload List of Tutors


Goal: Upload List of Tutors


Post-condition: register the uploaded Tutors to Tutors repository

Assumptions: all the data required to add the Tutors is met.


1 The Coordinator uploads an excel sheet that contains data about Tutors.

2 The system records the uploaded Tutors.

19

Identifier and Name: UC_5 Add Room


Goal: add a Room to Rooms repository

Pre-condition: -

Post-condition: register the added Room to Rooms repository

Assumptions: all the data required to add a Room is met.


1 The Coordinator adds a new Room

2 The system records the added Room.

Identifier and Name: UC_6 Upload List of Rooms


Goal: Upload List of Rooms


Post-condition: register the uploaded Rooms to Rooms repository

Assumptions: all the data required to add the Rooms is met.


1 The Coordinator uploads an excel sheet that contains data about Rooms.

2 The system records the uploaded Rooms.

20

Identifier and Name: UC_7 Add Section


Goal: add a Section to Sections repository

Pre-condition: -

Post-condition: register the added Section to Sections repository

Assumptions: all the data required to add a Section is met.


1 The Coordinator adds a new Section

2 The system records the added Section.

Identifier and Name: UC_8 Upload List of Sections


Goal: Upload List of Sections


Post-condition: register the uploaded Sections to Sections repository

Assumptions: all the data required to add the Sections is met.


1 The Coordinator uploads an excel sheet that contains data about Sections.

2 The system records the uploaded Sections.

21

Identifier and Name: UC_9 Distribute Sections


Goal: distribute courses’ sections over the available tutors’

times

Pre-condition: the repositories of courses, tutors should not be

empty.

Post-condition: register the scheduled Sections.

Assumptions: all the data required for tutors, courses and rooms are

filled.


1 The Coordinator requests to distribute Sections.

2 The system records the scheduled Sections and shows them to the

coordinator.

Identifier and Name: UC_10 Distribute Rooms


Goal: distribute the sections resulted in UC_9

Pre-condition: the Repository of sections and rooms should not be

empty.

Post-condition: register the Sections in their room.

Assumptions: all the data required for a room is filled.


1 The Coordinator requests to distribute Rooms.

2 The system records the distributed rooms and shows them to the coordinator.

Figure 1: Use Case Diagram 22

23

2.3.2. CLASSES

Class: Tutor

Attributes:

tutorName “The name of the tutor”

tutorCourse “the courses that the tutor teaches”

tutorAvailableTimes “the times when the tutor is available to teach the

course”

tutorSections “the courses that the tutor teaches”

Tutors “holds every tutor object created”

Class: Course

Attributes:

courseName “The name of the course”

courseCode “the code of the course”

courseStudentsNo “the number of sections needed for the course”

Class: Section

Attributes:

sectionCourse “the course taught at the section”

sectionTutor “the tutor that teaches the section”

sectionCode “the code of the section”

sectionRoom “the room where the section is taught”

Class: Room

Attributes:

roomNumber “the room number”

roomTimeTable “the timetable of the room”

Invariant 1: If s is an instance of Section that is linked to an instance t of tutor via

taughtBy, then s and t should be linked to the same instance c of Course via of

and teaches respectively.

Figure 2: Class Diagram

24

2.3.3. INITIAL DATA FLOW DIAGRAM

Add Courses Add Tutors Add Rooms

Distribute Sections

Distribute Rooms

Add Sections Store Sections

Figure 3: Initial Dataflow Diagram

25

2.3.4. OBJECT DIAGRAM

tutorName : stringtutorAvailableTimessectionstutorCourse

t : Tutor

CourseNameCourseCodeCourseStudentsNumber

c : Course

26

RoomTimeAvailabilityr : Room

sectionCodesectionTutorsectionCoursesectionRoom

s : Section

* *

*

*

*

*

* *

Figure 4: Object Diagram

2.3.5. ENTITY RELATIONSHIPS DIAGRAM

Figure 5: Entity Relationship Diagram

27

28

2.3.6. THE SCHEDULING ALGORITHM

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



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.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

Technologies (2003).

Faculty of Computer Studies Information Technology and...

Documents

Transcript of Faculty of Computer Studies Information Technology and...