Done By:: Scheduling System For CCI of HU

Scheduling system for CCI of HU
DONE BY: DEPARTMENT OF MANAGEMENT INFORMATION SYSTEM IN, 2015
NAME ID
Final project on
Scheduling System for college of computing and Informatics
1. Sileshi Negese ………………………………..........…2069/05
2. Bali Kebede…………………………………………..1807/05
3. Brtukan Moges……………………………………….1827/05
4. Simagn Nagash………………………………………..2085/02
Final project by MIS 3rdyear

Page
Acknowledgement
First of all, we would like to thank our Advisor Mulubrhan, for his restless edition of our document, input to
the quality of this document, heart full guidance, his valuable advice, and providing direction when we got
information and reading materials to execute this project.
Secondly, we would like to thank our instructor Rama A. for her partial willingness of interview, patience in
answering to our questions, giving documents and reading materials that help us to precede our project.
At the last but not the least, even if it is unusual, the group members would like to thank each other. The
main contributors to the success of this project are teamwork, friendship and the belief that we may achieve
something we set out to do. We also hope that this project and the documentation may be testaments to our
continued friendship and better work.

Page i
Abstract
Our documentation paper is used as a reference for an automation of scheduling system for college of computing and
informatics of Haramaya University. The documentation is attempted to provide full documentation of scheduling
system for the college. The documentation has four chapters. The summary of the chapter included in this document
is as follows:
Chapter one: Introduction part
This provides the general overview of scheduling system for college of computing and
informatics of Haramaya University starting from its problem statement to the designing phase,
and it is stating its tasting mechanism in order to make error free implementation in brief.
Chapter two: System Requirement Specifications and Analysis Modelling (SRS)
This chapter highlights about the requirement analysis phase. The requirement analysis phase
generally verifies the description of the existing system and also it understands the problems
under the existing system and also contains the functional and non-functional work flow of the
existing system. System models including scenario analysis and different UML diagrams.
Chapter Three: Design Document
This chapter extends the discussion specially the system and object design. And it also states the
design goals and objectives include different block diagrams that have a power means of
describing class type architecture class Diagrams, class modelling diagrams, data modelling
diagrams, sequence diagrams, collaboration diagrams, user interface design, state chart diagram,
persistent modelling, entity relationship diagram modelling, component diagram and deployment
diagram.
Chapter Four: Implementation Document
This chapter illustrates the implementation and testing of the concepts introduced in chapter two
and chapter three. And it gives the full Skeleton of the project. At the end it includes conclusion
and recommendation given to the college.

Page ii
Table of contents
Contents Page
Acknowledgement…………………………………………………………………………..……………………..……I
Abstract……………………………………………………………………………………………………………..…..II
Table of contents …………………………………………………………………………………………………..….III
Chapter One……………………………………………………………………………………………………….……1
Introduction………………………………………………………………………………………………………..…....1
1.2 Back ground of an organization………………………………………………………………………………….....1
1.3 Statement of the problem………………………………………………………………………………………...…2
1.4 Objectives of the project…………………………………………………………………………………………....2
1.4.1 General objective…………………………………………………………………………………...…2
1.4.2 Specific objectives………………………………………………………........................................…2
1.5 Methodology of the project…………………………………………………………..…………………………..…3
1.5.1 Data source…………………………………………………………….….…………………………..3
1.5.2 Method of data collection…................................................................................................................3
1.6 Scope of the project……………………………………………………………………………………..…………..3
1.7 Significance of the project…....................................................................................................................................3
1.8 Feasibility assessment………………………………………………………………………………………..……..4
1.8.1 Economic feasibility……………………………………………………………………………..…..…4
1.8.2 Technical feasibility……………………………………………………………………………………4
1.8.3 Operational feasibility………………………………………………………………………………….4
1.8.4 Schedule feasibility……………………………………………………………………………....…….5
1.9 Management Issues…………………………………………………………………………………..………….….5
1.9.1 Team configuration………………………………………………………………………….………..5
1.9.2 Communication plan…………………………………………………………………………….…...6
1.9.3 Change Management…………………………………………………………………………..……...6
1.10 Required Tools…………………………………………………………………………………………….....……6
Chapter Two……………………………………………………………………………………………………..…..….7
2. System Requirement Specifications and Analysis Modelling (SRS)………………….………………………….…7
2.1 Introduction……………………………………………………………………………………………………..…..7
2.2 Class responsibility collaboration (CRC)………………………………………….……………………………..…7
2.3 Use case modelling………………………………………………………………………………………………....8
2.3.1 Essential use case modelling…………………………………………………………………..….…8
2.3.2 System use case modelling…………………………………………………………………..……..11
2.4 User interface prototyping……………………………………………………………………………………..…..17
2.5 Supplementary specification………………………………………………………………………………………21
2.5.1 Business rules………………………………………………………………………………………21
2.5.2 Non-functional requirements………………………………………...………………………….…22
2.5.3 Constraints………………………………………………………………………..………………………………………..…….....…22
2.6 Activity Diagrams…………………………………………………………………………………………….…...23
Chapter Three………………………………………………………………………………………..………….……..26
Page iii
3. Design document………………………………………………………………………………………………....…26
3.1 Class Modelling…………………………………………………………………………………………………...26
3.1.1 Class diagrams……………………………………………………….............................................26
3.1.2 Data modelling………………………………………………………………………………...…....27
3.2 Sequence diagram………………………………………………………………………………………………....28
3.3 Collaboration diagram………………………………………………………………………………………..……31
3.4 User interface design……………………………………………………………………………………………....32
3.5 State chart diagram…………………………………………………………………………………………..…….35
3.6 persistent modelling………………………………………………………………….…………………………....37
3.6. 1 Entity relationship diagram…………………………………..………..…………………….……....38
3.7 Component diagram…………………………………………………………………………………………….....39
3.8 Deployment diagram……………………………………………………………………………………………....40
Chapter four…………………………………………………………………………………………………………...41
4. Implementation………………………………………………………………………………………………..........41
4.1 User manuals……………………………………………………………………………………………………...41
4.2 Sample codes………………………………………………………………………………………………………45
4.3 Recommendation……………………………………………………………………………………..……………50
Reference……………………………………………………………………………………………………………....51

Page iv
Chapter One
1.1 Introduction
Now we are in technological century. With new day, new generation with new idea and creativity in the existed
world is born daily. The advancement of computer is enabling us to speak about technology. The evolution of
computer comes up with intelligent technology. One of the remarkable and much known products of technology
advancement is the Conversion of manually system into automated system. Automation produces a great impact in
the lives of man, particularly in the field of industry, business, medicine, and Education.
It is a fact that arrangingschedules, instructor’s loadandroom utilization for the Students and faculty in every
department is one of the many activities that each department scheduler must prepare before classes start. But the
college use the manual way of preparing the schedule. With the manual system, more time and labour force is
required to plot, arrange, and revise the class schedules, room utilization and instructors’ load provided by the
department staff. Scheduling system allow managers to monitor and maximize labour resources. With all of the tasks
managers are required to perform, any tools which expedite and ease those duties are welcome. It also provides
adverse range of functions which attempt to do precisely. It produces reports to show student time tables and teacher
time tables. It also stores schedule information for department, batch, semester, year, teachers, classrooms, day, and
time.
1.2 Background of the college of computing and informatics
It is known that Haramaya University works around three main goals- teaching, research and community
engagement. Research, although categorized one of the separate objectives of the university, is found also integrated
both in the teaching and community engagement. No research is meaningful without the application of Statistics and
that is why all departments give at least one common course in statistics for their students. As the level of the
research done get complex statistical knowledge gained through common course only fails to be sufficient. With the
advancement of information age and computer technology, it was also found important to have all the students of all
the departments to be computer literate. That is also why computer application is given as a common course in all
departments of Haramaya University. Still as the level of complexity of information processing increases, the
knowledge gained through computer applications fails to be sufficient.
Besides its objectives of teaching, research and community engagement Haramaya University needed statistical and
information technology (or Computer Sciences) for its own business. It was the time that the Business Process Re-
engineering (BPR) was started to be studied and being implemented both in the country and the university. The
university thus needed a unit that helps the university research system and administration both in terms of statistical
analysis and information technology solutions.

Page 1
The foundation of the College of Computing and Informatics was thus based on the above premises. In its original
intention “computing” refers to statistics while “informatics” is for computer sciences fields. The college was
established in April 2008 by bringing together the three departments- Computer Science, Management Information
System http://gib.haramaya.edu/academics/college-of-computing-and-informatics/s and Information Studies that
were established under the Faculty of Business and Economics.
Soon after the establishment of the college, the curricula for the departments of Information Systems and Statistics
were prepared and got approved by the university senate. Hearing the approval of the curriculum of the Bachelor of
Science in Statistics, all the students who were already admitted to the Department of Applied Mathematics and
Statistics under the then Faculty of Education requested the university management and transferred to the
Department of Statistics that was newly established under CCI. The first batch of the B. Sc in Information Systems
was, however, admitted in the next academic year. The college then opened further B. Sc programs in Information
Technology and Software Engineering based on the need assessments made at national level.
1.3 Statement of problem

For an organization to be successful in its activities the need for well-structured system and placing the right
schedule in the right time is necessary. So doing this manually, it makes difficult to accomplish tasks easily and
effectively. So, we have identified the existing system and got the main problems which exist in the college of
computing and informatics.
The main problem of this college is lack of an automated scheduling system. This leads to the following problems:
 Time consuming: - wasting time occurs when scheduler arrange timetable using manual system. They be careful in
arrange the time table to decrease the mistake probability so they need a lot of time to arrange the time table.
 Lack of Information distribution method: - The information distribution method is very slow. Since information
transformation is paper based. The prepared schedule didn’t reach at right time to the student as well as to the
Instructor, also they didn’t gate everywhere they want. Also the distributed information is inefficient.
 It is difficult to update:-to update only one entry of the table you must change schedule that you print before. This
needs to replace the original paper by the new updated one this consume additional resource and assign additional
work for the person who post the schedule on the board and give for the instructors.
 There are clash of class schedule: - there are class overlapping problem.
1.4Objectives of the project

1.4.1 General Objective
The general objective of our project is to develop an automated scheduling system for the college of computing and
informatics of Haramaya University.
1.4.2 Specific objective
 To generate class and exam schedule: - specifically our system develop automated schedule.
 To update and delete course, instructor, student, information:- this done by administrator.
 To secure data of the college:-this system gives some privileges for authorized users to get it.
 To manage the information in database:-all information like admin, student, available room and time table in
database can be added updated deleted and printed.

Page 2
1.5 Methodology of the project

In order to accomplish the project, the system requirement we will follow methods, tools, and techniques as
mentioned below.
1.5.1 Data source
The main source of our data is primary source that got from interview and observation. Also as a secondary source
we use manually prepared scheduling system.
1.5.2 Method of data collection

We gather information from different department of college of computing and informatics through direct observation
and interviewing the staff departments.
Interview: This is one of data collection method that enables to gather information from the organization directly in
the form of asking question and getting answers for those questions. So, we have used this method to gather
information by asking the head and staff of CCI some basic questions.
Interviewed questions: -
 How scheduling system is going on?
 During scheduling time, are there any problems? If there, what are they?
 What requirements are needed for the process?
 Who is responsible for what?
 How these big organizations lack an automated scheduling system till now?
Observation: This is also another data collecting method. In fact we have also used this observation method to
gather data. This method enables us observing and understanding how the schedule is done.
1.6 Scope of the project
Haramaya University has more than nine colleges and under these colleges there are many departments. All
departments have their own class schedule based on the resource they have like classrooms and human power. Due
to time and other constraints we are limited the scope of our project to automate the scheduling system for college of
computing and informatics of Haramaya University. Our project scope is further limited to:
 Accept courses information (course name, credit hours, instructor name, etc.)
 Record all available resources like buildings, rooms, labs, instructors, sections, etc.
 Update the prepared schedule without overlapping.
 Easily search and print the information.
1.7Significance of the project

The project has many significant for us and for the users of the systems. The team members will get the knowledge
and experience on how to develop and design a new system. The students will get automate scheduling system online
and also others can use the new system for future automation of other colleges of the university.
Page 3
1.8 Feasibility assessment

The attainable and unattainable of the project is determined by feasibility study. The feasibility of the project should
pass through the following feasibility ground.
1.8.1 Economic Feasibility

The purpose of economic feasibility is to identify the financial benefits and costs associated with development of the
project.
A. Tangible Benefits: - Benefits that are easily quantified from the conducted system are:
 Fastest processing time and reduced processing error.
 Small response time and many services
 Easy and fast file management.
 Reduce cost for manual data management (Reduced expenses)
 Easy update & retrieval on stored records
B. Intangible Benefits: -Benefits from the system that areas unquantifiable are;
 Better decision making
 Better service to the office
 Little job burden to employees of office
1.8.2 Technical feasibility
Specific technical solution and the availability of technical resources are measured by technical visibility.
 Whether the proposed system is easily applied by the college or not,
 The required technology for new system,
 The skill of the team to apply the new system is considered under the technical feasibility.
By using the different techniques, we can perform the work up to the desire of the organization, even though
fulfilling human being’s need in all direction may be difficulty and impossible.
Therefore, the college has enough capability to be easily applied the proposed system and the technology is able to
handle new report and forms required of the new system. Because of this the project is technically feasible.
1.8.3 Operational feasibility
Whether the proposed solution workable in CCI college or not is measured by this feasibility. We perform the
activity firstly by having the understanding of main problem manual system have and we taught changing this
manual system to somehow an automating manner is the best thing and depending on this, the project result is
operational since it solves their problem. And to make the workers familiar with the technology, we will give the

Page 4
training for about the system to the working place. So that, the system users can themselves run and operate with the
system then after.
1.8.4 Schedule feasibility
The schedule feasibility involves how much time is available to build the new system, when it can be built
interference with normal business operation etc. The schedule for this project is feasible due to rich information
exchange between the college and the developing team.
In addition to the time set to develop the system is enough to complete the project on time.
Scheduling feasibility using Gant chart:
No. Task name Start Finish Durati 2007

on Nov 25 Dec 7 Dec8Dec30Jan1 Jan30 Mar1Mar30
1 Proposal 25/11/20 7/11/2014 12d
14
2 System 8/11/201 8/12/2014 30d
requirement 4
and analysis
modelling
3 Design 1/1/2014 30/1/2014 30d
document
4 Implementatio 1/3/2014 30/3/2014 30d
n
Table 1.1 schedule feasibility table
1.9 Management issues

1.9.1 Team configuration
Team configuration and management provides a description of our team member roles and reporting relationships.
Our team has four (4) members for the accomplishment of the project to automate scheduling system.
The table below shows the way of work break down structure of our project and how we manage our time and cost.
But, all of our members have a responsibility to participate and do any task. Then task assigned to individual will not
do by him/her.
Name Responsibility
SileshiNegese  Project manager
 Programmer
Bali Kebede  Analyst
 Assistance programmer
BrtukanMoges  Secretary
 Coordinator
SimagnNegash  Designer
 Assistance coordinator
Table 1.2 team configuration table
1.9.2 Communication plan

Page 5
For the successful accomplishment of our project we have the rules and procedures we should have to follow. We
agree that all our team members should meet five times weekly and we should meet our advisor at least one times per
week.
1.9.3 Change Management
We are made our team configuration based on our interest. So, we forward our project by helping and discussing
with each other and solving difficulties encountered us in our activities.
1.10 System development tools

 Window 7 operating system
 Wampserver
 Micro soft office word 2010
 Micro soft Visio 2013
 Language php

Page 6
Chapter Two
2. System Requirement Specifications and Analysis Modeling (SRS)
2.1 Introduction
Requirement Specification is a document that is clearly describes each of the essential requirements the software and
the external interfaces such as functions, performance, design constraints, quality attributes. Each requirement is
defined in such a way that its achievement is capable of being objectively verified by a prescribed method.
Requirement analysis is the process of studying and analyzing the customer and the user needs to arrive at a
definition of software requirements.
The College of Computing and Informatics in Haramaya University runs various programs that use scheduling. This
system is handled in a manual system thus creating a lot of problems for the office that made it function
ineffectively.
2.2 Class responsibility collaboration (CRC)

A CRC model is a collection of CRC cards that represent whole or part of an application or problem domain. The
most common use for CRC models, the one that this white paper addresses, is to gather and define the user
requirements for an object-oriented application. CRC modelling is an effective, low-tech method for developers and
users to work closely together to identify and understand business requirements. A class will have a responsibility to
fulfil, but will not have enough information to do it. When this happens it has to collaborate with other classes to get
the job done.

Page 7
Figure 2.1 CRC model for scheduling system

The student should know the course they take and in what credit hour they take. They attend class regularly. The
instructor should know the class they teach course. Then the learning and teaching process takes place regularly.
2.3 Use case modeling

Use case is a pattern of behavior that the new system is required to exhibit. It is a sequence of related actions
performed by an actor and the system via a dialogue. Actor is anything that needs to interact with the system such as
a person, a role, another external system etc.
A use case model is composed of a use case diagram and the accompanying documentation describing the use cases,
actors, and associations. It is used to model behavioral requirements. It is intended to capture the essence of problems
through technology free, idealized and abstract descriptions.
2.3.1 Essential use case modeling
An essential use case model often referred to as a business or abstract use case model, models a technology-
independent view of your behavioral requirements. Essential modeling is a fundamental aspect of usage-centered.
Essential models are intended to capture the essence of problems through technology-free, idealized, and abstract
descriptions. The resulting design models are more flexible, leaving more options open and more readily
accommodating changes in technology. Essential models are more robust than concrete representations simply
because they are more likely to remain valid in the face of changing requirements and changing implementation

Page 8
technology. Essential models of usage highlight purpose, what it is that users are trying to accomplish, and why they
are doing it. In short, essential models are ideal artifacts to capture the requirements for your system.
Figure 2.2 essential use cases for scheduling system.
Description for essential use case
Attend class
Identifier:EUC1
Precondition:student should be the legal member of the class.
Post condition: follow teacher
Actor Response
Student Verifies the legality through BR10 to attend the class. Table 2.1 essential
Instructor Instruct class according to BR1, 2, 3. use case description
attends class
Administrator Arrange classes according to BR4, 5, 6, 7,8

Page 9
Teach student
Identifier: EUC2
Precondition:the instructor should be assigned by the college.
Post condition:teach students
Actors Responsibility
Instructor Instruct the classes through BR1,3
Student The student should be attending the class through BR2, 4, 5, 10.
Table 2.2 essential use case descriptions for teach student.
View schedule
Identifier: EUC3
Precondition:Has an interest to view schedule.
Post condition:Know the schedule.
Instructor View schedule to verify whether it fulfill BR5, 6, 8, 9 and use it.
Student Identify whether the schedule verifies BR5, 7.
Table 2.3essential use case descriptions for view schedule.
Arrange schedule
Identifier: EUC4
Precondition: Theuser should be an authorized user.
Post condition: The schedule is generated.
Administrator Arrange schedule through BR1-BR10.
Table 2.4essential use case descriptions for arrange schedule.
2.3.2 System use case modeling

Page 10
System use case is use case that brings technological concerns into account. System use cases are the primary
requirements artifact for the rational unified process (RUP) (Kruchten 2000), although they are arguably analysis and
perhaps even design artifacts. A system use case model is similar to an essential use case model. A system use case
model is composed of a use case diagram and the accompanying documentation describing the use cases, actors, and
associations. The following diagram shows system use case for scheduling system of the college of computing and
informatics.
Figure 2.3 System use case diagram of class and exam schedule for college of computing and
informatics

Page 11
System use case description

Documentation for login use case
Use case name: Login
Identifier: UC1
Actors: Administrator, instructor and student
Precondition: The users must be an authorized user who has username and password.
Description: When user enters username and password, it checks the input from the database.
If it is valid, it allows the user to access and if not it display unauthorized
message.
Basic course of action: 1. The use case is initiated when the user click on the login link.
2. The systems display the login forms.
3. The user enter the Username and password
4. The user click login button.
5. The systems verify whether the user is authorized or not.
5. The system display appropriate page.
Alternative course of action: 4.1 If the user does not fill the appropriate username and password, Then the
systems display error message.
4.2 Goes to step 3.
Post condition: The user access the system.
Table2.5 System use case documentation for login use case.

Page 12
Use case description for generate

Use case name: Generate schedule
Identifier: UC2
Actor: Administrator
Precondition: The user must be an authorized who has a username and password.
Description: The scheduler create schedule for students and instructor for the
learning process.
Basic course of action: 1The administrator clicks on admin login.

2. The system displays login form
3. The administrator enters username and password.
4. The administrator clicks login button.
5. The system verifies whether the user is authorized or not.
6. The system displays the scheduler page.
7. The administrator click on class or exam schedule.
8. The system displays the schedule form.
9. The administrator fills the scheduling form.
10. The administrator clicks on create button.
11. The system verifies the entry.
12. The system generates the schedule.
13. The use case ends.
Alternative course of A4.1 f the user does not an authorised user the system display error
action: messages.
A4.2 Return to step 3.
B10.1 If the user does not fill the form the system display error
message.
B10.2 Return to step 9.
B10.3 The use case ends.
Post condition: The system creates the schedule.
Table2.6 System use case documentation for generate schedule use case

Page 13
Use case documentation for update schedule

Use case name: Update schedule
Identifier: UC3
Precondition: The user must be an authorized who has user name and
password.
Description: The schedule should be updated with time.
Basic course of action: 1. The use case starts after the scheduling is done.
2. The system prompts the user to enter user name and
password.
3. The user enters the necessary information.
4. The system display validates the user.
5. The system displays update page.
6. The user fills up the information.
7. The user press update button.
8. The system validates the entry.
9. The system changes the schedule.
10. The use case ends.
Alternative course of action: A4.1If username and password are not valid.
A4.2 Return to step 3.
A4.3 The use case ends.
B7.1 If the inputs areinvalids the system display error
message.
B7.2 Return to step 6.
B7.3 The use case ends
Post condition: The user views the updated schedule.
Table2.7 System use case documentation for update schedule use case.
Documentation for delete use case

Page 14
Use case name: Delete schedule

Identifier: UC5
Precondition: The user must be an authorized and login into the system.
Description: The administrator wantstodeleteinserted information to update, or for
other purposes.
Basic course of action: 1. The use case initiated when an administrator wants to delete the
schedule and the user account.
2. The user login into the system
3. They enter the username and password.
4. The system verifies whether the user is authorized or not.
5. The system display scheduler page.
6. The user click delete link.
7. The user deletes the schedule or user account.
8. The user click delete button.
9. The system verify the entry
10. The schedule or user account is deleted.
11. The use case end.
Alternative course of 4.1 If the user does not an authorised user the system display error
action: messages.
4.2 Return to step 3.
4.3 If the user does not fill the form the system display error message.
4.4 The use case ends.
Post condition: The system deletes the schedule or user account.
Table2.9 System use case documentation for delete schedule use case.
Table2.11 System use case documentation for register use case.
Documentation for register use case

Use case name: Register
Identifier: UC7
Actors: Administrator.
Precondition: The user should be the legal member of the college and known by administrator.
Description: The other administrators added by the previous administrator.
Basic course of action:
1. The use case starts after the scheduling is done
2. Administrator login into the system.
3. The administrator clicks on add administrator.
4. The system display registration form.
5. Then fill necessary information.
6. Then save information.
7. End use case.
Alternative course of action:
2.1 If the user name and password are not valid.
2.2 Go step 2.
2.3 End use case.
Page 15
Post condition: The user’s information is saved to the system.
2.4User interface prototyping
User interface (UI) prototyping is an iterative analysis technique in which users are actively involved in the mocking-
up of the UI for a system. UI prototypes have several purposes:
As an analysis artifact that enables you to explore the problem space with your stakeholders. As a design artifact that
enable us to explore the solution space of our system. A vehicle for us to communicate the possible UI design(s) of
our system.
A potential foundation from which to continue developing the system (if you intend to throw the prototype away
and start over from scratch then you don't need to invest the time writing quality code for your prototype).
It describes the logical characteristics of each interface between the system and the users. This may include
graphical user interface standards or product family style guides, screen layout constraints and standard. The user
interface consists of a set of menus through which the user can interact with data on the scheduling system database
server. These menus include home, schedule, contact us, about us, administrator login, help menu will be linked to
some page to perform a specified task. The user will interact with these menus through the pressing menus.

Page 16
Figure 2.4 Main user interfaces of college of computing and informatics of exam and class scheduling system

Page 17
Login form user interface prototyping
Figure 2.5 login user interface prototype
Teacher entry user interface prototyping
Fig 2.6 teacher entry user interface prototype.

Page 18
Add class schedule user interface prototype
Figure 2.7 add class schedule user interface prototyping

Page 19
Data Flow Diagram

A Data Flow Diagram (DFD) is a graphical representation of the "flow" of data through an information system,
modeling its process aspects. ADFD is often used as a preliminary step to create an overview of the system, which
can later be elaborated.
Figure 2.8 Data flow diagram for scheduling system of CCI of Haramaya University

Page 20
2.5 Supplementary specification

2.5.1 Business Rules
A business rule is a rule of a business, company, or corporation. It is a rule that defines or constrains some aspect of
business and always resolves to either true or false. Business rules are intended to assert business structure or to
control or influence the behaviour of the business. Business rules describe the operations, definitions and constraints
that apply to an organization. Business rules can apply to people, processes, corporate behaviour and computing
systems in an organization, and are put in place to help the organization achieve its goals.
 Course is a series of lectures or labs offered by a department.
 Section is an instance of a course taught by one instructor.
 Timeslot is a unit of 1hr-3hr period of time.
 Class is a section of a course + an instructor + a classroom + a set of Timeslots.
 Class day a class can meet on Monday-Saturday a single weekday or combination.
 Class length the total minutes each class meeting.
 Schedule or timetable is a timed plan of classes.
 Exclusive courses two courses are exclusive if sections of one course cannot be scheduled in
timeslots that are overlapped with sections of the other course so students can enrol both at the same
time.
 Combined classes are classes of the same or different departments can be combined with an
identical schedule (i.e., same room, day/time, and instructor) in a given semester.
 User’s class scheduling system distinguishes three types of users: Administrator who create classes
and their schedules; and faculty users (students and instructor) who can only view schedules and
give comment.
Ten common rules and constraints of the college associated with different resources:
BR1. Instructor cannot teach more than one class at the same time.
BR2. Classes can meet more than once in a day as long as their time is not
overlapped.
BR3. A class is taught by one and only one instructor.
BR4. A class may use more than one classroom, but only one classroom at
a time.
BR5. No classes share a classroom at the same time.
BR6. Exclusive classes must not be scheduled with overlapping time.
BR7. Combined class always have identical schedule (i.e., room,
day/time, and Instructor.)
BR8. A class can only be scheduled with a length of 1hr -3hr
BR9. Timeslots can be scheduled for classes only if they are already
allocated to department.

Page 21
BR10. Only legal student attend the class.
2.5.2 Non-functional requirements

Non-functional requirements place restrictions on the product being developed, the development process, and specify
external constraints that the product must meet. This requirement considers only the front end values rather than
values that have relation with the database. Now here non-functional requirements according to this system are
described:
I. Design Constraints
The system shall be prepared related to user can uses the systems standards.
II. Performance requirement
To satisfy the interesting we have built the College Scheduling System at Haramaya University. It has been used by
six departments within one college schools of the university to support about classes per semester using 6 rooms in
one building. The system is modelled in the Unified modelling Language and implemented using Visual basic
language. Although Particular algorithms were adopted in its current version to automate the timetable generation
delivers many advantages to the user.
High availability: It provides on-line access via user friendly forms and reports.
Sharable information: Schools and departments and all faculty members can concurrently access the same
scheduling information from their own computers.
Transparent updates: Every schedule change, no matter who, when, and what is made is immediately visible
to all online users.
Error-proof output: Illegal scheduling process and data are always rejected because of the embedded
scheduling rules. No single piece of data, except the login name and password, needs to be typed by the user
only clicking on the desired data value.
III. Security requirement
Obviously today’s project requires security, for the sake of free from the attack, also we use security system for our
project. The security system that we use is session to return null when the request is empty and also check whether
the user is authenticated or not.
Based on different scheduling roles and responsibilities, users are granted with different permissions. For example,
an instructor cannot update change his time table the only chance is writing comment to the system and also the
students and other end user cannot modify or change the schedule created but the permission of deleting and
updating given to the scheduler.
2.5.3 Constraints
We can consider constraints in two ways. These are hard constraint and soft constraint.
A. Hard constraint
During system requirements the hard constraints encountered us are the following.
 meeting pattern specification;
 prohibited or required times for classes;
 class requires room with sufficient seating capacity;
 class requires or prohibits some building(s) or room(s);

Page 22
 class requires or prohibits classroom of a specified generic type (computer, computer projection,
audio recording, document camera, . . . );
 classes taught by the same instructor overlap;
 sections of the same course overlap;
 Additional constraints over selected sets of classes: classes must be taught at the same times, on
the same days, in the same class rooms.
B. Soft constraint
Two of requirements are encountered us as a soft constraints. These are:
 Unary constraints on time variables—faculty time preferences;
 Unary constraints on classroom variables—faculty preferences on the class-room selection for
classes.
Instructors may specify preferences for the days, hours, or parts of days they wish to encourage or discourage. This
specification is transformed into a list of integer preferences corresponding to the possible start time of each class.
We have seen that the initial selection of start times for each class is determined by its meeting pattern. The domain
size of this set of start times can differ greatly among meeting patterns. This causes the relative effect of any given
preference to vary greatly among the meeting patterns. To compensate for this effect, the number of preference
points associated with instructor time preferences differs based on the meeting pattern. Each class is associated with
a time preference variable with preferences initialized either as specified by the instructor or to a set of default
preferences. These default preferences are very important; their exclusion would lead to the construction of
timetables which discriminate against classes for which no preferences have been provided. Many such classes
would be placed in undesirable times, which no human timetable would want to do. Instructors may also specify
positive or negative preferences towards the room selection for each class. It is possible to prefer or discourage
particular Classrooms, buildings, or properties of the room. Each value in the domain of the classroom preference
variable has either the specified preference or the neutral preference specification.
2.6 Activity Diagram
Activity diagrams are typically used for business process modeling, for modeling the logic captured by a single
use case or usage scenario, or for modeling the detailed logic of a business rule. Although activity diagrams could
potentially model the internal logic of a complex operation it would be far better to simply rewrite the operation so
that it is simple enough that you do not require an activity diagram. In many ways activity diagrams are the object-
oriented equivalent of flowcharts and DFD from structured development.

Page 23
Activity diagram for login
Figure2.9 Login activity diagram
Activity diagram for updating information

Page 24
Figure 2.11updating activity diagrams
The following diagram is the overall activity diagram for CCI scheduling system.

Page 25
Figure 2.12 Overall activity diagrams for scheduling system
Chapter Three
3 Design Document
The analysis and design are highly interrelated and iterative. The transformation system from model analyses is
designing the system. The main purpose of designing document is to determine how we are going to build our
system. In this chapter we focused on designing the scheduling system for college of computing and informatics. A
well designed document makes our implementation simple and easy. In this chapter we are going to see different
modeling like class modeling, sequence diagram, collaboration diagram, user interface design, state chart diagram,
persistent modeling, component diagram and deployment diagram.
3.1 Class modeling

3.1.1 Class diagrams
Class diagrams are the most common diagram found in modelling object-oriented systems. A class diagram shows a
set of classes, interfaces, and collaborations and their relationships.
We use class diagrams to model the static design view of a system. For the most part, this involves modeling the
vocabulary of the system, modeling collaborations, or modeling schemas. Class diagrams are also the foundation for
a couple of related diagrams: component diagrams and deployment diagrams.

Page 26
Figure 3.1 Class diagram for scheduling system of CCI.
3.1.2 Data modeling
Data modelling isthe act of exploring data-oriented structures. Like other modelling artefacts, data models are
used for a variety of purposes, from conceptual models to physical design models .Logical data models are used to
explore domain concepts and their relationships. This could be done for the scope of a single project or for your
entire enterprise. From the point of view of an object-oriented developer, data modelling is conceptually similar to
class modelling. With data modelling, you identify data entities and assign data attributes to them, whereas with class
modelling you identify classes and assign responsibilities to them. There are associations between entities; similar to
the associations between class’s relationships, inheritance, and composition are all applicable concepts in data
modelling.

Page 27
Figure 3.3 Data modeling diagram
3.2 Sequence Diagram

A sequence diagram is unified modeling language (UML) diagram that models the sequential logic, in effect the time
ordering of messages between classifiers. This diagram is the mainstay of dynamic modeling; it is often used as a
bridge between usage requirements and detailed structural designs. It is interaction diagram that shows how
processes operate with one another and in what order. It is a construct of a Message Sequence Chart. A sequence
diagram shows object interactions arranged in time sequence. It depicts the objects and classes involved in the
scenario and the sequence of messages exchanged between the objects needed to carry out the functionality of the
scenario. Sequence diagrams typically (but not always), are associated with use case realizations in the Logical View
of the system under development. A sequence diagram shows, as parallel vertical lines (lifelines), different processes
or objects that live simultaneously, and, as horizontal arrows, the messages exchanged between them, in the order in
which they occur. This allows the specification of simple runtime scenarios in a graphical manner.
The followings are sequence diagrams for activities takes place in scheduling system.

Page 28
Figure 3.4 sequence diagrams for login.
Figure 3.5 Sequence diagram for generate schedule.

Page 29
Figure 3.6 Sequence diagrams for update schedule.

Page 30
3.3 collaboration diagram

A collaboration diagram describes interactions among objects in terms of sequenced messages. Collaboration
diagrams represent a combination of information taken from class, sequence, and use case diagrams describing both
the static structure and dynamic behavior of a system. Collaboration diagrams show interaction without the time
dimension, but do include object links. It captures more directly the interactions between actors and objects.
Collaboration diagram for login into the system.
Figure 3.7 collaboration diagrams for login.

Page 31
3.4 User interface design

User interface is the space where interactions between humans and machines occur. The goal of this interaction is to
allow effective operation and control of the machine from the human end, whilst the machine simultaneously feeds
back information that aids the operator’s decision making process. The aim of user interface design is to make the
user's interaction as simple and efficient as possible, in terms of accomplishing user goals—what is often called user-
centered design. Good user interface design facilitates finishing the task at hand without drawing unnecessary
attention to it. User interface design has its own steps. This step is summarized by the diagram below.
Login user interface form design is looks like below:

Page 32
Figure 3.9 login form user interface design.

Page 33
Figure 3.10 Teacher registration userinterfacedesign.

Page 34
Figure 3.11Display schedule user interface.

Page 35
3.5 State chart diagram

A state diagram is a diagram used to describe the behavior of a system considering all the possible states of an object
when an event occurs. This behavior is represented and analyzed in a series of events that occur in one or more
possible states. Each diagram represents objects and tracks the various states of these objects throughout the system.
Below are state chart diagram for view added schedule which is occurred during using our system.
Figure 3.12 State diagram for generate schedule

Page 36
Figure 3.13 State diagrams for update schedule.

Page 37
3.6 persistent modeling/ database design

Databases are programs that allow for the storage and retrieval of large quantities of related data. Databases consist
of tables that contain data. When we creating a database we should think about what tables we are going to create
and what relationships exist between the data in our tables. In other words, we have to think about the design of our
database. A good database design will ensure the integrity and maintainability of our data.
The relational model is a model that describes how to organize data into tables and how to define relationships
between these tables. The following are relational database models for class and exam schedule of college of
computing and informatics of Haramaya University.
Figure 3.16Persistent database diagrams for class schedule and exam schedule.

Page 38
3.6.1 Entity relationship (E-R) diagram or model

Entity relationship model is a graphical representation of entities and their relationships to each other, typically used
in computing in regard to the organization of data within databases or information systems. An entity is a piece of
data-an object or concept about which data is stored. A relationship is how the data is shared between entities.
There are three basic elements in entity relationship diagram:
 Entities are the "things" for which we want to store information. An entity is a person, place, thing or event.
 Attributes are the data we want to collect for an entity.
 Relationships describe the relations between the entities.
We have six entities and eleven key attributes and different derived attributes.
Figure 3.17Entity relationship diagrams for both class schedule and exam schedule.

Page 39
3.7 Component diagram

A component is a functionally independent part of any system. It performs some function and may require some
input or produce some output. A component in software is often represented by classes. In the Unified Modeling
Language a component diagram depicts how components are wired together to form larger components and or
software systems. They are used to illustrate the structure of arbitrarily complex systems.
The following diagram shows component diagram for scheduling system of college of computing and informatics.
Figure 3.18Component diagram for scheduling system for CCI of Haramaya University

Page 40
3.8 Deployment diagram

A deployment diagram in the Unified Modeling Language models the physical deployment of artifacts on nodes. The
nodes appear as boxes, and the artifacts allocated to each node appear as rectangles within the boxes. Nodes may
have sub nodes, which appear as nested boxes. A single node in a deployment diagram may conceptually represent
multiple physical nodes, such as a cluster of database servers. Nodes are device node which is physical computing
resources with processing memory and services to execute software like computers and execution environment
node is a software computing resource that runs within an outer node and which itself provides a service to host and
execute other executable software elements. The deployment diagram for our system is as follows.
Figure 3.19deployment diagram of class and exam schedule for CCI of Haramaya University

Page 41
Chapter four
Implementation
4.1 User manuals

Page 42
To view schedule click on Department year and semester

Page 43

Page 44

Page 45
4.2 Sample codes

Class room Registration

Page 46
Teacher registration
Page 47

Page 48

Page 49

Page 50
4.3 Recommendation
Our system is only applicable for college of computing and informatics faculty, because of the applicability of the
system and ease of use we fell other faculties in Haramaya University will benefit from it.
So we recommend that the system be expanded to include all faculties and departments in Haramaya University.
We advise that the site be hosted on a secure server and that the administration of the website is given to a person or
entity that has experience in managing a website. Also this website is useful for who are going to do in the advanced
way.

Page 51
Reference
 THE OBJECT PRIMER, THIRD EDITION, Agile Model-Driven Development, With

UML 2.0, SCOTT W.AMBLER.
 Haramaya University website (www.haramaya.edu.et).

Page 52

Done By:: Scheduling System For CCI of HU

Uploaded by

Document Information

Original Title

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

Done By:: Scheduling System For CCI of HU

Uploaded by

Copyright:

Available Formats

Scheduling system for CCI of HU

DONE BY: DEPARTMENT OF MANAGEMENT INFORMATION SYSTEM IN, 2015

Final project by MIS 3rdyear

Final project by MIS 3rdyear

Chapter one: Introduction part

Chapter two: System Requirement Specifications and Analysis Modelling (SRS)

Chapter Three: Design Document

Chapter Four: Implementation Document

Final project by MIS 3rdyear

Final project by MIS 3rdyear

Final project by MIS 3rdyear

1.3 Statement of problem

1.4Objectives of the project

Final project by MIS 3rdyear

1.5 Methodology of the project

1.5.2 Method of data collection

1.7Significance of the project

1.8 Feasibility assessment

1.8.1 Economic Feasibility

Final project by MIS 3rdyear

No. Task name Start Finish Durati 2007

1.9 Management issues

Final project by MIS 3rdyear

1.10 System development tools

Final project by MIS 3rdyear

2.2 Class responsibility collaboration (CRC)

Final project by MIS 3rdyear

Figure 2.1 CRC model for scheduling system

2.3 Use case modeling

Final project by MIS 3rdyear

Figure 2.2 essential use cases for scheduling system.

Description for essential use case

Precondition:student should be the legal member of the class.

Post condition: follow teacher

Final project by MIS 3rdyear

Precondition:the instructor should be assigned by the college.

Post condition:teach students

Precondition:Has an interest to view schedule.

Post condition:Know the schedule.

Table 2.3essential use case descriptions for view schedule.

Precondition: Theuser should be an authorized user.

Post condition: The schedule is generated.

Table 2.4essential use case descriptions for arrange schedule.

2.3.2 System use case modeling

Final project by MIS 3rdyear

Final project by MIS 3rdyear

System use case description

Post condition: The user access the system.

Table2.5 System use case documentation for login use case.

Final project by MIS 3rdyear

Use case description for generate

Basic course of action: 1The administrator clicks on admin login.

Final project by MIS 3rdyear

Use case documentation for update schedule

Documentation for delete use case

Final project by MIS 3rdyear

Use case name: Delete schedule

Table2.11 System use case documentation for register use case.

Documentation for register use case

Post condition: The user’s information is saved to the system.

2.4User interface prototyping

Final project by MIS 3rdyear

Final project by MIS 3rdyear